3 years agocrypto: algapi - fix NULL dereference in crypto_remove_spawns()
Eric Biggers [Fri, 29 Dec 2017 20:30:19 +0000 (14:30 -0600)]
crypto: algapi - fix NULL dereference in crypto_remove_spawns()

commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream.

syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
via a program that repeatedly and concurrently requests AEADs
"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
through AF_ALG, where the hashes are requested as "untested"
(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
causes the template to be instantiated for every request).

Although AF_ALG users really shouldn't be able to request an "untested"
algorithm, the NULL pointer dereference is actually caused by a
longstanding race condition where crypto_remove_spawns() can encounter
an instance which has had spawn(s) "grabbed" but hasn't yet been
registered, resulting in ->cra_users still being NULL.

We probably should properly initialize ->cra_users earlier, but that
would require updating many templates individually.  For now just fix
the bug in a simple way that can easily be backported: make
crypto_remove_spawns() treat a NULL ->cra_users list as empty.

Reported-by: syzbot <>
Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
3 years agomm/mprotect: add a cond_resched() inside change_pmd_range()
Anshuman Khandual [Fri, 5 Jan 2018 00:17:52 +0000 (16:17 -0800)]
mm/mprotect: add a cond_resched() inside change_pmd_range()

commit 4991c09c7c812dba13ea9be79a68b4565bb1fa4e upstream.

While testing on a large CPU system, detected the following RCU stall
many times over the span of the workload.  This problem is solved by
adding a cond_resched() in the change_pmd_range() function.

  INFO: rcu_sched detected stalls on CPUs/tasks:
   154-....: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612
   (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864)
  Sending NMI from CPU 955 to CPUs 154:
  NMI backtrace for cpu 154
  CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3
  NIP:  c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18
  REGS: 00000000a4b0fb44 TRAP: 0501   Not tainted  (4.15.0-rc3+)
  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 22422082  XER: 00000000
  CFAR: 00000000006cf8f0 SOFTE: 1
  GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000
  GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00
  GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00
  GPR12: ffffffffffffffff c00000000fb25100
  NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c
  LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420
  Call Trace:
  Instruction dump:
  60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378
  e9410060 e9610068 e9810070 44000022 <7d806378e9810028 f88c0000 f8ac0008

Signed-off-by: Anshuman Khandual <>
Suggested-by: Nicholas Piggin <>
Acked-by: Michal Hocko <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: remove kernel addresses from usb device and urb debug msgs
Shuah Khan [Sat, 23 Dec 2017 00:00:06 +0000 (17:00 -0700)]
usbip: remove kernel addresses from usb device and urb debug msgs

commit e1346fd87c71a1f61de1fe476ec8df1425ac931c upstream.

usbip_dump_usb_device() and usbip_dump_urb() print kernel addresses.
Remove kernel addresses from usb device and urb debug msgs and improve
the message content.

Instead of printing parent device and bus addresses, print parent device
and bus names.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: pcm: Add missing error checks in OSS emulation plugin builder
Takashi Iwai [Thu, 4 Jan 2018 15:39:27 +0000 (16:39 +0100)]
ALSA: pcm: Add missing error checks in OSS emulation plugin builder

commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.

In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.

This patch papers over such places.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: cp210x: add new device ID ELV ALC 8xxx
Christian Holl [Wed, 3 Jan 2018 18:53:02 +0000 (19:53 +0100)]
USB: serial: cp210x: add new device ID ELV ALC 8xxx

commit d14ac576d10f865970bb1324d337e5e24d79aaf4 upstream.

This adds the ELV ALC 8xxx Battery Charging device
to the list of USB IDs of drivers/usb/serial/cp210x.c

Signed-off-by: Christian Holl <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
3 years agommc: s3mci: mark debug_regs[] as static
Arnd Bergmann [Wed, 3 Jan 2018 22:49:18 +0000 (23:49 +0100)]
mmc: s3mci: mark debug_regs[] as static

commit 2bd7b4aacdb6efa5ccd4749c365c171b884791d2 upstream.

The global array clashes with a newly added symbol of the same name:

drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of `debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here

We should fix both, this one addresses the s3cmci driver by removing
the symbol from the global namespace. While at it, this separates
the declaration from the type definition and makes the variable const.

Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs interface")
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Ulf Hansson <>
Signed-off-by: Ben Hutchings <>
3 years agoe1000e: Fix e1000_check_for_copper_link_ich8lan return value.
Benjamin Poirier [Mon, 11 Dec 2017 07:26:40 +0000 (16:26 +0900)]
e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

commit 4110e02eb45ea447ec6f5459c9934de0a273fb91 upstream.

e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan()
are the two functions that may be assigned to mac.ops.check_for_link when
phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d ("e1000e:
Separate signaling for link check/link up") changed the meaning of the
return value of check_for_link for copper media but only adjusted the first
function. This patch adjusts the second function likewise.

Reported-by: Christian Hesse <>
Reported-by: Gabriel C <>
Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
Signed-off-by: Benjamin Poirier <>
Tested-by: Aaron Brown <>
Tested-by: Christian Hesse <>
Signed-off-by: Jeff Kirsher <>
[bwh: Backported to 3.2: e1000_check_for_copper_link() has a single return
 statement for success and error cases, so set ret_val in the link-up
 case instead of changing that statement.]
Signed-off-by: Ben Hutchings <>
3 years agoe1000e: Separate signaling for link check/link up
Benjamin Poirier [Fri, 21 Jul 2017 18:36:26 +0000 (11:36 -0700)]
e1000e: Separate signaling for link check/link up

commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.

Lennart reported the following race condition:

\ e1000_watchdog_task
    \ e1000e_has_link
        \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
            /* link is up */
            mac->get_link_status = false;

                            /* interrupt */
                            \ e1000_msix_other
                                hw->mac.get_link_status = true;

        link_active = !hw->mac.get_link_status
        /* link_active is false, wrongly */

This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is

Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().

Reported-by: Lennart Sorensen <>
Signed-off-by: Benjamin Poirier <>
Tested-by: Aaron Brown <>
Signed-off-by: Jeff Kirsher <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: pcm: Remove incorrect snd_BUG_ON() usages
Takashi Iwai [Mon, 1 Jan 2018 08:50:50 +0000 (09:50 +0100)]
ALSA: pcm: Remove incorrect snd_BUG_ON() usages

commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.

syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
  WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
  snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
  Call Trace:
   snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
   snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
   snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
   snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
   snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
   __fput+0x327/0x7e0 fs/file_table.c:210

This happens while it tries to open and set up the aloop device
concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail.  The theory is true for the case where the hw_params
config rules are static.  But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().

That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path.  As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agofscache: Fix the default for fscache_maybe_release_page()
David Howells [Tue, 2 Jan 2018 10:02:19 +0000 (10:02 +0000)]
fscache: Fix the default for fscache_maybe_release_page()

commit 98801506552593c9b8ac11021b0cdad12cab4f6b upstream.

Fix the default for fscache_maybe_release_page() for when the cookie isn't
valid or the page isn't cached.  It mustn't return false as that indicates
the page cannot yet be freed.

The problem with the default is that if, say, there's no cache, but a
network filesystem's pages are using up almost all the available memory, a
system can OOM because the filesystem ->releasepage() op will not allow
them to be released as fscache_maybe_release_page() incorrectly prevents

This can be tested by writing a sequence of 512MiB files to an AFS mount.
It does not affect NFS or CIFS because both of those wrap the call in a
check of PG_fscache and it shouldn't bother Ceph as that only has
PG_private set whilst writeback is in progress.  This might be an issue for
9P, however.

Note that the pages aren't entirely stuck.  Removing a file or unmounting
will clear things because that uses ->invalidatepage() instead.

Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
Reported-by: Marc Dionne <>
Signed-off-by: David Howells <>
Reviewed-by: Jeff Layton <>
Acked-by: Al Viro <>
Tested-by: Marc Dionne <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ
Diego Elio Pettenò [Fri, 29 Dec 2017 09:54:25 +0000 (09:54 +0000)]
USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ

commit 4307413256ac1e09b8f53e8715af3df9e49beec3 upstream.

Add IDs for the OneTouch Verio IQ that comes with an embedded
USB-to-serial converter.

Signed-off-by: Diego Elio Pettenò <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
3 years agokbuild: add '-fno-stack-check' to kernel build options
Linus Torvalds [Sat, 30 Dec 2017 01:34:43 +0000 (17:34 -0800)]
kbuild: add '-fno-stack-check' to kernel build options

commit 3ce120b16cc548472f80cf8644f90eda958cf1b6 upstream.

It appears that hardened gentoo enables "-fstack-check" by default for

That doesn't work _at_all_ for the kernel, because the kernel stack
doesn't act like a user stack at all: it's much smaller, and it doesn't
auto-expand on use.  So the extra "probe one page below the stack" code
generated by -fstack-check just breaks the kernel in horrible ways,
causing infinite double faults etc.

[ I have to say, that the particular code gcc generates looks very
  stupid even for user space where it works, but that's a separate
  issue.  ]

Reported-and-tested-by: Alexander Tsoy <>
Reported-and-tested-by: Toralf Förster <>
Cc: Dave Hansen <>
Cc: Jiri Kosina <>
Cc: Andy Lutomirski <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
3 years agoaf_key: fix buffer overread in parse_exthdrs()
Eric Biggers [Sat, 30 Dec 2017 00:15:23 +0000 (18:15 -0600)]
af_key: fix buffer overread in parse_exthdrs()

commit 4e765b4972af7b07adcb1feb16e7a525ce1f6b28 upstream.

If a message sent to a PF_KEY socket ended with an incomplete extension
header (fewer than 4 bytes remaining), then parse_exthdrs() read past
the end of the message, into uninitialized memory.  Fix it by returning
-EINVAL in this case.


#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>

int main()
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[17] = { 0 };
struct sadb_msg *msg = (void *)buf;

msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 2;

write(sock, buf, 17);

Signed-off-by: Eric Biggers <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
3 years agoaf_key: fix buffer overread in verify_address_len()
Eric Biggers [Sat, 30 Dec 2017 00:13:05 +0000 (18:13 -0600)]
af_key: fix buffer overread in verify_address_len()

commit 06b335cb51af018d5feeff5dd4fd53847ddb675a upstream.

If a message sent to a PF_KEY socket ended with one of the extensions
that takes a 'struct sadb_address' but there were not enough bytes
remaining in the message for the ->sa_family member of the 'struct
sockaddr' which is supposed to follow, then verify_address_len() read
past the end of the message, into uninitialized memory.  Fix it by
returning -EINVAL in this case.

This bug was found using syzkaller with KMSAN.


#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>

int main()
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[24] = { 0 };
struct sadb_msg *msg = (void *)buf;
struct sadb_address *addr = (void *)(msg + 1);

msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 3;
addr->sadb_address_len = 1;
addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC;

write(sock, buf, 24);

Reported-by: Alexander Potapenko <>
Signed-off-by: Eric Biggers <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
3 years agoinclude/stddef.h: Move offsetofend() from vfio.h to a generic kernel header
Denys Vlasenko [Mon, 9 Mar 2015 14:52:17 +0000 (15:52 +0100)]
include/stddef.h: Move offsetofend() from vfio.h to a generic kernel header

commit 3876488444e71238e287459c39d7692b6f718c3e upstream.

Suggested by Andy.

Suggested-by: Andy Lutomirski <>
Signed-off-by: Denys Vlasenko <>
Acked-by: Linus Torvalds <>
Cc: Alexei Starovoitov <>
Cc: Borislav Petkov <>
Cc: Frederic Weisbecker <>
Cc: H. Peter Anvin <>
Cc: Kees Cook <>
Cc: Oleg Nesterov <>
Cc: Steven Rostedt <>
Cc: Will Drewry <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - There is no definition in vfio.h to move
 - Put the definition inside the #ifdef __KERNEL__ section]
Signed-off-by: Ben Hutchings <>
3 years agoring-buffer: Mask out the info bits when returning buffer page length
Steven Rostedt (VMware) [Sat, 23 Dec 2017 01:32:35 +0000 (20:32 -0500)]
ring-buffer: Mask out the info bits when returning buffer page length

commit 45d8b80c2ac5d21cd1e2954431fb676bc2b1e099 upstream.

Two info bits were added to the "commit" part of the ring buffer data page
when returned to be consumed. This was to inform the user space readers that
events have been missed, and that the count may be stored at the end of the

What wasn't handled, was the splice code that actually called a function to
return the length of the data in order to zero out the rest of the page
before sending it up to user space. These data bits were returned with the
length making the value negative, and that negative value was not checked.
It was compared to PAGE_SIZE, and only used if the size was less than
PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an
unsigned compare, meaning the negative size value did not end up causing a
large portion of memory to be randomly zeroed out.

Fixes: 66a8cb95ed040 ("ring-buffer: Add place holder recording of dropped events")
Signed-off-by: Steven Rostedt (VMware) <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: ftdi_sio: add id for Airbus DS P8GR
Max Schulze [Wed, 20 Dec 2017 19:47:44 +0000 (20:47 +0100)]
USB: serial: ftdi_sio: add id for Airbus DS P8GR

commit c6a36ad383559a60a249aa6016cebf3cb8b6c485 upstream.

Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver.

Signed-off-by: Max Schulze <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agocrypto: n2 - cure use after free
Jan Engelhardt [Tue, 19 Dec 2017 18:09:07 +0000 (19:09 +0100)]
crypto: n2 - cure use after free

commit 203f45003a3d03eea8fa28d74cfc74c354416fdb upstream.

queue_cache_init is first called for the Control Word Queue
(n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
kmem_cache will be allocated. If the subsequent n2_register_algs call
fails, the kmem_cache will be released in queue_cache_destroy, but
queue_cache_init[0] is not set back to NULL.

So when the Module Arithmetic Unit gets probed next (n2_mau_probe),
queue_cache_init will not allocate a kmem_cache again, but leave it
as its bogus value, causing a BUG() to trigger when queue_cache[0] is
eventually passed to kmem_cache_zalloc:

n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
n2_crypto: md5 alg registration failed
n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register algorithms.
called queue_cache_destroy
n2cp: probe of f028687c failed with error -22
n2_crypto: Found NCP at /virtual-devices@100/ncp@6
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
kernel BUG at mm/slab.c:2993!
Call Trace:
 [0000000000604488] kmem_cache_alloc+0x1a8/0x1e0
                  (inlined) kmem_cache_zalloc
                  (inlined) new_queue
                  (inlined) spu_queue_setup
                  (inlined) handle_exec_unit
 [0000000010c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto]
 [0000000010c62b80] n2_mau_probe+0x100/0x220 [n2_crypto]
 [000000000084b174] platform_drv_probe+0x34/0xc0

Signed-off-by: Jan Engelhardt <>
Acked-by: David S. Miller <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
3 years agoiw_cxgb4: Only validate the MSN for successful completions
Steve Wise [Mon, 18 Dec 2017 21:10:00 +0000 (13:10 -0800)]
iw_cxgb4: Only validate the MSN for successful completions

commit f55688c45442bc863f40ad678c638785b26cdce6 upstream.

If the RECV CQE is in error, ignore the MSN check.  This was causing
recvs that were flushed into the sw cq to be completed with the wrong
status (BAD_MSN instead of FLUSHED).

Signed-off-by: Steve Wise <>
Signed-off-by: Jason Gunthorpe <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agon_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)
Linus Torvalds [Thu, 21 Dec 2017 01:57:06 +0000 (17:57 -0800)]
n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa <>
Reported-by: syzkaller <>
Cc: Jiri Slaby <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agousb: Add device quirk for Logitech HD Pro Webcam C925e
Dmitry Fleytman Dmitry Fleytman [Tue, 19 Dec 2017 04:02:04 +0000 (06:02 +0200)]
usb: Add device quirk for Logitech HD Pro Webcam C925e

commit 7f038d256c723dd390d2fca942919573995f4cfd upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

There is one more model that has the same issue - C925e, so applying
the same quirk as well.

See aforementioned commit message for detailed explanation of the problem.

Signed-off-by: Dmitry Fleytman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agousb: add RESET_RESUME for ELSA MicroLink 56K
Oliver Neukum [Tue, 12 Dec 2017 15:11:30 +0000 (16:11 +0100)]
usb: add RESET_RESUME for ELSA MicroLink 56K

commit b9096d9f15c142574ebebe8fbb137012bb9d99c2 upstream.

This modem needs this quirk to operate. It produces timeouts when
resumed without reset.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agousbip: fix usbip bind writing random string after command in match_busid
Juan Zea [Fri, 15 Dec 2017 09:21:20 +0000 (10:21 +0100)]
usbip: fix usbip bind writing random string after command in match_busid

commit 544c4605acc5ae4afe7dd5914147947db182f2fb upstream.

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea <>
Acked-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: prevent leaking socket pointer address in messages
Shuah Khan [Fri, 15 Dec 2017 17:50:09 +0000 (10:50 -0700)]
usbip: prevent leaking socket pointer address in messages

commit 90120d15f4c397272aaf41077960a157fc4212bf upstream.

usbip driver is leaking socket pointer address in messages. Remove
the messages that aren't useful and print sockfd in the ones that
are useful for debugging.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filenames, context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: stub: stop printing kernel pointer addresses in messages
Shuah Khan [Tue, 19 Dec 2017 00:23:37 +0000 (17:23 -0700)]
usbip: stub: stop printing kernel pointer addresses in messages

commit 248a22044366f588d46754c54dfe29ffe4f8b4df upstream.

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop change in stub_complete()
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: vhci: stop printing kernel pointer addresses in messages
Shuah Khan [Tue, 19 Dec 2017 00:24:22 +0000 (17:24 -0700)]
usbip: vhci: stop printing kernel pointer addresses in messages

commit 8272d099d05f7ab2776cf56a2ab9f9443be18907 upstream.

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filenames, context, indentation]
Signed-off-by: Ben Hutchings <>
3 years agostaging: usbip: removed dead code from receive function
Bart Westgeest [Mon, 19 Dec 2011 22:44:11 +0000 (17:44 -0500)]
staging: usbip: removed dead code from receive function

commit 5a08c5267e45fe936452051a8c126e8418984eb7 upstream.

The usbip_xmit function supported sending and receiving data, however
the sending part of the function was never used/executed. Renamed the
function to usbip_recv, and removed the unused code.

Signed-off-by: Bart Westgeest <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: option: adding support for YUGA CLM920-NC5
SZ Lin (林上智) [Tue, 19 Dec 2017 09:40:32 +0000 (17:40 +0800)]
USB: serial: option: adding support for YUGA CLM920-NC5

commit 3920bb713038810f25770e7545b79f204685c8f2 upstream.

This patch adds support for YUGA CLM920-NC5 PID 0x9625 USB modem to option

Interface layout:
1: ADB
3: AT

Signed-off-by: Taiyi Wu <>
Signed-off-by: SZ Lin (林上智) <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
3 years agoxfrm: Reinject transport-mode packets through tasklet
Herbert Xu [Fri, 15 Dec 2017 05:40:44 +0000 (16:40 +1100)]
xfrm: Reinject transport-mode packets through tasklet

commit acf568ee859f098279eadf551612f103afdacb4e upstream.

This is an old bugbear of mine:

By crafting special packets, it is possible to cause recursion
in our kernel when processing transport-mode packets at levels
that are only limited by packet size.

The easiest one is with DNAT, but an even worse one is where
UDP encapsulation is used in which case you just have to insert
an UDP encapsulation header in between each level of recursion.

This patch avoids this problem by reinjecting tranport-mode packets
through a tasklet.

Fixes: b05e106698d9 ("[IPV4/6]: Netfilter IPsec input hooks")
Signed-off-by: Herbert Xu <>
Signed-off-by: Steffen Klassert <>
[bwh: Backported to 3.2:
 - netfilter finish callbacks only receive an sk_buff pointer
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: usb-audio: Fix the missing ctl name suffix at parsing SU
Takashi Iwai [Mon, 18 Dec 2017 22:36:57 +0000 (23:36 +0100)]
ALSA: usb-audio: Fix the missing ctl name suffix at parsing SU

commit 5a15f289ee87eaf33f13f08a4909ec99d837ec5f upstream.

The commit 89b89d121ffc ("ALSA: usb-audio: Add check return value for
usb_string()") added the check of the return value from
snd_usb_copy_string_desc(), which is correct per se, but it introduced
a regression.  In the original code, either the "Clock Source",
"Playback Source" or "Capture Source" suffix is added after the
terminal string, while the commit changed it to add the suffix only
when get_term_name() is failing.  It ended up with an incorrect ctl
name like "PCM" instead of "PCM Capture Source".

Also, even the original code has a similar bug: when the ctl name is
generated from snd_usb_copy_string_desc() for the given iSelector, it
also doesn't put the suffix.

This patch addresses these issues: the suffix is added always when no
static mapping is found.  Also the patch tries to put more comments
and cleans up the if/else block for better readability in order to
avoid the same pitfall again.

Fixes: 89b89d121ffc ("ALSA: usb-audio: Add check return value for usb_string()")
Reported-and-tested-by: Mauro Santos <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agonet: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks
Nikolay Aleksandrov [Mon, 18 Dec 2017 15:35:09 +0000 (17:35 +0200)]
net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks

commit 84aeb437ab98a2bce3d4b2111c79723aedfceb33 upstream.

The early call to br_stp_change_bridge_id in bridge's newlink can cause
a memory leak if an error occurs during the newlink because the fdb
entries are not cleaned up if a different lladdr was specified, also
another minor issue is that it generates fdb notifications with
ifindex = 0. Another unrelated memory leak is the bridge sysfs entries
which get added on NETDEV_REGISTER event, but are not cleaned up in the
newlink error path. To remove this special case the call to
br_stp_change_bridge_id is done after netdev register and we cleanup the
bridge on changelink error via br_dev_delete to plug all leaks.

This patch makes netlink bridge destruction on newlink error the same as
dellink and ioctl del which is necessary since at that point we have a
fully initialized bridge device.

To reproduce the issue:
$ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1
RTNETLINK answers: Invalid argument

$ rmmod bridge
[ 1822.142525] =============================================================================
[ 1822.143640] BUG bridge_fdb_cache (Tainted: G           O    ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown()
[ 1822.144821] -----------------------------------------------------------------------------

[ 1822.145990] Disabling lock debugging due to kernel taint
[ 1822.146732] INFO: Slab 0x0000000092a844b2 objects=32 used=2 fp=0x00000000fef011b0 flags=0x1ffff8000000100
[ 1822.147700] CPU: 2 PID: 13584 Comm: rmmod Tainted: G    B      O     4.15.0-rc2+ #87
[ 1822.148578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 1822.150008] Call Trace:
[ 1822.150510]  dump_stack+0x78/0xa9
[ 1822.151156]  slab_err+0xb1/0xd3
[ 1822.151834]  ? __kmalloc+0x1bb/0x1ce
[ 1822.152546]  __kmem_cache_shutdown+0x151/0x28b
[ 1822.153395]  shutdown_cache+0x13/0x144
[ 1822.154126]  kmem_cache_destroy+0x1c0/0x1fb
[ 1822.154669]  SyS_delete_module+0x194/0x244
[ 1822.155199]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 1822.155773]  entry_SYSCALL_64_fastpath+0x23/0x9a
[ 1822.156343] RIP: 0033:0x7f929bd38b17
[ 1822.156859] RSP: 002b:00007ffd160e9a98 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0
[ 1822.157728] RAX: ffffffffffffffda RBX: 00005578316ba090 RCX: 00007f929bd38b17
[ 1822.158422] RDX: 00007f929bd9ec60 RSI: 0000000000000800 RDI: 00005578316ba0f0
[ 1822.159114] RBP: 0000000000000003 R08: 00007f929bff5f20 R09: 00007ffd160e8a11
[ 1822.159808] R10: 00007ffd160e9860 R11: 0000000000000202 R12: 00007ffd160e8a80
[ 1822.160513] R13: 0000000000000000 R14: 0000000000000000 R15: 00005578316ba090
[ 1822.161278] INFO: Object 0x000000007645de29 @offset=0
[ 1822.161666] INFO: Object 0x00000000d5df2ab5 @offset=128

Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device")
Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
Signed-off-by: Nikolay Aleksandrov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: register_netdevice() was the last thing done in
 br_dev_newlink(), so no extra cleanup is needed]
Signed-off-by: Ben Hutchings <>
3 years agonet: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.
Zhao Qiang [Mon, 18 Dec 2017 02:26:43 +0000 (10:26 +0800)]
net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.

commit c505873eaece2b4aefd07d339dc7e1400e0235ac upstream.

88E1145 also need this autoneg errata.

Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoACPI: APEI / ERST: Fix missing error handling in erst_reader()
Takashi Iwai [Thu, 14 Dec 2017 12:31:16 +0000 (13:31 +0100)]
ACPI: APEI / ERST: Fix missing error handling in erst_reader()

commit bb82e0b4a7e96494f0c1004ce50cec3d7b5fb3d1 upstream.

The commit f6f828513290 ("pstore: pass allocated memory region back to
caller") changed the check of the return value from erst_read() in
erst_reader() in the following way:

        if (len == -ENOENT)
                goto skip;
-       else if (len < 0) {
-               rc = -1;
+       else if (len < sizeof(*rcd)) {
+               rc = -EIO;
                goto out;

This introduced another bug: since the comparison with sizeof() is
cast to unsigned, a negative len value doesn't hit any longer.
As a result, when an error is returned from erst_read(), the code
falls through, and it may eventually lead to some weird thing like
memory corruption.

This patch adds the negative error value check more explicitly for
addressing the issue.

Fixes: f6f828513290 (pstore: pass allocated memory region back to caller)
Tested-by: Jerry Tang <>
Signed-off-by: Takashi Iwai <>
Acked-by: Kees Cook <>
Reviewed-by: Borislav Petkov <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
3 years agoPCI / PM: Force devices to D0 in pci_pm_thaw_noirq()
Rafael J. Wysocki [Fri, 15 Dec 2017 02:07:18 +0000 (03:07 +0100)]
PCI / PM: Force devices to D0 in pci_pm_thaw_noirq()

commit 5839ee7389e893a31e4e3c9cf17b50d14103c902 upstream.

It is incorrect to call pci_restore_state() for devices in low-power
states (D1-D3), as that involves the restoration of MSI setup which
requires MMIO to be operational and that is only the case in D0.

However, pci_pm_thaw_noirq() may do that if the driver's "freeze"
callbacks put the device into a low-power state, so fix it by making
it force devices into D0 via pci_set_power_state() instead of trying
to "update" their power state which is pointless.

Fixes: e60514bd4485 (PCI/PM: Restore the status of PCI devices across hibernation)
Reported-by: Thomas Gleixner <>
Reported-by: Maarten Lankhorst <>
Tested-by: Thomas Gleixner <>
Tested-by: Maarten Lankhorst <>
Signed-off-by: Rafael J. Wysocki <>
Acked-by: Bjorn Helgaas <>
Signed-off-by: Ben Hutchings <>
3 years agoparisc: Hide Diva-built-in serial aux and graphics card
Helge Deller [Tue, 12 Dec 2017 20:52:26 +0000 (21:52 +0100)]
parisc: Hide Diva-built-in serial aux and graphics card

commit bcf3f1752a622f1372d3252d0fea8855d89812e7 upstream.

Diva GSP card has built-in serial AUX port and ATI graphic card which simply
don't work and which both don't have external connectors.  User Guides even
mention that those devices shouldn't be used.
So, prevent that Linux drivers try to enable those devices.

Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
3 years agoposix-timer: Properly check sigevent->sigev_notify
Thomas Gleixner [Fri, 15 Dec 2017 09:32:03 +0000 (10:32 +0100)]
posix-timer: Properly check sigevent->sigev_notify

commit cef31d9af908243421258f1df35a4a644604efbe upstream.

timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD

The sanity check in good_sigevent() is only checking the valid combination
not set it accepts any random value.

This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.

Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.

Reported-by: Eric Biggers <>
Reported-by: Dmitry Vyukov <>
Reported-by: Alexey Dobriyan <>
Signed-off-by: Thomas Gleixner <>
Cc: John Stultz <>
[bwh: Backported to 3.2:
 - Add sig_none variable in common_timer_get(), added earlier upstream
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agonfsd: auth: Fix gid sorting when rootsquash enabled
Ben Hutchings [Mon, 22 Jan 2018 20:11:06 +0000 (20:11 +0000)]
nfsd: auth: Fix gid sorting when rootsquash enabled

commit 1995266727fa8143897e89b55f5d3c79aa828420 upstream.

Commit bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility
group_info allocators") appears to break nfsd rootsquash in a pretty
major way.

It adds a call to groups_sort() inside the loop that copies/squashes
gids, which means the valid gids are sorted along with the following
garbage.  The net result is that the highest numbered valid gids are
replaced with any lower-valued garbage gids, possibly including 0.

We should sort only once, after filling in all the gids.

Fixes: bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility ...")
Signed-off-by: Ben Hutchings <>
Acked-by: J. Bruce Fields <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
3 years agokernel: make groups_sort calling a responsibility group_info allocators
Thiago Rafael Becker [Thu, 14 Dec 2017 23:33:12 +0000 (15:33 -0800)]
kernel: make groups_sort calling a responsibility group_info allocators

commit bdcf0a423ea1c40bbb40e7ee483b50fc8aa3d758 upstream.

In testing, we found that nfsd threads may call set_groups in parallel
for the same entry cached in auth.unix.gid, racing in the call of
groups_sort, corrupting the groups for that entry and leading to
permission denials for the client.

This patch:
 - Make groups_sort globally visible.
 - Move the call to groups_sort to the modifiers of group_info
 - Remove the call to groups_sort from set_groups

Signed-off-by: Thiago Rafael Becker <>
Reviewed-by: Matthew Wilcox <>
Reviewed-by: NeilBrown <>
Acked-by: "J. Bruce Fields" <>
Cc: Al Viro <>
Cc: Martin Schwidefsky <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Drop change in gss_rpc_xdr.c
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: rawmidi: Avoid racy info ioctl via ctl device
Takashi Iwai [Thu, 14 Dec 2017 15:44:12 +0000 (16:44 +0100)]
ALSA: rawmidi: Avoid racy info ioctl via ctl device

commit c1cfd9025cc394fd137a01159d74335c5ac978ce upstream.

The rawmidi also allows to obtaining the information via ioctl of ctl
API.  It means that user can issue an ioctl to the rawmidi device even
when it's being removed as long as the control device is present.
Although the code has some protection via the global register_mutex,
its range is limited to the search of the corresponding rawmidi
object, and the mutex is already unlocked at accessing the rawmidi
object.  This may lead to a use-after-free.

For avoiding it, this patch widens the application of register_mutex
to the whole snd_rawmidi_info_select() function.  We have another
mutex per rawmidi object, but this operation isn't very hot path, so
it shouldn't matter from the performance POV.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoKVM: X86: Fix load RFLAGS w/o the fixed bit
Wanpeng Li [Thu, 7 Dec 2017 08:30:08 +0000 (00:30 -0800)]
KVM: X86: Fix load RFLAGS w/o the fixed bit

commit d73235d17ba63b53dc0e1051dbc10a1f1be91b71 upstream.

 *** Guest State ***
 CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
 CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871
 CR3 = 0x00000000fffbc000
 RSP = 0x0000000000000000  RIP = 0x0000000000000000
 RFLAGS=0x00000000         DR7 = 0x0000000000000400

The failed vmentry is triggered by the following testcase when ept=Y:

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <string.h>
    #include <stdint.h>
    #include <linux/kvm.h>
    #include <fcntl.h>
    #include <sys/ioctl.h>

    long r[5];
    int main()
     r[2] = open("/dev/kvm", O_RDONLY);
     r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
     r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
     struct kvm_regs regs = {
     .rflags = 0,
     ioctl(r[4], KVM_SET_REGS, &regs);
     ioctl(r[4], KVM_RUN, 0);

X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1
of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails.
This patch fixes it by oring X86_EFLAGS_FIXED during ioctl.

Suggested-by: Jim Mattson <>
Reviewed-by: David Hildenbrand <>
Reviewed-by: Quan Xu <>
Cc: Paolo Bonzini <>
Cc: Radim Krčmář <>
Cc: Jim Mattson <>
Signed-off-by: Wanpeng Li <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: use literal integer]
Signed-off-by: Ben Hutchings <>
3 years agotcp md5sig: Use skb's saddr when replying to an incoming segment
Christoph Paasch [Mon, 11 Dec 2017 08:05:46 +0000 (00:05 -0800)]
tcp md5sig: Use skb's saddr when replying to an incoming segment

commit 30791ac41927ebd3e75486f9504b6d2280463bf0 upstream.

The MD5-key that belongs to a connection is identified by the peer's
IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number

Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.

This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences are not catastrophic. We will call
tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer,
thus the connection doesn't really fail.

Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().")
Signed-off-by: Christoph Paasch <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoext4: fix crash when a directory's i_size is too small
Chandan Rajendra [Mon, 11 Dec 2017 20:00:57 +0000 (15:00 -0500)]
ext4: fix crash when a directory's i_size is too small

commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.

On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,

VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)

This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is

This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.

Reported-by: Abdul Haleem <>
Signed-off-by: Chandan Rajendra <>
Signed-off-by: Ben Hutchings <>
3 years agonet: ipv4: fix for a race condition in raw_sendmsg
Mohamed Ghannam [Sun, 10 Dec 2017 03:50:58 +0000 (03:50 +0000)]
net: ipv4: fix for a race condition in raw_sendmsg

commit 8f659a03a0ba9289b9aeb9b4470e6fb263d6f483 upstream.

inet->hdrincl is racy, and could lead to uninitialized stack pointer
usage, so its value should be read only once.

Fixes: c008ba5bdc9f ("ipv4: Avoid reading user iov twice after raw_probe_proto_opt")
Signed-off-by: Mohamed Ghannam <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - flowi4 flags don't depend on hdrincl
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoipv4: Avoid reading user iov twice after raw_probe_proto_opt
Herbert Xu [Fri, 7 Nov 2014 13:27:09 +0000 (21:27 +0800)]
ipv4: Avoid reading user iov twice after raw_probe_proto_opt

commit c008ba5bdc9fa830e1a349b20b0be5a137bdef7a upstream.

Ever since raw_probe_proto_opt was added it had the problem of
causing the user iov to be read twice, once during the probe for
the protocol header and once again in ip_append_data.

This is a potential security problem since it means that whatever
we're probing may be invalid.  This patch plugs the hole by
firstly advancing the iov so we don't read the same spot again,
and secondly saving what we read the first time around for use
by ip_append_data.

Signed-off-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoipv4: Use standard iovec primitive in raw_probe_proto_opt
Herbert Xu [Fri, 7 Nov 2014 13:27:08 +0000 (21:27 +0800)]
ipv4: Use standard iovec primitive in raw_probe_proto_opt

commit 32b5913a931fd753faf3d4e1124b2bc2edb364da upstream.

The function raw_probe_proto_opt tries to extract the first two
bytes from the user input in order to seed the IPsec lookup for
ICMP packets.  In doing so it's processing iovec by hand and
overcomplicating things.

This patch replaces the manual iovec processing with a call to

Signed-off-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoxhci: Don't add a virt_dev to the devs array before it's fully allocated
Mathias Nyman [Fri, 8 Dec 2017 16:10:05 +0000 (18:10 +0200)]
xhci: Don't add a virt_dev to the devs array before it's fully allocated

commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.

Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.

Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.

issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port

"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: There is an extra failure path, so we may need to
 free dev->eps[0].ring]
Signed-off-by: Ben Hutchings <>
3 years agoUSB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
David Kozub [Tue, 5 Dec 2017 21:40:04 +0000 (22:40 +0100)]
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.

There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:

[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb

The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).

Enabling US_FL_BROKEN_FUA quirk solves this issue.

This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.

Signed-off-by: David Kozub <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop uas change
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agocan: esd_usb2: cancel urb on -EPIPE and -EPROTO
Martin Kelly [Tue, 5 Dec 2017 19:15:48 +0000 (11:15 -0800)]
can: esd_usb2: cancel urb on -EPIPE and -EPROTO

commit 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 upstream.

In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect

This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.

Signed-off-by: Martin Kelly <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
3 years agocan: ems_usb: cancel urb on -EPIPE and -EPROTO
Martin Kelly [Tue, 5 Dec 2017 19:15:47 +0000 (11:15 -0800)]
can: ems_usb: cancel urb on -EPIPE and -EPROTO

commit bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 upstream.

In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect

This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.

Signed-off-by: Martin Kelly <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
3 years agobtrfs: Fix possible off-by-one in btrfs_search_path_in_tree
Nikolay Borisov [Fri, 1 Dec 2017 09:19:42 +0000 (11:19 +0200)]
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree

commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 upstream.

The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.


Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the

btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.

Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.

Before this patch the buffer was one byte larger, but then the -1 was
not added.

Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov <>
Reviewed-by: David Sterba <>
[ added implications ]
Signed-off-by: David Sterba <>
Signed-off-by: Ben Hutchings <>
3 years agokdb: Fix handling of kallsyms_symbol_next() return value
Daniel Thompson [Mon, 2 Mar 2015 14:13:36 +0000 (14:13 +0000)]
kdb: Fix handling of kallsyms_symbol_next() return value

commit c07d35338081d107e57cf37572d8cc931a8e32e2 upstream.

kallsyms_symbol_next() returns a boolean (true on success). Currently
kdb_read() tests the return value with an inequality that
unconditionally evaluates to true.

This is fixed in the obvious way and, since the conditional branch is
supposed to be unreachable, we also add a WARN_ON().

Reported-by: Dan Carpenter <>
Signed-off-by: Daniel Thompson <>
Signed-off-by: Jason Wessel <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: pcm: prevent UAF in snd_pcm_info
Robb Glasser [Tue, 5 Dec 2017 17:16:55 +0000 (09:16 -0800)]
ALSA: pcm: prevent UAF in snd_pcm_info

commit 362bca57f5d78220f8b5907b875961af9436e229 upstream.

When the device descriptor is closed, the `substream->runtime` pointer
is freed. But another thread may be in the ioctl handler, case
SNDRV_CTL_IOCTL_PCM_INFO. This case calls snd_pcm_info_user() which
calls snd_pcm_info() which accesses the now freed `substream->runtime`.

Note: this fixes CVE-2017-0861

Signed-off-by: Robb Glasser <>
Signed-off-by: Nick Desaulniers <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agonet_sched: red: Avoid illegal values
Nogah Frankel [Mon, 4 Dec 2017 11:31:11 +0000 (13:31 +0200)]
net_sched: red: Avoid illegal values

commit 8afa10cbe281b10371fee5a87ab266e48d71a7f9 upstream.

Check the qmin & qmax values doesn't overflow for the given Wlog value.
Check that qmin <= qmax.

Fixes: a783474591f2 ("[PKT_SCHED]: Generic RED layer")
Signed-off-by: Nogah Frankel <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop changes in sch_sfq
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agos390: always save and restore all registers on context switch
Heiko Carstens [Mon, 20 Nov 2017 11:38:44 +0000 (12:38 +0100)]
s390: always save and restore all registers on context switch

commit fbbd7f1a51965b50dd12924841da0d478f3da71b upstream.

The switch_to() macro has an optimization to avoid saving and
restoring register contents that aren't needed for kernel threads.

There is however the possibility that a kernel thread execve's a user
space program. In such a case the execve'd process can partially see
the contents of the previous process, which shouldn't be allowed.

To avoid this, simply always save and restore register contents on
context switch.

Fixes: fdb6d070effba ("switch_to: dont restore/save access & fpu regs for kernel threads")
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2:
 - The save/restore functions are different here
 - FP restore is non-lazy, so drop the comment about it being lazy
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agodm: fix various targets to dm_register_target after module __init resources created [Fri, 24 Nov 2017 17:43:50 +0000 (01:43 +0800)]
dm: fix various targets to dm_register_target after module __init resources created

commit 7e6358d244e4706fe612a77b9c36519a33600ac0 upstream.

A NULL pointer is seen if two concurrent "vgchange -ay -K <vg name>"
processes race to load the dm-thin-pool module:

 PID: 25992 TASK: ffff883cd7d23500 CPU: 4 COMMAND: "vgchange"
  #0 [ffff883cd743d600] machine_kexec at ffffffff81038fa9
  0000001 [ffff883cd743d660] crash_kexec at ffffffff810c5992
  0000002 [ffff883cd743d730] oops_end at ffffffff81515c90
  0000003 [ffff883cd743d760] no_context at ffffffff81049f1b
  0000004 [ffff883cd743d7b0] __bad_area_nosemaphore at ffffffff8104a1a5
  0000005 [ffff883cd743d800] bad_area at ffffffff8104a2ce
  0000006 [ffff883cd743d830] __do_page_fault at ffffffff8104aa6f
  0000007 [ffff883cd743d950] do_page_fault at ffffffff81517bae
  0000008 [ffff883cd743d980] page_fault at ffffffff81514f95
     [exception RIP: kmem_cache_alloc+108]
     RIP: ffffffff8116ef3c RSP: ffff883cd743da38 RFLAGS: 00010046
     RAX: 0000000000000004 RBX: ffffffff81121b90 RCX: ffff881bf1e78cc0
     RDX: 0000000000000000 RSI: 00000000000000d0 RDI: 0000000000000000
     RBP: ffff883cd743da68 R8: ffff881bf1a4eb00 R9: 0000000080042000
     R10: 0000000000002000 R11: 0000000000000000 R12: 00000000000000d0
     R13: 0000000000000000 R14: 00000000000000d0 R15: 0000000000000246
     ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
  0000009 [ffff883cd743da70] mempool_alloc_slab at ffffffff81121ba5
 0000010 [ffff883cd743da80] mempool_create_node at ffffffff81122083
 0000011 [ffff883cd743dad0] mempool_create at ffffffff811220f4
 0000012 [ffff883cd743dae0] pool_ctr at ffffffffa08de049 [dm_thin_pool]
 0000013 [ffff883cd743dbd0] dm_table_add_target at ffffffffa0005f2f [dm_mod]
 0000014 [ffff883cd743dc30] table_load at ffffffffa0008ba9 [dm_mod]
 0000015 [ffff883cd743dc90] ctl_ioctl at ffffffffa0009dc4 [dm_mod]

The race results in a NULL pointer because:

Process A (vgchange -ay -K):
  a. send DM_LIST_VERSIONS_CMD ioctl;
  b. pool_target not registered;
  c. modprobe dm_thin_pool and wait until end.

Process B (vgchange -ay -K):
  a. send DM_LIST_VERSIONS_CMD ioctl;
  b. pool_target registered;
  c. table_load->dm_table_add_target->pool_ctr;
  d. _new_mapping_cache is NULL and panic.
  1. process A and process B are two concurrent processes.
  2. pool_target can be detected by process B but
  _new_mapping_cache initialization has not ended.

To fix dm-thin-pool, and other targets (cache, multipath, and snapshot)
with the same problem, simply dm_register_target() after all resources
created during module init (as labelled with __init) are finished.

Signed-off-by: monty <>
Signed-off-by: Mike Snitzer <>
[bwh: Backported to 3.2:
 - Drop changes in dm-cache (non-existent) and dm-thin (doesn't have this bug)
 - In dm-snap, reorder cleanup of tracked_chunk_cache too
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agodm mpath: simplify failure path of dm_multipath_init()
Johannes Thumshirn [Sun, 11 Jan 2015 11:45:23 +0000 (12:45 +0100)]
dm mpath: simplify failure path of dm_multipath_init()

commit ff658e9c1aae9a84dd06d46f847dc0cd2bf0dd11 upstream.

Currently the cleanup of all error cases are open-coded.  Introduce a
common exit path and labels.

Signed-off-by: Johannes Thumshirn <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
3 years agobatman-adv: Fix lock for ogm cnt access in batadv_iv_ogm_calc_tq
Sven Eckelmann [Sun, 3 Dec 2017 10:26:45 +0000 (11:26 +0100)]
batman-adv: Fix lock for ogm cnt access in batadv_iv_ogm_calc_tq

commit 5ba7dcfe77037b67016263ea597a8b431692ecab upstream.

The originator node object orig_neigh_node is used to when accessing the
bcast_own(_sum) and real_packet_count information. The access to them has
to be protected with the spinlock in orig_neigh_node.

But the function uses the lock in orig_node instead. This is incorrect
because they could be two different originator node objects.

Fixes: 0ede9f41b217 ("batman-adv: protect bit operations to count OGMs with spinlock")
Signed-off-by: Sven Eckelmann <>
Signed-off-by: Simon Wunderlich <>
[bwh: Backported to 3.2:
 - s/bat_iv\.ogm_cnt_lock/ogm_cnt_lock/
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: usb-audio: Add check return value for usb_string()
Jaejoong Kim [Mon, 4 Dec 2017 06:31:49 +0000 (15:31 +0900)]
ALSA: usb-audio: Add check return value for usb_string()

commit 89b89d121ffcf8d9546633b98ded9d18b8f75891 upstream.

snd_usb_copy_string_desc() returns zero if usb_string() fails.
In case of failure, we need to check the snd_usb_copy_string_desc()'s
return value and add an exception case

Signed-off-by: Jaejoong Kim <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: usb-audio: Fix out-of-bound error
Jaejoong Kim [Mon, 4 Dec 2017 06:31:48 +0000 (15:31 +0900)]
ALSA: usb-audio: Fix out-of-bound error

commit 251552a2b0d454badc8f486e6d79100970c744b0 upstream.

The snd_usb_copy_string_desc() retrieves the usb string corresponding to
the index number through the usb_string(). The problem is that the
usb_string() returns the length of the string (>= 0) when successful, but
it can also return a negative value about the error case or status of

If iClockSource is '0' as shown below, usb_string() will returns -EINVAL.
This will result in '0' being inserted into buf[-22], and the following
KASAN out-of-bound error message will be output.

AudioControl Interface Descriptor:
  bLength                 8
  bDescriptorType        36
  bDescriptorSubtype     10 (CLOCK_SOURCE)
  bClockID                1
  bmAttributes         0x07 Internal programmable Clock (synced to SOF)
  bmControls           0x07
  Clock Frequency Control (read/write)
  Clock Validity Control (read-only)
  bAssocTerminal          0
  iClockSource            0

To fix it, check usb_string()'return value and bail out.

BUG: KASAN: stack-out-of-bounds in parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
Write of size 1 at addr ffff88007e66735a by task systemd-udevd/18376

CPU: 0 PID: 18376 Comm: systemd-udevd Not tainted 4.13.0+ #3
Hardware name: LG Electronics                   15N540-RFLGL/White Tip Mountain, BIOS 15N5
Call Trace:
? parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
? save_stack+0xb5/0xd0
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
? kasan_kmalloc+0xad/0xe0
? kmem_cache_alloc_trace+0xff/0x230
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? usb_probe_interface+0x1f5/0x440
? driver_probe_device+0x3ed/0x660
? build_feature_ctl+0xb10/0xb10 [snd_usb_audio]
? save_stack_trace+0x1b/0x20
? init_object+0x69/0xa0
? snd_usb_find_csint_desc+0xa8/0xf0 [snd_usb_audio]
snd_usb_mixer_controls+0x1dc/0x370 [snd_usb_audio]
? build_audio_procunit+0x890/0x890 [snd_usb_audio]
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? kmem_cache_alloc_trace+0xff/0x230
? usb_ifnum_to_if+0xbd/0xf0
snd_usb_create_mixer+0x25b/0x4b0 [snd_usb_audio]
? snd_usb_create_stream+0x255/0x2c0 [snd_usb_audio]
usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? snd_usb_autosuspend.part.7+0x30/0x30 [snd_usb_audio]
? __pm_runtime_idle+0x90/0x90
? kernfs_activate+0xa6/0xc0
? usb_match_one_id_intf+0xdc/0x130
? __pm_runtime_set_status+0x2d4/0x450

Signed-off-by: Jaejoong Kim <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoxhci: Don't show incorrect WARN message about events for empty rings
Mathias Nyman [Fri, 1 Dec 2017 11:41:19 +0000 (13:41 +0200)]
xhci: Don't show incorrect WARN message about events for empty rings

commit e4ec40ec4b260efcca15089de4285a0a3411259b upstream.

xHC can generate two events for a short transfer if the short TRB and
last TRB in the TD are not the same TRB.

The driver will handle the TD after the first short event, and remove
it from its internal list. Driver then incorrectly prints a warning
for the second event:

"WARN Event TRB for slot x ep y with no TDs queued"

Fix this by not printing a warning if we get a event on a empty list
if the previous event was a short event.

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agocan: ti_hecc: Fix napi poll return value for repoll
Oliver Stäbler [Mon, 20 Nov 2017 13:45:15 +0000 (14:45 +0100)]
can: ti_hecc: Fix napi poll return value for repoll

commit f6c23b174c3c96616514827407769cbcfc8005cf upstream.

After commit d75b1ade567f ("net: less interrupt masking in NAPI") napi
repoll is done only when work_done == budget.
So we need to return budget if there are still packets to receive.

Signed-off-by: Oliver Stäbler <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
3 years agomedia: dvb: i2c transfers over usb cannot be done from stack
Laurent Caumont [Sat, 11 Nov 2017 17:44:46 +0000 (12:44 -0500)]
media: dvb: i2c transfers over usb cannot be done from stack

commit 6d33377f2abbf9f0e561b116dd468d1c3ff36a6a upstream.

Signed-off-by: Laurent Caumont <>
Signed-off-by: Sean Young <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: Remove spurious WARN_ON() at timer check
Takashi Iwai [Thu, 30 Nov 2017 09:08:28 +0000 (10:08 +0100)]
ALSA: seq: Remove spurious WARN_ON() at timer check

commit 43a3542870328601be02fcc9d27b09db467336ef upstream.

The use of snd_BUG_ON() in ALSA sequencer timer may lead to a spurious
WARN_ON() when a slave timer is deployed as its backend and a
corresponding master timer stops meanwhile.  The symptom was triggered
by syzkaller spontaneously.

Since the NULL timer is valid there, rip off snd_BUG_ON().

Reported-by: syzbot <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoeeprom: at24: check at24_read/write arguments
Heiner Kallweit [Fri, 24 Nov 2017 06:47:50 +0000 (07:47 +0100)]
eeprom: at24: check at24_read/write arguments

commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream.

So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.

Signed-off-by: Heiner Kallweit <>
Signed-off-by: Bartosz Golaszewski <>
Signed-off-by: Ben Hutchings <>
3 years agonet/packet: fix a race in packet_bind() and packet_notifier()
Eric Dumazet [Tue, 28 Nov 2017 16:03:30 +0000 (08:03 -0800)]
net/packet: fix a race in packet_bind() and packet_notifier()

commit 15fe076edea787807a7cdc168df832544b58eba6 upstream.

syzbot reported crashes [1] and provided a C repro easing bug hunting.

When/if packet_do_bind() calls __unregister_prot_hook() and releases
po->bind_lock, another thread can run packet_notifier() and process an
NETDEV_UP event.

This calls register_prot_hook() and hooks again the socket right before
first thread is able to grab again po->bind_lock.

Fixes this issue by temporarily setting po->num to 0, as suggested by
David Miller.

dev_remove_pack: ffff8801bf16fa80 not found
------------[ cut here ]------------
kernel BUG at net/core/dev.c:7945!  ( BUG_ON(!list_empty(&dev->ptype_all)); )
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
device syz0 entered promiscuous mode
CPU: 0 PID: 3161 Comm: syzkaller404108 Not tainted 4.14.0+ #190
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cc57a500 task.stack: ffff8801cc588000
RIP: 0010:netdev_run_todo+0x772/0xae0 net/core/dev.c:7945
RSP: 0018:ffff8801cc58f598 EFLAGS: 00010293
RAX: ffff8801cc57a500 RBX: dffffc0000000000 RCX: ffffffff841f75b2
RDX: 0000000000000000 RSI: 1ffff100398b1ede RDI: ffff8801bf1f8810
device syz0 entered promiscuous mode
RBP: ffff8801cc58f898 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801bf1f8cd8
R13: ffff8801cc58f870 R14: ffff8801bf1f8780 R15: ffff8801cc58f7f0
FS:  0000000001716880(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020b13000 CR3: 0000000005e25000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:106
 tun_detach drivers/net/tun.c:670 [inline]
 tun_chr_close+0x49/0x60 drivers/net/tun.c:2845
 __fput+0x333/0x7f0 fs/file_table.c:210
 ____fput+0x15/0x20 fs/file_table.c:244
 task_work_run+0x199/0x270 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x9bb/0x1ae0 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 SYSC_exit_group kernel/exit.c:979 [inline]
 SyS_exit_group+0x1d/0x20 kernel/exit.c:977
RIP: 0033:0x44ad19

Fixes: 30f7ea1c2b5f ("packet: race condition in packet_bind")
Signed-off-by: Eric Dumazet <>
Reported-by: syzbot <>
Cc: Francesco Ruggeri <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
3 years agoisa: Prevent NULL dereference in isa_bus driver callbacks
William Breathitt Gray [Wed, 8 Nov 2017 15:23:11 +0000 (10:23 -0500)]
isa: Prevent NULL dereference in isa_bus driver callbacks

commit 5a244727f428a06634f22bb890e78024ab0c89f3 upstream.

The isa_driver structure for an isa_bus device is stored in the device
platform_data member of the respective device structure. This
platform_data member may be reset to NULL if isa_driver match callback
for the device fails, indicating a device unsupported by the ISA driver.

This patch fixes a possible NULL pointer dereference if one of the
isa_driver callbacks to attempted for an unsupported device. This error
should not occur in practice since ISA devices are typically manually
configured and loaded by the users, but we may as well prevent this
error from popping up for the 0day testers.

Fixes: a5117ba7da37 ("[PATCH] Driver model: add ISA bus")
Signed-off-by: William Breathitt Gray <>
Acked-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoserial: 8250_pci: Add Amazon PCI serial device ID
Matt Wilson [Mon, 13 Nov 2017 19:31:31 +0000 (11:31 -0800)]
serial: 8250_pci: Add Amazon PCI serial device ID

commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.

This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).


Signed-off-by: Matt Wilson <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agoUSB: core: Add type-specific length check of BOS descriptors
Masakazu Mokuno [Thu, 9 Nov 2017 16:25:50 +0000 (01:25 +0900)]
USB: core: Add type-specific length check of BOS descriptors

commit 81cf4a45360f70528f1f64ba018d61cb5767249a upstream.

As most of BOS descriptors are longer in length than their header
'struct usb_dev_cap_header', comparing solely with it is not sufficient
to avoid out-of-bounds access to BOS descriptors.

This patch adds descriptor type specific length check in
usb_get_bos_descriptor() to fix the issue.

Signed-off-by: Masakazu Mokuno <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop handling of USB_PTM_CAP_TYPE and USB_SSP_CAP_TYPE
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agousb: host: fix incorrect updating of offset
Colin Ian King [Tue, 7 Nov 2017 16:45:04 +0000 (16:45 +0000)]
usb: host: fix incorrect updating of offset

commit 1d5a31582ef046d3b233f0da1a68ae26519b2f0a upstream.

The variable temp is incorrectly being updated, instead it should
be offset otherwise the loop just reads the same capability value
and loops forever.  Thanks to Alan Stern for pointing out the
correct fix to my original fix.  Fix also cleans up clang warning:

drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp'
is never read

Fixes: d49d43174400 ("USB: misc ehci updates")
Signed-off-by: Colin Ian King <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: usbfs: Filter flags passed in from user space
Oliver Neukum [Thu, 23 Nov 2017 15:39:52 +0000 (16:39 +0100)]
USB: usbfs: Filter flags passed in from user space

commit 446f666da9f019ce2ffd03800995487e79a91462 upstream.

USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints.
Improve sanity checking.

Reported-by: Andrey Konovalov <>
Signed-off-by: Oliver Neukum <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agohwmon: (pmbus) Use 64bit math for DIRECT format values
Robert Lippert [Mon, 27 Nov 2017 23:51:55 +0000 (15:51 -0800)]
hwmon: (pmbus) Use 64bit math for DIRECT format values

commit bd467e4eababe4c04272c1e646f066db02734c79 upstream.

Power values in the 100s of watt range can easily blow past
32bit math limits when processing everything in microwatts.

Use 64bit math instead to avoid these issues on common 32bit ARM
BMC platforms.

Fixes: 442aba78728e ("hwmon: PMBus device driver")
Signed-off-by: Robert Lippert <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2: use integer literals instead of S16_{MIN,MAX}]
Signed-off-by: Ben Hutchings <>
3 years agoKVM: apic: fix LDR calculation in x2apic mode
Gleb Natapov [Sun, 14 Oct 2012 11:08:58 +0000 (13:08 +0200)]
KVM: apic: fix LDR calculation in x2apic mode

commit 7f46ddbd487e0d0528d89534fdfb31d885977804 upstream.

Signed-off-by: Gleb Natapov <>
Reviewed-by: Chegu Vinod <>
Tested-by: Chegu Vinod <>
Signed-off-by: Avi Kivity <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: option: add Quectel BG96 id
Sebastian Sjoholm [Mon, 20 Nov 2017 18:29:32 +0000 (19:29 +0100)]
USB: serial: option: add Quectel BG96 id

commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.

Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.

Signed-off-by: Sebastian Sjoholm <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
3 years agoInput: elantech - add new icbody type 15
Aaron Ma [Sun, 26 Nov 2017 00:48:41 +0000 (16:48 -0800)]
Input: elantech - add new icbody type 15

commit 10d900303f1c3a821eb0bef4e7b7ece16768fba4 upstream.

The touchpad of Lenovo Thinkpad L480 reports it's version as 15.

Signed-off-by: Aaron Ma <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
3 years agoscsi: libsas: align sata_device's rps_resp on a cacheline
Huacai Chen [Tue, 21 Nov 2017 13:23:39 +0000 (14:23 +0100)]
scsi: libsas: align sata_device's rps_resp on a cacheline

commit c2e8fbf908afd81ad502b567a6639598f92c9b9d upstream.

The rps_resp buffer in ata_device is a DMA target, but it isn't
explicitly cacheline aligned. Due to this, adjacent fields can be
overwritten with stale data from memory on non-coherent architectures.
As a result, the kernel is sometimes unable to communicate with an SATA
device behind a SAS expander.

Fix this by ensuring that the rps_resp buffer is cacheline aligned.

This issue is similar to that fixed by Commit 84bda12af31f93 ("libata:
align ap->sector_buf") and Commit 4ee34ea3a12396f35b26 ("libata: Align
ata_device's id on a cacheline").

Signed-off-by: Huacai Chen <>
Signed-off-by: Christoph Hellwig <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agolibsas: remove unused ata_task_resp fields
Dan Williams [Fri, 18 Nov 2011 01:59:45 +0000 (17:59 -0800)]
libsas: remove unused ata_task_resp fields

commit 95ac7fd189b7e81a200b4d00b2bb6669b31acf3a upstream.

Commit 1e34c838 "[SCSI] libsas: remove spurious sata control register
read/write" removed the routines to fake the presence of the sata
control registers, now remove the unused data structure fields to kill
any remaining confusion.

Acked-by: Jack Wang <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoscsi: use dma_get_cache_alignment() as minimum DMA alignment
Huacai Chen [Tue, 21 Nov 2017 13:23:38 +0000 (14:23 +0100)]
scsi: use dma_get_cache_alignment() as minimum DMA alignment

commit 90addc6b3c9cda0146fbd62a08e234c2b224a80c upstream.

In non-coherent DMA mode, kernel uses cache flushing operations to
maintain I/O coherency, so scsi's block queue should be aligned to the
value returned by dma_get_cache_alignment().  Otherwise, If a DMA buffer
and a kernel structure share a same cache line, and if the kernel
structure has dirty data, cache_invalidate (no writeback) will cause
data corruption.

Signed-off-by: Huacai Chen <>
[hch: rebased and updated the comment and changelog]
Signed-off-by: Christoph Hellwig <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoscsi: dma-mapping: always provide dma_get_cache_alignment
Christoph Hellwig [Tue, 21 Nov 2017 13:23:37 +0000 (14:23 +0100)]
scsi: dma-mapping: always provide dma_get_cache_alignment

commit 860dd4424f344400b491b212ee4acb3a358ba9d9 upstream.

Provide the dummy version of dma_get_cache_alignment that always returns
1 even if CONFIG_HAS_DMA is not set, so that drivers and subsystems can
use it without ifdefs.

Signed-off-by: Christoph Hellwig <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: Also delete the conflicting declaration in
Signed-off-by: Ben Hutchings <>
3 years agobtrfs: clear space cache inode generation always
Josef Bacik [Fri, 17 Nov 2017 19:50:46 +0000 (14:50 -0500)]
btrfs: clear space cache inode generation always

commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream.

We discovered a box that had double allocations, and suspected the space
cache may be to blame.  While auditing the write out path I noticed that
if we've already setup the space cache we will just carry on.  This
means that any error we hit after cache_save_setup before we go to
actually write the cache out we won't reset the inode generation, so
whatever was already written will be considered correct, except it'll be
stale.  Fix this by _always_ resetting the generation on the block group
inode, this way we only ever have valid or invalid cache.

With this patch I was no longer able to reproduce cache corruption with
dm-log-writes and my bpf error injection tool.

Signed-off-by: Josef Bacik <>
Signed-off-by: David Sterba <>
Signed-off-by: Ben Hutchings <>
3 years agoiommu/vt-d: Fix scatterlist offset handling
Robin Murphy [Thu, 28 Sep 2017 14:14:01 +0000 (15:14 +0100)]
iommu/vt-d: Fix scatterlist offset handling

commit 29a90b70893817e2f2bb3cea40a29f5308e21b21 upstream.

The intel-iommu DMA ops fail to correctly handle scatterlists where
sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
appropriately based on the page-aligned portion of the offset, but the
mapping is set up relative to sg->page, which means it fails to actually
cover the whole buffer (and in the worst case doesn't cover it at all):

    (sg->dma_address + sg->dma_len) ----+
    sg->dma_address ---------+          |
    iov_pfn------+           |          |
                 |           |          |
                 v           v          v
iova:   a        b        c        d        e        f
pfn:    0        1        2        3        4        5
                 ^           ^          ^
                 |           |          |
    sg->page ----+           |          |
    sg->offset --------------+          |
    (sg->offset + sg->length) ----------+

As a result, the caller ends up overrunning the mapping into whatever
lies beyond, which usually goes badly:

[  429.645492] DMAR: DRHD: handling fault status reg 2
[  429.650847] DMAR: [DMA Write] Request device [02:00.4] fault addr f2682000 ...

Whilst this is a fairly rare occurrence, it can happen from the result
of intermediate scatterlist processing such as scatterwalk_ffwd() in the
crypto layer. Whilst that particular site could be fixed up, it still
seems worthwhile to bring intel-iommu in line with other DMA API
implementations in handling this robustly.

To that end, fix the intel_map_sg() path to line up the mapping
correctly (in units of MM pages rather than VT-d pages to match the
aligned_nrpages() calculation) regardless of the offset, and use
sg_phys() consistently for clarity.

Reported-by: Harsh Jain <>
Signed-off-by: Robin Murphy <>
Reviewed by: Ashok Raj <>
Tested by: Jacob Pan <>
Signed-off-by: Alex Williamson <>
Signed-off-by: Ben Hutchings <>
3 years agoKVM: x86: Don't re-execute instruction when not passing CR2 value
Liran Alon [Sun, 5 Nov 2017 14:56:34 +0000 (16:56 +0200)]
KVM: x86: Don't re-execute instruction when not passing CR2 value

commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 upstream.

In case of instruction-decode failure or emulation failure,
x86_emulate_instruction() will call reexecute_instruction() which will
attempt to use the cr2 value passed to x86_emulate_instruction().
However, when x86_emulate_instruction() is called from
emulate_instruction(), cr2 is not passed (passed as 0) and therefore
it doesn't make sense to execute reexecute_instruction() logic at all.

Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction")

Signed-off-by: Liran Alon <>
Reviewed-by: Nikita Leshenko <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Reviewed-by: Wanpeng Li <>
Signed-off-by: Radim Krčmář <>
Signed-off-by: Ben Hutchings <>
3 years agoKVM: VMX: do not try to reexecute failed instruction while emulating invalid guest...
Gleb Natapov [Thu, 11 Apr 2013 09:10:51 +0000 (12:10 +0300)]
KVM: VMX: do not try to reexecute failed instruction while emulating invalid guest state

commit 991eebf9f8e523e7ff1e4d31ac80641582b2e57a upstream.

During invalid guest state emulation vcpu cannot enter guest mode to try
to reexecute instruction that emulator failed to emulate, so emulation
will happen again and again.  Prevent that by telling the emulator that
instruction reexecution should not be attempted.

Signed-off-by: Gleb Natapov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: Fix regression by incorrect ioctl_mutex usages
Takashi Iwai [Mon, 19 Feb 2018 16:16:01 +0000 (17:16 +0100)]
ALSA: seq: Fix regression by incorrect ioctl_mutex usages

This is the revised backport of the upstream commit

We had another backport (e.g. 623e5c8ae32b in 4.4.115), but it applies
the new mutex also to the code paths that are invoked via faked
kernel-to-kernel ioctls.  As reported recently, this leads to a
deadlock at suspend (or other scenarios triggering the kernel
sequencer client).

This patch addresses the issue by taking the mutex only in the code
paths invoked by user-space, just like the original fix patch does.

Reported-and-tested-by: Andres Bertens <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoLinux 3.2.99
Ben Hutchings [Tue, 13 Feb 2018 18:32:25 +0000 (18:32 +0000)]
Linux 3.2.99

3 years agokaiser: Set _PAGE_NX only if supported
Lepton Wu [Tue, 16 Jan 2018 14:19:14 +0000 (15:19 +0100)]
kaiser: Set _PAGE_NX only if supported

This finally resolve crash if loaded under qemu + haxm. Haitao Shan pointed
out that the reason of that crash is that NX bit get set for page tables.
It seems we missed checking if _PAGE_NX is supported in kaiser_add_user_map

Reviewed-by: Guenter Roeck <>
Signed-off-by: Lepton Wu <>
Signed-off-by: Greg Kroah-Hartman <>
(backported from Greg K-H's 4.4 stable-queue)
Signed-off-by: Juerg Haefliger <>
Signed-off-by: Ben Hutchings <>
3 years agokaiser: Set _PAGE_NX only if supported
Guenter Roeck [Tue, 16 Jan 2018 14:19:13 +0000 (15:19 +0100)]
kaiser: Set _PAGE_NX only if supported

This resolves a crash if loaded under qemu + haxm under windows.
See for details.
Here is a boot log (the log is from chromeos-4.4, but Tao Wu says that
the same log is also seen with vanilla v4.4.110-rc1).

[    0.712750] Freeing unused kernel memory: 552K
[    0.721821] init: Corrupted page table at address 57b029b332e0
[    0.722761] PGD 80000000bb238067 PUD bc36a067 PMD bc369067 PTE 45d2067
[    0.722761] Bad pagetable: 000b [#1] PREEMPT SMP
[    0.722761] Modules linked in:
[    0.722761] CPU: 1 PID: 1 Comm: init Not tainted 4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
[    0.722761] task: ffff8800bc290000 ti: ffff8800bc28c000 task.ti: ffff8800bc28c000
[    0.722761] RIP: 0010:[<ffffffff83f4129e>]  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761] RSP: 0000:ffff8800bc28fcf8  EFLAGS: 00010202
[    0.722761] RAX: 0000000000000000 RBX: 00000000000001a4 RCX: 00000000000001a4
[    0.722761] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000057b029b332e0
[    0.722761] RBP: ffff8800bc28fd08 R08: ffff8800bc290000 R09: ffff8800bb2f4000
[    0.722761] R10: ffff8800bc290000 R11: ffff8800bb2f4000 R12: 000057b029b332e0
[    0.722761] R13: 0000000000000000 R14: 000057b029b33340 R15: ffff8800bb1e2a00
[    0.722761] FS:  0000000000000000(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
[    0.722761] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.722761] CR2: 000057b029b332e0 CR3: 00000000bb2f8000 CR4: 00000000000006e0
[    0.722761] Stack:
[    0.722761]  000057b029b332e0 ffff8800bb95fa80 ffff8800bc28fd18 ffffffff83f4120c
[    0.722761]  ffff8800bc28fe18 ffffffff83e9e7a1 ffff8800bc28fd68 0000000000000000
[    0.722761]  ffff8800bc290000 ffff8800bc290000 ffff8800bc290000 ffff8800bc290000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.722761]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.722761]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.722761]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.722761]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.722761]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.722761]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761] Code: 86 84 be 12 00 00 00 e8 87 0d e8 ff 66 66 90 48 89 d8 48 c1
eb 03 4c 89 e7 83 e0 07 48 89 d9 be 08 00 00 00 31 d2 48 85 c9 74 0a <48> 89 17
48 01 f7 ff c9 75 f6 48 89 c1 85 c9 74 09 88 17 48 ff
[    0.722761] RIP  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761]  RSP <ffff8800bc28fcf8>
[    0.722761] ---[ end trace def703879b4ff090 ]---
[    0.722761] BUG: sleeping function called from invalid context at /mnt/host/source/src/third_party/kernel/v4.4/kernel/locking/rwsem.c:21
[    0.722761] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[    0.722761] CPU: 1 PID: 1 Comm: init Tainted: G      D         4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
[    0.722761]  0000000000000086 dcb5d76098c89836 ffff8800bc28fa30 ffffffff83f34004
[    0.722761]  ffffffff84839dc2 0000000000000015 ffff8800bc28fa40 ffffffff83d57dc9
[    0.722761]  ffff8800bc28fa68 ffffffff83d57e6a ffffffff84a53640 0000000000000000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f34004>] dump_stack+0x4d/0x63
[    0.722761]  [<ffffffff83d57dc9>] ___might_sleep+0x13a/0x13c
[    0.722761]  [<ffffffff83d57e6a>] __might_sleep+0x9f/0xa6
[    0.722761]  [<ffffffff84502788>] down_read+0x20/0x31
[    0.722761]  [<ffffffff83cc5d9b>] __blocking_notifier_call_chain+0x35/0x63
[    0.722761]  [<ffffffff83cc5ddd>] blocking_notifier_call_chain+0x14/0x16
[    0.800374] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    0.722761]  [<ffffffff83cefe97>] profile_task_exit+0x1a/0x1c
[    0.802309]  [<ffffffff83cac84e>] do_exit+0x39/0xe7f
[    0.802309]  [<ffffffff83ce5938>] ? vprintk_default+0x1d/0x1f
[    0.802309]  [<ffffffff83d7bb95>] ? printk+0x57/0x73
[    0.802309]  [<ffffffff83c46e25>] oops_end+0x80/0x85
[    0.802309]  [<ffffffff83c7b747>] pgtable_bad+0x8a/0x95
[    0.802309]  [<ffffffff83ca7f4a>] __do_page_fault+0x8c/0x352
[    0.802309]  [<ffffffff83eefba5>] ? file_has_perm+0xc4/0xe5
[    0.802309]  [<ffffffff83ca821c>] do_page_fault+0xc/0xe
[    0.802309]  [<ffffffff84507682>] page_fault+0x22/0x30
[    0.802309]  [<ffffffff83f4129e>] ? __clear_user+0x42/0x67
[    0.802309]  [<ffffffff83f4127f>] ? __clear_user+0x23/0x67
[    0.802309]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.802309]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.802309]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.802309]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.802309]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.802309]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.802309]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.802309]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.830559] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009
[    0.830559]
[    0.831305] Kernel Offset: 0x2c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.831305] ---[ end Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009

The crash part of this problem may be solved with the following patch
(thanks to Hugh for the hint). There is still another problem, though -
with this patch applied, the qemu session aborts with "VCPU Shutdown
request", whatever that means.

Cc: lepton <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
(cherry picked from commit b33c3c64c4786cd724ccde6fa97c87ada49f6a73 linux-4.4.y)
Signed-off-by: Juerg Haefliger <>
Signed-off-by: Ben Hutchings <>
3 years agocx231xx: Fix the max number of interfaces
Mauro Carvalho Chehab [Sun, 27 Jul 2014 19:27:27 +0000 (16:27 -0300)]
cx231xx: Fix the max number of interfaces

commit 139d28826b8e2bc7a9232fde0d2f14812914f501 upstream.

The max number of interfaces was read from the wrong descriptor.

Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agousbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
Shuah Khan [Thu, 7 Dec 2017 21:16:50 +0000 (14:16 -0700)]
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer

commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream.

stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.

Reported-by: Secunia Research <>
Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Device for logging purposes is &sdev->interface->dev
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agousbip: prevent vhci_hcd driver from leaking a socket pointer address
Shuah Khan [Thu, 7 Dec 2017 21:16:49 +0000 (14:16 -0700)]
usbip: prevent vhci_hcd driver from leaking a socket pointer address

commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream.

When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the

/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.

Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.

As this opens a security hole, the fix replaces socket pointer address with

Reported-by: Secunia Research <>
Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - usbip port status does not include hub type
 - Adjust filenames, context, indentation]
Signed-off-by: Ben Hutchings <>
3 years agousbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
Shuah Khan [Thu, 7 Dec 2017 21:16:48 +0000 (14:16 -0700)]
usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input

commit c6688ef9f29762e65bce325ef4acd6c675806366 upstream.

Harden CMD_SUBMIT path to handle malicious input that could trigger
large memory allocations. Add checks to validate transfer_buffer_length
and number_of_packets to protect against bad input requesting for
unbounded memory allocations. Validate early in get_pipe() and return

Reported-by: Secunia Research <>
Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Device for logging purposes is &sdev->interface->dev
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: fix stub_rx: get_pipe() to validate endpoint number
Shuah Khan [Thu, 7 Dec 2017 21:16:47 +0000 (14:16 -0700)]
usbip: fix stub_rx: get_pipe() to validate endpoint number

commit 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 upstream.

get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().

Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.

Reported-by: Secunia Research <>
Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agousb: add helper to extract bits 12:11 of wMaxPacketSize
Felipe Balbi [Mon, 26 Sep 2016 07:51:18 +0000 (10:51 +0300)]
usb: add helper to extract bits 12:11 of wMaxPacketSize

commit 541b6fe63023f3059cf85d47ff2767a3e42a8e44 upstream.

According to USB Specification 2.0 table 9-4,
wMaxPacketSize is a bitfield. Endpoint's maxpacket
is laid out in bits 10:0. For high-speed,
high-bandwidth isochronous endpoints, bits 12:11
contain a multiplier to tell us how many
transactions we want to try per uframe.

This means that if we want an isochronous endpoint
to issue 3 transfers of 1024 bytes per uframe,
wMaxPacketSize should contain the value:

1024 | (2 << 11)

or 5120 (0x1400). In order to make Host and
Peripheral controller drivers' life easier, we're
adding a helper which returns bits 12:11. Note that
no care is made WRT to checking endpoint type and
gadget's speed. That's left for drivers to handle.

Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agousbip: Fix sscanf handling
Alan [Wed, 11 Dec 2013 18:32:59 +0000 (18:32 +0000)]
usbip: Fix sscanf handling

commit 2d32927127f44d755780aa5fa88c8c34e72558f8 upstream.

Scan only to the length permitted by the buffer

One of a set of sscanf problems noted by Jackie Chang

Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agostaging: usbip: removed #if 0'd out code
Bart Westgeest [Mon, 23 Jan 2012 15:55:47 +0000 (10:55 -0500)]
staging: usbip: removed #if 0'd out code

commit 34c09578179f5838e5958c45e8aed4edc9c6c3b8 upstream.

Signed-off-by: Bart Westgeest <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: Make ioctls race-free
Takashi Iwai [Tue, 9 Jan 2018 22:11:03 +0000 (23:11 +0100)]
ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

Reported-by: Luo Quan <>
Reviewed-by: Kees Cook <>
Reviewed-by: Greg Kroah-Hartman <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <>
3 years agoRDS: null pointer dereference in rds_atomic_free_op
Mohamed Ghannam [Wed, 3 Jan 2018 21:06:06 +0000 (21:06 +0000)]
RDS: null pointer dereference in rds_atomic_free_op

commit 7d11f77f84b27cef452cee332f4e469503084737 upstream.

set rm->atomic.op_active to 0 when rds_pin_pages() fails
or the user supplied address is invalid,
this prevents a NULL pointer usage in rds_atomic_free_op()

Signed-off-by: Mohamed Ghannam <>
Acked-by: Santosh Shilimkar <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoRDS: Heap OOB write in rds_message_alloc_sgs()
Mohamed Ghannam [Tue, 2 Jan 2018 19:44:34 +0000 (19:44 +0000)]
RDS: Heap OOB write in rds_message_alloc_sgs()

commit c095508770aebf1b9218e77026e48345d719b17c upstream.

When args->nr_local is 0, nr_pages gets also 0 due some size
calculation via rds_rm_size(), which is later used to allocate
pages for DMA, this bug produces a heap Out-Of-Bound write access
to a specific memory region.

Signed-off-by: Mohamed Ghannam <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: xt_TCPMSS: add more sanity tests on tcph->doff
Eric Dumazet [Mon, 3 Apr 2017 17:55:11 +0000 (10:55 -0700)]
netfilter: xt_TCPMSS: add more sanity tests on tcph->doff

commit 2638fd0f92d4397884fd991d8f4925cb3f081901 upstream.

Denys provided an awesome KASAN report pointing to an use
after free in xt_TCPMSS

I have provided three patches to fix this issue, either in xt_TCPMSS or
in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible

Signed-off-by: Eric Dumazet <>
Reported-by: Denys Fedoryshchenko <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: xt_TCPMSS: correct return value in tcpmss_mangle_packet
Phil Oester [Sun, 1 Sep 2013 15:32:21 +0000 (08:32 -0700)]
netfilter: xt_TCPMSS: correct return value in tcpmss_mangle_packet

commit 1205e1fa615805c9efa97303b552cf445965752a upstream.

In commit b396966c4 (netfilter: xt_TCPMSS: Fix missing fragmentation handling),
I attempted to add safe fragment handling to xt_TCPMSS.  However, Andy Padavan
of Project N56U correctly points out that returning XT_CONTINUE in this
function does not work.  The callers (tcpmss_tg[46]) expect to receive a value
of 0 in order to return XT_CONTINUE.

Signed-off-by: Phil Oester <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: xt_TCPMSS: fix handling of malformed TCP header and options
Pablo Neira Ayuso [Thu, 25 Jul 2013 08:37:49 +0000 (10:37 +0200)]
netfilter: xt_TCPMSS: fix handling of malformed TCP header and options

commit 71ffe9c77dd7a2b62207953091efa8dafec958dd upstream.

Make sure the packet has enough room for the TCP header and
that it is not malformed.

While at it, store tcph->doff*4 in a variable, as it is used
several times.

This patch also fixes a possible off by one in case of malformed
TCP options.

Reported-by: Julian Anastasov <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>