1. 09 Jun, 2014 35 commits
  2. 18 May, 2014 5 commits
    • Ben Hutchings's avatar
      Linux 3.2.59 · 382ae9d0
      Ben Hutchings authored
      382ae9d0
    • Matthew Daley's avatar
      floppy: don't write kernel-only members to FDRAWCMD ioctl output · 629cbea2
      Matthew Daley authored
      commit 2145e15e upstream.
      
      Do not leak kernel-only floppy_raw_cmd structure members to userspace.
      This includes the linked-list pointer and the pointer to the allocated
      DMA space.
      Signed-off-by: default avatarMatthew Daley <mattd@bugfuzz.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      629cbea2
    • Matthew Daley's avatar
      floppy: ignore kernel-only members in FDRAWCMD ioctl input · d79119d4
      Matthew Daley authored
      commit ef87dbe7 upstream.
      
      Always clear out these floppy_raw_cmd struct members after copying the
      entire structure from userspace so that the in-kernel version is always
      valid and never left in an interdeterminate state.
      Signed-off-by: default avatarMatthew Daley <mattd@bugfuzz.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d79119d4
    • Peter Hurley's avatar
      n_tty: Fix n_tty_write crash when echoing in raw mode · 1e509971
      Peter Hurley authored
      commit 4291086b upstream.
      
      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
      d945cb9c (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
      
      References: CVE-2014-0196
      Reported-and-tested-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarJiri 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: output_lock is a member of struct tty_struct]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1e509971
    • Ben Hutchings's avatar
      rtl8192ce: Fix null dereference in watchdog · 11e83519
      Ben Hutchings authored
      Dmitry Semyonov reported that after upgrading from 3.2.54 to
      3.2.57 the rtl8192ce driver will crash when its interface is brought
      up.  The oops message shows:
      
      [ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [ 1833.611455] IP: [<ffffffffa0410c6a>] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
      ...
      [ 1833.613326] Call Trace:
      [ 1833.613346]  [<ffffffffa02ad9c6>] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
      [ 1833.613391]  [<ffffffff8105b5cf>] ? process_one_work+0x161/0x269
      [ 1833.613425]  [<ffffffff8105c598>] ? worker_thread+0xc2/0x145
      [ 1833.613458]  [<ffffffff8105c4d6>] ? manage_workers.isra.25+0x15b/0x15b
      [ 1833.613496]  [<ffffffff8105f6d9>] ? kthread+0x76/0x7e
      [ 1833.613527]  [<ffffffff81356b74>] ? kernel_thread_helper+0x4/0x10
      [ 1833.613563]  [<ffffffff8105f663>] ? kthread_worker_fn+0x139/0x139
      [ 1833.613598]  [<ffffffff81356b70>] ? gs_change+0x13/0x13
      
      Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
      parameter was null.  None of the changes to the rtlwifi family between
      3.2.54 and 3.2.57 seem to directly cause this, and reverting commit 
      f78bccd7 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
      doesn't fix it.
      
      rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
      rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
      call trace as it was inlined.  That function has been completely
      removed upstream which may explain why this crash wasn't seen there.
      
      I'm not sure that it is sensible to completely remove
      rtl92c_dm_refresh_rate_adaptive_mask() without making other
      compensating changes elsewhere, so try to work around this for 3.2 by
      checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
      and then skipping the call to rtl92ce_update_hal_rate_tbl().
      
      References: https://bugs.debian.org/745137
      References: https://bugs.debian.org/745462Reported-by: default avatarDmitry Semyonov <linulin@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      11e83519