Skip to content

L
linux
Switch branch/tag
  1. 09 Jun, 2014 29 commits
  3. 18 May, 2014 11 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
    • Bjørn Mork's avatar
      usb: option: add and update a number of CMOTech devices · 74627ab1
      Bjørn Mork authored 
      commit 34f972d6 upstream.

A number of older CMOTech modems are based on Qualcomm
chips.  The blacklisted interfaces are QMI/wwan.
Reported-by: default avatarLars Melin <larsm17@gmail.com>
Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      74627ab1
    • Bjørn Mork's avatar
      usb: option: add Alcatel L800MA · 809d8833
      Bjørn Mork authored 
      commit dd6b48ec upstream.

Device interface layout:
0: ff/ff/ff - serial
1: ff/00/00 - serial AT+PPP
2: ff/ff/ff - QMI/wwan
3: 08/06/50 - storage
Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      809d8833
    • Bjørn Mork's avatar
      usb: option: add Olivetti Olicard 500 · c0d47d94
      Bjørn Mork authored 
      commit 533b3994 upstream.

Device interface layout:
0: ff/ff/ff - serial
1: ff/ff/ff - serial AT+PPP
2: 08/06/50 - storage
3: ff/ff/ff - serial
4: ff/ff/ff - QMI/wwan
Reported-by: default avatarJulio Araujo <julio.araujo@wllctel.com.br>
Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c0d47d94
    • Johan Hovold's avatar
      USB: io_ti: fix firmware download on big-endian machines · 83ad4b78
      Johan Hovold authored 
      commit 5509076d upstream.

During firmware download the device expects memory addresses in
big-endian byte order. As the wIndex parameter which hold the address is
sent in little-endian byte order regardless of host byte order, we need
to use swab16 rather than cpu_to_be16.

Also make sure to handle the struct ti_i2c_desc size parameter which is
returned in little-endian byte order.
Reported-by: default avatarLudovic Drolez <ldrolez@debian.org>
Tested-by: default avatarLudovic Drolez <ldrolez@debian.org>
Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      83ad4b78
    • David Cohen's avatar
      usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM · 42eb6ec9
      David Cohen authored 
      commit 01bb59eb upstream.

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]

Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.

This warning has been in since 3.2 kernel and was
caused by commit 421aa841
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried
Signed-off-by: default avatarDavid Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      42eb6ec9
    • Julius Werner's avatar
      usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb · b9c6d6da
      Julius Werner authored 
      commit 1f81b6d2 upstream.

We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.

The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.

This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.

This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747 "USB: xhci: URB
cancellation support."
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b9c6d6da
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7