- 07 Jun, 2018 40 commits
-
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 2b63f132 upstream. musb_start_urb() doesn't check the pass-in parameter if it is NULL. But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is returned from first_qh(), which could be NULL. So wrap the musb_start_urb() call here with a if condition check to avoid the potential NULL pointer dereference. Fixes: f283862f ("usb: musb: NAK timeout scheme on bulk TX endpoint") Cc: stable@vger.kernel.org # v3.7+ Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
SZ Lin (林上智) authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 4205cb01 upstream. This patch adds support for ublox R410M PID 0x90b2 USB modem to option driver, this module supports LTE Cat M1 / NB1. Interface layout: 0: QCDM/DIAG 1: ADB 2: AT 3: RMNET Signed-off-by:
SZ Lin (林上智) <sz.lin@moxa.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit c3a65808 upstream. Reimplement interface masking using device flags stored directly in the device-id table. This will make it easier to add and maintain device-id entries by using a more compact and readable notation compared to the current implementation (which manages pairs of masks in separate blacklist structs). Two convenience macros are used to flag an interface as either reserved or as not supporting modem-control requests: { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM), .driver_info = NCTRL(0) | RSVD(3) }, For now, we limit the highest maskable interface number to seven, which allows for (up to 16) additional device flags to be added later should need arise. Note that this will likely need to be backported to stable in order to make future device-id backports more manageable. Reviewed-by:
-
Alan Stern authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit fb5ee84e upstream. Some non-compliant high-speed USB devices have bulk endpoints with a 1024-byte maxpacket size. Although such endpoints don't work with xHCI host controllers, they do work with EHCI controllers. We used to accept these invalid sizes (with a warning), but we no longer do because of an unintentional change introduced by commit aed9d65a ("USB: validate wMaxPacketValue entries in endpoint descriptors"). This patch restores the old behavior, so that people with these peculiar devices can use them without patching their kernels by hand. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Suggested-by:
Elvinas <elvinas@veikia.lt> Fixes: aed9d65a ("USB: validate wMaxPacketValue entries in endpoint descriptors") CC: <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 4842ed5b upstream. If we get an invalid device configuration from a palm 3 type device, we might incorrectly parse things, and we have the potential to crash in "interesting" ways. Fix this up by verifying the size of the configuration passed to us by the device, and only if it is correct, will we handle it. Note that this also fixes an information leak of slab data. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Reviewed-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit e5384092 upstream. Commit 65c79230 tried to clear the custom firmware path on exit by writing a single space to the firmware_class.path parameter. This doesn't work because nothing strips this space from the value stored and fw_get_filesystem_firmware() only ignores zero-length paths. Instead, write a null byte. Fixes: 0a8adf58 ("test: add firmware_class loader test") Fixes: 65c79230 ("test_firmware: fix setting old custom fw path back on exit") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Acked-by:
Luis R. Rodriguez <mcgrof@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Thomas Hellstrom authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 13f149d4 upstream. A buffer object leak was introduced when fixing a premature buffer object release. Fix this. Cc: <stable@vger.kernel.org> Fixes: 73a88250 ("Fix a destoy-while-held mutex problem.") Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Deepak Rawat <drawat@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Danit Goldberg authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 4f32ac2e upstream. Before the change, if the user passed a static rate value different than zero and the FW doesn't support static rate, it would end up configuring rate of 2.5 GBps. Fix this by using rate 0; unlimited, in cases where FW doesn't support static rate configuration. Cc: <stable@vger.kernel.org> # 3.10 Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Reviewed-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
Danit Goldberg <danitg@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
SZ Lin (林上智) authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 9306b38e upstream. This patch adds support for PID 0x90b2 of ublox R410M. qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer [/dev/cdc-wdm0] Device manufacturer retrieved: Manufacturer: 'u-blox' qmicli -d /dev/cdc-wdm0 --dms-get-model [/dev/cdc-wdm0] Device model retrieved: Model: 'SARA-R410M-02B' Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Leon Romanovsky authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 002bf228 upstream. Ensure that user didn't supply values too large that can cause overflow. UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:263:23 shift exponent -2147483648 is negative CPU: 0 PID: 292 Comm: syzkaller612609 Not tainted 4.16.0-rc1+ #131 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xde/0x164 ubsan_epilogue+0xe/0x81 set_rq_size+0x7c2/0xa90 create_qp_common+0xc18/0x43c0 mlx5_ib_create_qp+0x379/0x1ca0 create_qp.isra.5+0xc94/0x2260 ib_uverbs_create_qp+0x21b/0x2a0 ib_uverbs_write+0xc2c/0x1010 vfs_write+0x1b0/0x550 SyS_write+0xc7/0x1a0 do_syscall_64+0x1aa/0x740 entry_SYSCALL_64_after_hwframe+0x26/0x9b RIP: 0033:0x433569 RSP: 002b:00007ffc6e62f448 EFLAGS: 00000217 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004002f8 RCX: 0000000000433569 RDX: 0000000000000070 RSI: 00000000200042c0 RDI: 0000000000000003 RBP: 00000000006d5018 R08: 00000000004002f8 R09: 00000000004002f8 R10: 00000000004002f8 R11: 0000000000000217 R12: 0000000000000000 R13: 000000000040c9f0 R14: 000000000040ca80 R15: 0000000000000006 Cc: <stable@vger.kernel.org> # 3.10 Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <syzkaller@googlegroups.com> Reported-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
-
Roland Dreier authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 09abfe7b upstream. The RDMA CM will select a source device and address by consulting the routing table if no source address is passed into rdma_resolve_address(). Userspace will ask for this by passing an all-zero source address in the RESOLVE_IP command. Unfortunately the new check for non-zero address size rejects this with EINVAL, which breaks valid userspace applications. Fix this by explicitly allowing a zero address family for the source. Fixes: 2975d5de ("RDMA/ucma: Check AF family prior resolving address") Cc: <stable@vger.kernel.org> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Darrick J. Wong authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 7d83fb14 upstream. During the "insert range" fallocate operation, i_size grows by the specified 'len' bytes. XFS verifies that i_size + len < s_maxbytes, as it should. But this comparison is done using the signed 'loff_t', and 'i_size + len' can wrap around to a negative value, causing the check to incorrectly pass, resulting in an inode with "negative" i_size. This is possible on 64-bit platforms, where XFS sets s_maxbytes = LLONG_MAX. ext4 and f2fs don't run into this because they set a smaller s_maxbytes. Fix it by using subtraction instead. Reproducer: xfs_io -f file -c "truncate $(((1<<63)-1))" -c "finsert 0 4096" Fixes: a904b1ca ("xfs: Add support FALLOC_FL_INSERT_RANGE for fallocate") Cc: <stable@vger.kernel.org> # v4.1+ Originally-From: Eric Biggers <ebiggers@google.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> [darrick: fix signed integer addition overflow too] Signed-off-by:
-
Vittorio Gambaletta (VittGam) authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit f372b811 upstream. This patch adds the correct platform data information for the Caroline Chromebook, so that the mouse button does not get stuck in pressed state after the first click. The Samus button keymap and platform data definition are the correct ones for Caroline, so they have been reused here. Signed-off-by:
Vittorio Gambaletta <linuxbugs@vittgam.net> Signed-off-by:
Salvatore Bellizzi <lkml@seppia.net> Tested-by:
Guenter Roeck <groeck@chromium.org> Cc: stable@vger.kernel.org [dtor: adjusted vendor spelling to match shipping firmware] Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 6bd6ae63 upstream. UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with led > LED_CHARGING: [ 1274.663418] BUG: KASAN: slab-out-of-bounds in input_leds_connect+0x611/0x730 [input_leds] [ 1274.663426] Write of size 8 at addr ffff88003377b2c0 by task ckb-next-daemon/5128 This happens because we were writing to the led structure before making sure that it exists. Reported-by:
Tasos Sahanidis <tasos@tasossah.com> Tested-by:
-
Mathieu Desnoyers authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit d66a270b upstream. Tracepoint should only warn when a kernel API user does not respect the required preconditions (e.g. same tracepoint enabled twice, or called to remove a tracepoint that does not exist). Silence warning in out-of-memory conditions, given that the error is returned to the caller. This ensures that out-of-memory error-injection testing does not trigger warnings in tracepoint.c, which were seen by syzbot. Link: https://lkml.kernel.org/r/001a114465e241a8720567419a72@google.com Link: https://lkml.kernel.org/r/001a1140e0de15fc910567464190@google.com Link: http://lkml.kernel.org/r/20180315124424.32319-1-mathieu.desnoyers@efficios.com CC: Peter Zijlstra <peterz@infradead.org> CC: Jiri Olsa <jolsa@redhat.com> CC: Arnaldo Carvalho de Melo <acme@kernel.org> CC: Alexander Shishkin <alexander.shishkin@linux.intel.com> CC: Namhyung Kim <namhyung@kernel.org> CC: stable@vger.kernel.org Fixes: de7b2973 ("tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints") Reported-by: syzbot+9c0d616860575a73166a@syzkaller.appspotmail.com Reported-by: syzbot+4e9ae7fa46233396f64d@syzkaller.appspotmail.com Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 76b3421b upstream. Some control API callbacks in aloop driver are too lazy to take the loopback->cable_lock and it results in possible races of cable access while it's being freed. It eventually lead to a UAF, as reported by fuzzer recently. This patch covers such control API callbacks and add the proper mutex locks. Reported-by:
DaeRyong Jeong <threeearcat@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Robert Rosengren authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 306a4f3c upstream. Show paused ALSA aloop device as inactive, i.e. the control "PCM Slave Active" set as false. Notification sent upon state change. This makes it possible for client capturing from aloop device to know if data is expected. Without it the client expects data even if playback is paused. Signed-off-by:
Robert Rosengren <robert.rosengren@axis.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 8f22e525 upstream. The sequencer virmidi code has an open race at its output trigger callback: namely, virmidi keeps only one event packet for processing while it doesn't protect for concurrent output trigger calls. snd_virmidi_output_trigger() tries to process the previously unfinished event before starting encoding the given MIDI stream, but this is done without any lock. Meanwhile, if another rawmidi stream starts the output trigger, this proceeds further, and overwrites the event package that is being processed in another thread. This eventually corrupts and may lead to the invalid memory access if the event type is like SYSEX. The fix is just to move the spinlock to cover both the pending event and the new stream. The bug was spotted by a new fuzzer, RaceFuzzer. BugLink: http://lkml.kernel.org/r/20180426045223.GA15307@dragonet.kaist.ac.krReported-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit f13876e2 upstream. Since snd_pcm_ioctl_xfern_compat() has no PCM state check, it may go further and hit the sanity check pcm_sanity_check() when the ioctl is called right after open. It may eventually spew a kernel warning, as triggered by syzbot, depending on kconfig. The lack of PCM state check there was just an oversight. Although it's no real crash, the spurious kernel warning is annoying, so let's add the proper check. Reported-by: syzbot+1dac3a4f6bc9c1c675d4@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kristian Evensen authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 71a0483d upstream. The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as follows: 0: Diag 1: NMEA 2: AT 3: Modem Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. This patch should also be considered for -stable. The QMI-patch for this modem is already in the -stable-queue. v1->v2: * Updated commit prefix (thanks Johan Hovold) * Updated commit message slightly. Signed-off-by:
Kristian Evensen <kristian.evensen@gmail.com> Acked-by:
-
Markus Pargmann authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit bd2e778c upstream. ECC is only calculated for written pages. As erased pages are not actively written the ECC is always invalid. For this purpose the Hardware BCH unit is able to check for erased pages and does not raise an ECC error in this case. This behaviour can be influenced using the BCH_MODE register which sets the number of allowed bitflips in an erased page. Unfortunately the unit is not capable of fixing the bitflips in memory. To avoid complete software checks for erased pages, we can simply check buffers with uncorrectable ECC errors because we know that any erased page with errors is uncorrectable by the BCH unit. This patch adds the generic nand_check_erased_ecc_chunk() to gpmi-nand to correct erased pages. To have the valid data in the buffer before using them, this patch moves the read_page_swap_end() call before the ECC status checking for-loop. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> [Squashed patches by Stefan and Boris to check ECC area] Tested-by:
Stefan Christ <s.christ@phytec.de> Acked-by:
Han xu <han.xu@nxp.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 7eccb738 upstream. Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by:
Manikanta Pubbisetty <mpubbise@qti.qualcomm.com> Signed-off-by:
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 2f38c3c0 upstream. Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future) rx_hdr_status is not padded to align in 4-byte boundary. Define a new hw_params field to handle different alignment behaviour between different hw. This patch fixes improper retrieval of rfc1042 header with QCA4019. This patch along with "ath10k: Properly remove padding from the start of rx payload" will fix traffic failure in ethernet decap mode for QCA4019. Signed-off-by:
-
David Spinadel authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit cef0acd4 upstream. Add a flag that indicates that the WEP ICV was stripped from an RX packet, allowing the device to not transfer that if it's already checked. Signed-off-by:
David Spinadel <david.spinadel@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Cc: Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Sara Sharon authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit f631a77b upstream. Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV as is to the generated MPDUs, so the same PN appears in multiple packets without being a replay attack. Allow driver to explicitly indicate that a frame is allowed to have the same PN as the previous frame. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Sara Sharon authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit f980ebc0 upstream. When HW crypto is used, there's no need for the CCMP/GCMP MIC to be available to mac80211, and the hardware might have removed it already after checking. The MIC is also useless to have when the frame is already decrypted, so allow indicating that it's not present. Since we are running out of bits in mac80211_rx_flags, make the flags field a u64. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Tejun Heo authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 71546d10 upstream. microblaze build broke due to missing declaration of the cond_resched() invocation added recently. Let's include linux/sched.h explicitly. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Teng Qin authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 8fe45924 upstream. When iterating through a map, we need to find a key that does not exist in the map so map_get_next_key will give us the first key of the map. This often requires a lot of guessing in production systems. This patch makes map_get_next_key return the first key when the key pointer in the parameter is NULL. Signed-off-by:
Teng Qin <qinteng@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Chenbo Feng <fengc@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
-
Tan Xiaojun authored
BugLink: http://bugs.launchpad.net/bugs/1774173 commit 1572e45a upstream. Use "proc_dointvec_minmax" instead of "proc_dointvec" to check the input value from user-space. If not, we can set a big value and some vars will overflow like "sysctl_perf_event_sample_rate" which will cause a lot of unexpected problems. Signed-off-by:
Tan Xiaojun <tanxiaojun@huawei.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: <acme@kernel.org> Cc: <alexander.shishkin@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1487829879-56237-1-git-send-email-tanxiaojun@huawei.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1774181 With the rename of osb() in the previous commit, use barrier_nospec() instead. Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1774181 The x86 barrier macro that landed in upstream is named barrier_nospec() and is an LFENCE/MFENCE alternative. What was added in Ubuntu with the original embargoed patches is named osb() but it's the same thing, so rename it. Also, rename the Ubuntu-specific non-x86 osb() macros and simplify the code to turn barrier_nospec() into a no-op for arches that don't support it. And while we're at it, drop the reporting of osb for x86. It's always enabled and OSB is not a recognizable upstream term and only adds confusion. Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1774181 The original embargoed patches introduced an arch-specific barrier macro gmb() (later renamed to osb()) which is used to prevent speculation beyond array boundaries. What finally landed in upstream is an arch-agnostic masking solution in favor of osb(). In Ubuntu, we still use osb() in a couple of places where upstream does nothing, so change those to using the masking solution. Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 69fa6f19 upstream. As recently Smatch suggested, one place in HD-audio hwdep ioctl codes may expand the array directly from the user-space value with speculation: sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec->wcaps' As get_wcaps() itself is a fairly frequently called inline function, and there is only one single call with a user-space value, we replace only the latter one to open-code locally with array_index_nospec() hardening in this patch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 8d218dd8 upstream. As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 1d91c1d2 upstream. There are multiple problems with the dynamic sanity checking in array_index_nospec_mask_check(): * It causes unnecessary overhead in the 32-bit case since integer sized @index values will no longer cause the check to be compiled away like in the 64-bit case. * In the 32-bit case it may trigger with user controllable input when the expectation is that should only trigger during development of new kernel enabling. * The macro reuses the input parameter in multiple locations which is broken if someone passes an expression like 'index++' to array_index_nospec(). Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/151881604278.17395.6605847763178076520.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 8fa80c50 upstream. For architectures providing their own implementation of array_index_mask_nospec() in asm/barrier.h, attempting to use WARN_ONCE() to complain about out-of-range parameters using WARN_ON() results in a mess of mutually-dependent include files. Rather than unpick the dependencies, simply have the core code in nospec.h perform the checking for us. Signed-off-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1517840166-15399-1-git-send-email-will.deacon@arm.comSigned-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit eb6174f6 upstream. The nospec.h header expects the per-architecture header file <asm/barrier.h> to optionally define array_index_mask_nospec(). Include that dependency to prevent inadvertent fallback to the default array_index_mask_nospec() implementation. The default implementation may not provide a full mitigation on architectures that perform data value speculation. Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 3968523f upstream. mpls_label_ok() validates that the 'platform_label' array index from a userspace netlink message payload is valid. Under speculation the mpls_label_ok() result may not resolve in the CPU pipeline until after the index is used to access an array element. Sanitize the index to zero to prevent userspace-controlled arbitrary out-of-bounds speculation, a precursor for a speculative execution side channel vulnerability. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1774181 In 4.4.118, we have commit c8961332 (x86/syscall: Sanitize syscall table de-references under speculation), which is a backport of upstream commit 2fbd7af5. But it fixed only the C part of the upstream patch -- the IA32 sysentry. So it ommitted completely the assembly part -- the 64bit sysentry. Fix that in this patch by explicit array_index_mask_nospec written in assembly. The same was used in lib/getuser.S. However, to have "sbb" working properly, we have to switch from "cmp" against (NR_syscalls-1) to (NR_syscalls), otherwise the last syscall number would be "and"ed by 0. It is because the original "ja" relies on "CF" or "ZF", but we rely only on "CF" in "sbb". That means: switch to "jae" conditional jump too. Final note: use rcx for mask as this is exactly what is overwritten by the 4th syscall argument (r10) right after. Reported-by:
Jan Beulich <JBeulich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Andy Lutomirski <luto@kernel.org> Cc: alan@linux.intel.com Cc: Jinpu Wang <jinpu.wang@profitbricks.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Rasmus Villemoes authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit b98c6a16 upstream. The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
