- 15 Mar, 2020 22 commits
-
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864774 [ Upstream commit 30780d08 ] With -O3, gcc has found an actual unintialized variable stored into an mmio register in two instances: drivers/atm/eni.c: In function 'discard': drivers/atm/eni.c:465:13: error: 'dma[1]' is used uninitialized in this function [-Werror=uninitialized] writel(dma[i*2+1],eni_dev->rx_dma+dma_wr*8+4); ^ drivers/atm/eni.c:465:13: error: 'dma[3]' is used uninitialized in this function [-Werror=uninitialized] Change the code to always write zeroes instead. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Krzysztof Kozlowski authored
BugLink: https://bugs.launchpad.net/bugs/1864774 [ Upstream commit 00c0688c ] Since net_device.mem_start is unsigned long, it should not be cast to int right before casting to pointer. This fixes warning (compile testing on alpha architecture): drivers/net/wan/sdla.c: In function ‘sdla_transmit’: drivers/net/wan/sdla.c:711:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Fenghua Yu authored
BugLink: https://bugs.launchpad.net/bugs/1864774 [ Upstream commit f11421ba ] Atomic operations that span cache lines are super-expensive on x86 (not just to the current processor, but also to other processes as all memory operations are blocked until the operation completes). Upcoming x86 processors have a switch to cause such operations to generate a #AC trap. It is expected that some real time systems will enable this mode in BIOS. In preparation for this, it is necessary to fix code that may execute atomic instructions with operands that cross cachelines because the #AC trap will crash the kernel. Since "pwol_mask" is local and never exposed to concurrency, there is no need to set bits in pwol_mask using atomic operations. Directly operate on the byte which contains the bit instead of using __set_bit() to avoid any big endian concern due to type cast to unsigned long in __set_bit(). Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Andreas Kemnade authored
BugLink: https://bugs.launchpad.net/bugs/1864774 [ Upstream commit a76dfb85 ] Platform device aliases were missing so module autoloading did not work. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20191213214802.22268-1-andreas@kemnade.infoSigned-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 2d68bb26 upstream. Make sure to use the current alternate setting when verifying the storage interface descriptors to avoid submitting an URB to an invalid endpoint. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: a1030e92 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device") Cc: stable <stable@vger.kernel.org> # 2.6.19 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 39a4281c upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Cc: stable <stable@vger.kernel.org> # 4.4 Cc: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 3428fbcd upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 71bb244b ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets") Cc: stable <stable@vger.kernel.org> # 3.4 Cc: Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 0ef33295 upstream. Make sure to use the current alternate setting when verifying the storage interface descriptors to avoid submitting an URB to an invalid endpoint. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 36bcce43 ("ath9k_htc: Handle storage devices") Cc: stable <stable@vger.kernel.org> # 2.6.39 Signed-off-by:
-
Malcolm Priestley authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 9dd631fa upstream. The driver reporting IEEE80211_TX_STAT_ACK is not being handled correctly. The driver should only report on TSR_TMO flag is not set indicating no transmission errors and when not IEEE80211_TX_CTL_NO_ACK is being requested. Cc: stable <stable@vger.kernel.org> Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Link: https://lore.kernel.org/r/340f1f7f-c310-dca5-476f-abc059b9cd97@gmail.comSigned-off-by:
-
Malcolm Priestley authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit d579c43c upstream. It appears that the drivers does not go into power save correctly the NULL data packets are not being transmitted because it not enabled in mac80211. The driver needs to capture ieee80211_is_nullfunc headers and copy the duration_id to it's own duration data header. Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Malcolm Priestley authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit d971fdd3 upstream. It appears that the driver still transmits in CTS protect mode even though it is not enabled in mac80211. That is both packet types PK_TYPE_11GA and PK_TYPE_11GB both use CTS protect. The only difference between them GA does not use B rates. Find if only B rate in GB or GA in protect mode otherwise transmit packets as PK_TYPE_11A. Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 4cc41cbc upstream. Currently when the call to prism2sta_ifst fails a netdev_err error is reported, error return variable result is set to -1 but the function always returns 0 for success. Fix this by returning the error value in variable result rather than 0. Addresses-Coverity: ("Unused value") Fixes: 00b3ed16 ("Staging: add wlan-ng prism2 usb driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200114181604.390235-1-colin.king@canonical.comSigned-off-by:
-
Andrey Shvetsov authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 4d1356ac upstream. If the length of the socket buffer is 0xFFFFFFFF (max size for an unsigned int), then payload_len becomes 0xFFFFFFF1 after subtracting 14 (ETH_HLEN). Then, mdp_len is set to payload_len + 16 (MDP_HDR_LEN) which overflows and results in a value of 2. These values for payload_len and mdp_len will pass current buffer size checks. This patch checks if derived from skb->len sum may overflow. The check is based on the following idea: For any `unsigned V1, V2` and derived `unsigned SUM = V1 + V2`, `V1 + V2` overflows iif `SUM < V1`. Reported-by:
Andrey Shvetsov <andrey.shvetsov@k2l.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200116172238.6046-1-andrey.shvetsov@microchip.comSigned-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 38c0d5bd upstream. Commit f4a4cbb2 ("USB: ir-usb: reimplement using generic framework") switched to using the generic write implementation which may combine multiple write requests into larger transfers. This can break the IrLAP protocol where end-of-frame is determined using the USB short packet mechanism, for example, if multiple frames are sent in rapid succession. Fixes: f4a4cbb2 ("USB: ir-usb: reimplement using generic framework") Cc: stable <stable@vger.kernel.org> # 2.6.35 Reviewed-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 17a0184c upstream. Commit e0d795e4 ("usb: irda: cleanup on ir-usb module") added a USB IrDA header with common defines, but mistakingly switched to using the class-descriptor baud-rate bitmask values for the outbound header. This broke link-speed handling for rates above 9600 baud, but a device would also be able to operate at the default 9600 baud until a link-speed request was issued (e.g. using the TCGETS ioctl). Fixes: e0d795e4 ("usb: irda: cleanup on ir-usb module") Cc: stable <stable@vger.kernel.org> # 2.6.27 Cc: Felipe Balbi <balbi@kernel.org> Reviewed-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 2988a8ae upstream. Add missing endpoint sanity check to avoid dereferencing a NULL-pointer on open() in case a device lacks a bulk-out endpoint. Note that prior to commit f4a4cbb2 ("USB: ir-usb: reimplement using generic framework") the oops would instead happen on open() if the device lacked a bulk-in endpoint and on write() if it lacked a bulk-out endpoint. Fixes: f4a4cbb2 ("USB: ir-usb: reimplement using generic framework") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit 3139b180 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: dad0d04f ("rsi: Add RS9113 wireless driver") Cc: stable <stable@vger.kernel.org> # 3.15 Cc: Fariya Fatima <fariyaf@gmail.com> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864774 commit b73e05aa upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 9afac70a ("orinoco: add orinoco_usb driver") Cc: stable <stable@vger.kernel.org> # 2.6.35 Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1864774 [ this is a fix specific to 4.4.y and 4.9.y stable trees; 4.14.y and older already contain the right fix ] The stable 4.4.y and 4.9.y backports of the upstream commit add9d56d ("ALSA: pcm: Avoid possible info leaks from PCM stream buffers") dropped the check of substream->ops->copy_user as copy_user is a new member that isn't present in the older kernels. Although upstream drivers should work without this NULL check, it may cause a regression with a downstream driver that sets some inaccessible address to runtime->dma_area, leading to a crash at worst. Since such drivers must have ops->copy member on older kernels instead of ops->copy_user, this patch adds the missing check of ops->copy for fixing the regression. Reported-and-tested-by:
Andreas Schneider <asn@cryptomilk.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1864773Signed-off-by:
-
Wen Huang authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit e5e884b4 upstream. add_ie_rates() copys rates without checking the length in bss descriptor from remote AP.when victim connects to remote attacker, this may trigger buffer overflow. lbs_ibss_join_existing() copys rates without checking the length in bss descriptor from remote IBSS node.when victim connects to remote attacker, this may trigger buffer overflow. Fix them by putting the length check before performing copy. This fix addresses CVE-2019-14896 and CVE-2019-14897. This also fix build warning of mixed declarations and code. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Wen Huang <huangwenabc@gmail.com> Signed-off-by:
-
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1864773 This reverts commit f41dbb3e. Note: it will be replaced by a modified version from linux-stable Signed-off-by:
-
- 13 Mar, 2020 18 commits
-
-
Martin Schiller authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit e21dba7a upstream. This patch fixes 2 issues in x25_connect(): 1. It makes absolutely no sense to reset the neighbour and the connection state after a (successful) nonblocking call of x25_connect. This prevents any connection from being established, since the response (call accept) cannot be processed. 2. Any further calls to x25_connect() while a call is pending should simply return, instead of creating new Call Request (on different logical channels). This patch should also fix the "KASAN: null-ptr-deref Write in x25_connect" and "BUG: unable to handle kernel NULL pointer dereference in x25_connect" bugs reported by syzbot. Signed-off-by:
Martin Schiller <ms@dev.tdt.de> Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com Signed-off-by:
-
Kadlecsik József authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 32c72165 upstream. The bitmap allocation did not use full unsigned long sizes when calculating the required size and that was triggered by KASAN as slab-out-of-bounds read in several places. The patch fixes all of them. Reported-by: syzbot+fabca5cbf5e54f3fe2de@syzkaller.appspotmail.com Reported-by: syzbot+827ced406c9a1d9570ed@syzkaller.appspotmail.com Reported-by: syzbot+190d63957b22ef673ea5@syzkaller.appspotmail.com Reported-by: syzbot+dfccdb2bdb4a12ad425e@syzkaller.appspotmail.com Reported-by: syzbot+df0d0f5895ef1f41a65b@syzkaller.appspotmail.com Reported-by: syzbot+b08bd19bb37513357fd4@syzkaller.appspotmail.com Reported-by: syzbot+53cdd0ec0bbabd53370a@syzkaller.appspotmail.com Signed-off-by:
Jozsef Kadlecsik <kadlec@netfilter.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit c42b65e3 upstream. A lot of code become ugly because of open coding allocations for bitmaps. Introduce three helpers to allow users be more clear of intention and keep their code neat. Note, due to multiple circular dependencies we may not provide the helpers as inliners. For now we keep them exported and, perhaps, at some point in the future we will sort out header inclusion and inheritance. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit e64e4018 upstream. bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods. On the other hand MD bitmap API is special case. Adding 'md' prefix to it to avoid name space collision. No functional changes intended. Signed-off-by:
Shaohua Li <shli@kernel.org> Signed-off-by:
-
Bo Wu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit bba340c7 upstream. In iscsi_if_rx func, after receiving one request through iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to reply to the request in a do-while loop. If the iscsi_if_send_reply function keeps returning -EAGAIN, a deadlock will occur. For example, a client only send msg without calling recvmsg func, then it will result in the watchdog soft lockup. The details are given as follows: sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI); retval = bind(sock_fd, (struct sock addr*) & src_addr, sizeof(src_addr); while (1) { state_msg = sendmsg(sock_fd, &msg, 0); //Note: recvmsg(sock_fd, &msg, 0) is not processed here. } close(sock_fd); watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305] Sample time: 4000897528 ns(HZ: 250) Sample stat: curr: user: 675503481560, nice: 321724050, sys: 448689506750, idle: 4654054240530, iowait: 40885550700, irq: 14161174020, softirq: 8104324140, st: 0 deta: user: 0, nice: 0, sys: 3998210100, idle: 0, iowait: 0, irq: 1547170, softirq: 242870, st: 0 Sample softirq: TIMER: 992 SCHED: 8 Sample irqstat: irq 2: delta 1003, curr: 3103802, arch_timer CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G OE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO) pc : __alloc_skb+0x104/0x1b0 lr : __alloc_skb+0x9c/0x1b0 sp : ffff000033603a30 x29: ffff000033603a30 x28: 00000000000002dd x27: ffff800b34ced810 x26: ffff800ba7569f00 x25: 00000000ffffffff x24: 0000000000000000 x23: ffff800f7c43f600 x22: 0000000000480020 x21: ffff0000091d9000 x20: ffff800b34eff200 x19: ffff800ba7569f00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0001000101000100 x13: 0000000101010000 x12: 0101000001010100 x11: 0001010101010001 x10: 00000000000002dd x9 : ffff000033603d58 x8 : ffff800b34eff400 x7 : ffff800ba7569200 x6 : ffff800b34eff400 x5 : 0000000000000000 x4 : 00000000ffffffff x3 : 0000000000000000 x2 : 0000000000000001 x1 : ffff800b34eff2c0 x0 : 0000000000000300 Call trace: __alloc_skb+0x104/0x1b0 iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi] netlink_unicast+0x1e0/0x258 netlink_sendmsg+0x310/0x378 sock_sendmsg+0x4c/0x70 sock_write_iter+0x90/0xf0 __vfs_write+0x11c/0x190 vfs_write+0xac/0x1c0 ksys_write+0x6c/0xd8 __arm64_sys_write+0x24/0x30 el0_svc_common+0x78/0x130 el0_svc_handler+0x38/0x78 el0_svc+0x8/0xc Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6915E3D4D2@dggeml505-mbx.china.huawei.comSigned-off-by:
Bo Wu <wubo40@huawei.com> Reviewed-by:
Zhiqiang Liu <liuzhiqiang26@huawei.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Lars Möllendorf authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 883f6165 upstream. Previous versions of `iio_compute_scan_bytes` only aligned each element to its own length (i.e. its own natural alignment). Because multiple consecutive sets of scan elements are buffered this does not work in case the computed scan bytes do not align with the natural alignment of the first scan element in the set. This commit fixes this by aligning the scan bytes to the natural alignment of the largest scan element in the set. Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by:
Lars Möllendorf <lars.moellendorf@plating.de> Reviewed-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Changbin Du authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit d0695e23 upstream. Just as commit 0566e40c ("tracing: initcall: Ordered comparison of function pointers"), this patch fixes another remaining one in xen.h found by clang-9. In file included from arch/x86/xen/trace.c:21: In file included from ./include/trace/events/xen.h:475: In file included from ./include/trace/define_trace.h:102: In file included from ./include/trace/trace_events.h:473: ./include/trace/events/xen.h:69:7: warning: ordered comparison of function \ pointers ('xen_mc_callback_fn_t' (aka 'void (*)(void *)') and 'xen_mc_callback_fn_t') [-Wordered-compare-function-pointers] __field(xen_mc_callback_fn_t, fn) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/trace_events.h:421:29: note: expanded from macro '__field' ^ ./include/trace/trace_events.h:407:6: note: expanded from macro '__field_ext' is_signed_type(type), filter_type); \ ^ ./include/linux/trace_events.h:554:44: note: expanded from macro 'is_signed_type' ^ Fixes: c796f213 ("xen/trace: add multicall tracing") Signed-off-by:
Changbin Du <changbin.du@gmail.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 04060db4 upstream. iscsit_close_connection() calls isert_wait_conn(). Due to commit e9d3009c both functions call target_wait_for_sess_cmds() although that last function should be called only once. Fix this by removing the target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling isert_wait_conn() after target_wait_for_sess_cmds(). Fixes: e9d3009c ("scsi: target: iscsi: Wait for all commands to finish before freeing a session"). Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.orgReported-by:
Rahul Kundu <rahul.kundu@chelsio.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Tested-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Acked-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Gilles Buloz authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 7713e62c upstream. in0 thresholds are written to the in2 thresholds registers in2 thresholds to in3 thresholds in3 thresholds to in4 thresholds in4 thresholds to in0 thresholds Signed-off-by:
Gilles Buloz <gilles.buloz@kontron.com> Link: https://lore.kernel.org/r/5de0f509.rc0oEvPOMjbfPW1w%gilles.buloz@kontron.com Fixes: 3434f378 ("hwmon: Driver for Nuvoton NCT7802Y") Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 3111491f upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 8e20cf2b ("Input: aiptek - fix crash on detecting device without endpoints") Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.orgSigned-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit a8eeb74d upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 162f98de ("Input: gtco - fix crash on detecting device without endpoints") Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 6b32391e upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: bdb5c57f ("Input: add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)") Signed-off-by:
-
Michał Mirosław authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 2a187d03 upstream. For SDHCIv3+ with programmable clock mode, minimal clock frequency is still base clock / max(divider). Minimal programmable clock frequency is always greater than minimal divided clock frequency. Without this patch, SDHCI uses out-of-spec initial frequency when multiplier is big enough: mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz [for 480 MHz source clock divided by 1024] The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode. Fixes: c3ed3877 ("mmc: sdhci: add support for programmable clock mode") Cc: <stable@vger.kernel.org> # 4f6aa326: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: <stable@vger.kernel.org> Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.plSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Alex Sverdlin authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit 927d780e upstream. Scenario 1, ARMv7 ================= If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer the following may be generated: 00000230 <prealloc_fixed_plts>: 230: b5f8 push {r3, r4, r5, r6, r7, lr} 232: b500 push {lr} 234: f7ff fffe bl 0 <__gnu_mcount_nc> 234: R_ARM_THM_CALL __gnu_mcount_nc 238: f240 0600 movw r6, #0 238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc 23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180 FTRACE currently is not able to deal with it: WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230() ... CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1 ... [<c0314e3d>] (unwind_backtrace) from [<c03115e9>] (show_stack+0x11/0x14) [<c03115e9>] (show_stack) from [<c051a7f1>] (dump_stack+0x81/0xa8) [<c051a7f1>] (dump_stack) from [<c0321c5d>] (warn_slowpath_common+0x69/0x90) [<c0321c5d>] (warn_slowpath_common) from [<c0321cf3>] (warn_slowpath_null+0x17/0x1c) [<c0321cf3>] (warn_slowpath_null) from [<c038ee9d>] (ftrace_bug+0x1ad/0x230) [<c038ee9d>] (ftrace_bug) from [<c038f1f9>] (ftrace_process_locs+0x27d/0x444) [<c038f1f9>] (ftrace_process_locs) from [<c08915bd>] (ftrace_init+0x91/0xe8) [<c08915bd>] (ftrace_init) from [<c0885a67>] (start_kernel+0x34b/0x358) [<c0885a67>] (start_kernel) from [<00308095>] (0x308095) ---[ end trace cb88537fdc8fa200 ]--- ftrace failed to modify [<c031266c>] prealloc_fixed_plts+0x8/0x60 actual: 44:f2:e1:36 ftrace record flags: 0 (0) expected tramp: c03143e9 Scenario 2, ARMv4T ================== ftrace: allocating 14435 entries in 43 pages ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310 CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1 Hardware name: Cirrus Logic EDB9302 Evaluation Board [<c0010a24>] (unwind_backtrace) from [<c000ecb0>] (show_stack+0x20/0x2c) [<c000ecb0>] (show_stack) from [<c03c72e8>] (dump_stack+0x20/0x30) [<c03c72e8>] (dump_stack) from [<c0021c18>] (__warn+0xdc/0x104) [<c0021c18>] (__warn) from [<c0021d7c>] (warn_slowpath_null+0x4c/0x5c) [<c0021d7c>] (warn_slowpath_null) from [<c0095360>] (ftrace_bug+0x204/0x310) [<c0095360>] (ftrace_bug) from [<c04dabac>] (ftrace_init+0x3b4/0x4d4) [<c04dabac>] (ftrace_init) from [<c04cef4c>] (start_kernel+0x20c/0x410) [<c04cef4c>] (start_kernel) from [<00000000>] ( (null)) ---[ end trace 0506a2f5dae6b341 ]--- ftrace failed to modify [<c000c350>] perf_trace_sys_exit+0x5c/0xe8 actual: 1e:ff:2f:e1 Initializing ftrace call sites ftrace record flags: 0 (0) expected tramp: c000fb24 The analysis for this problem has been already performed previously, refer to the link below. Fix the above problems by allowing only selected reloc types in __mcount_loc. The list itself comes from the legacy recordmcount.pl script. Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/ Cc: stable@vger.kernel.org Fixes: ed60453f ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount") Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit ba9a103f upstream. The driver was issuing synchronous uninterruptible control requests without using a timeout. This could lead to the driver hanging on probe due to a malfunctioning (or malicious) device until the device is physically disconnected. While sleeping in probe the driver prevents other devices connected to the same hub from being added to (or removed from) the bus. The USB upper limit of five seconds per request should be more than enough. Fixes: 99f83c9c ("[PATCH] USB: add driver for Keyspan Digital Remote") Signed-off-by:
-
Luuk Paulussen authored
BugLink: https://bugs.launchpad.net/bugs/1864773 commit cf3ca187 upstream. reg2volt returns the voltage that matches a given register value. Converting this back the other way with volt2reg didn't return the same register value because it used truncation instead of rounding. This meant that values read from sysfs could not be written back to sysfs to set back the same register value. With this change, volt2reg will return the same value for every voltage previously returned by reg2volt (for the set of possible input values) Signed-off-by:
Luuk Paulussen <luuk.paulussen@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20191205231659.1301-1-luuk.paulussen@alliedtelesis.co.nz cc: stable@vger.kernel.org Signed-off-by:
-
James Hughes authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit ce896476 ] As reported by Eric Dumazet, there are still some outstanding cases where the driver does not handle TSO correctly when skb's are over a certain size. Most cases have been fixed, this patch should ensure that forwarded SKB's that are greater than MAX_SINGLE_PACKET_SIZE - TX_OVERHEAD are software segmented and handled correctly. Signed-off-by:
James Hughes <james.hughes@raspberrypi.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Cong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 61678d28 ] syzbot reported an out-of-bound access in em_nbyte. As initially analyzed by Eric, this is because em_nbyte sets its own em->datalen in em_nbyte_change() other than the one specified by user, but this value gets overwritten later by its caller tcf_em_validate(). We should leave em->datalen untouched to respect their choices. I audit all the in-tree ematch users, all of those implement ->change() set em->datalen, so we can just avoid setting it twice in this case. Reported-and-tested-by: syzbot+5af9a90dad568aa9f611@syzkaller.appspotmail.com Reported-by: syzbot+2f07903a5b05e7f36410@syzkaller.appspotmail.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
-
