Skip to content

Conversation

@aifari777
Copy link

No description provided.

jmalinen and others added 30 commits July 15, 2012 21:57
When user space SME/MLME (e.g., hostapd) is not used in AP mode, the
IEs from the (Re)Association Request frame that was processed in
firmware need to be made available for user space (e.g., RSN IE for
hostapd). Allow this to be done with cfg80211_new_sta().

(cherry picked from commit d692df2 from
android.googlesource.com/common.git)

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I211171ca4953832cc998402c149ecf3fc429f9e6
Reviewed-on: http://git-master/r/78886
Reviewed-by: Automatic_Commit_Validation_User
mac80211 leaves sinfo->assoc_req_ies uninitialized, causing a random
pointer memory access in nl80211_send_station.
Instead of checking if the pointer is null, use sinfo->filled, like
the rest of the fields.

Change-Id: I312a466f8c631ad64a16ecf191fa8046fe658cc1
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: http://mcrd1-5.corpnet.asus/code-review/master/48179
Reviewed-by: Jim1 Lin <jim1_lin@asus.com>
Tested-by: Jim1 Lin <jim1_lin@asus.com>
Reviewed-by: Leslie Yu <Leslie_Yu@asus.com>
Indicate an NL80211_CMD_DEL_STATION event when a station entry in
mac80211 is deleted to match with the NL80211_CMD_NEW_STATION event
that is used when the entry was added. This is needed, e.g., to allow
user space to remove a peer from RSN IBSS Authenticator state machine
to avoid re-authentication and re-keying delays when the peer is not
reachable anymore.

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
…ported

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
zachf714 and others added 30 commits April 10, 2014 17:34
Just stops some log spam
Kanged from nobodyAtall

Change-Id: I479372ad7877a1406d8fa31a2723dc9a1999a002
Signed-off-by: RonGokhale <cips173@gmail.com>

Conflicts:

	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9 (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

Change-Id: Ie0b03989fa8cfd6ffe40d1f770044fe7447dda05
References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.4: output_lock is a member of struct tty_struct]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.