commit d27a14321366788cef927dbe69854f34460b3f7c Author: Greg Kroah-Hartman Date: Sun Sep 12 09:01:00 2021 +0200 Linux 5.14.3 Link: https://lore.kernel.org/r/20210910122916.022815161@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Justin M. Forbes Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 5df96161b5e89dbffadc0b9e3feea49433d5c2eb Author: Alison Schofield Date: Fri Sep 3 19:20:39 2021 -0700 cxl/acpi: Do not add DSDT disabled ACPI0016 host bridge ports commit a7bfaad54b8b9cf06041528988d6b75b4b921546 upstream. During CXL ACPI probe, host bridge ports are discovered by scanning the ACPI0017 root port for ACPI0016 host bridge devices. The scan matches on the hardware id of "ACPI0016". An issue occurs when an ACPI0016 device is defined in the DSDT yet disabled on the platform. Attempts by the cxl_acpi driver to add host bridge ports using a disabled device fails, and the entire cxl_acpi probe fails. The DSDT table includes an _STA method that sets the status and the ACPI subsystem has checks available to examine it. One such check is in the acpi_pci_find_root() path. Move the call to acpi_pci_find_root() to the matching function to prevent this issue when adding either upstream or downstream ports. Suggested-by: Dan Williams Signed-off-by: Alison Schofield Fixes: 7d4b5ca2e2cb ("cxl/acpi: Add downstream port data to cxl_port instances") Cc: Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/163072203957.2250120.2178685721061002124.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 30732043855fe55d464de148159259d7dc7b28df Author: Dan Williams Date: Fri Sep 3 19:20:45 2021 -0700 cxl/pci: Fix lockdown level commit 9e56614c44b994b78fc9fcb2070bcbe3f5df0d7b upstream. A proposed rework of security_locked_down() users identified that the cxl_pci driver was passing the wrong lockdown_reason. Update cxl_mem_raw_command_allowed() to fail raw command access when raw pci access is also disabled. Fixes: 13237183c735 ("cxl/mem: Add a "RAW" send command") Cc: Ben Widawsky Cc: Jonathan Cameron Cc: Cc: Ondrej Mosnacek Cc: Paul Moore Link: https://lore.kernel.org/r/163072204525.2250120.16615792476976546735.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 50cfd0a582e7686e95e10f4f3621e068a4e8dfca Author: Li Qiang (Johnny Li) Date: Fri Sep 3 19:20:50 2021 -0700 cxl/pci: Fix debug message in cxl_probe_regs() commit da582aa5ad5787c46e3f475ab3f4602ec84c1617 upstream. Indicator string for mbox and memdev register set to status incorrectly in error message. Cc: Fixes: 30af97296f48 ("cxl/pci: Map registers based on capabilities") Signed-off-by: Li Qiang (Johnny Li) Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/163072205089.2250120.8103605864156687395.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 173eda2389870681ea466fdf3e24752424062703 Author: Marek BehĂșn Date: Thu Jun 24 19:14:17 2021 +0200 PCI: Call Max Payload Size-related fixup quirks early commit b8da302e2955fe4d41eb9d48199242674d77dbe0 upstream. pci_device_add() calls HEADER fixups after pci_configure_device(), which configures Max Payload Size. Convert MPS-related fixups to EARLY fixups so pci_configure_mps() takes them into account. Fixes: 27d868b5e6cfa ("PCI: Set MPS to match upstream bridge") Link: https://lore.kernel.org/r/20210624171418.27194-1-kabel@kernel.org Signed-off-by: Marek BehĂșn Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit de33291cf45cef6214c786624515fa5ba6f8b69b Author: Paul Gortmaker Date: Sun May 30 12:24:47 2021 -0400 x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions commit a729691b541f6e63043beae72e635635abe5dc09 upstream. When this platform was relatively new in November 2011, with early BIOS revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot") However, this quirk (and several others) are open-ended to all BIOS versions and left no automatic expiry if/when the system BIOS fixed the issue, meaning that nobody is likely to come along and re-test. What is really problematic with using PCI reboot as this quirk does, is that it causes this platform to do a full power down, wait one second, and then power back on. This is less than ideal if one is using it for boot testing and/or bisecting kernels when legacy rotating hard disks are installed. It was only by chance that the quirk was noticed in dmesg - and when disabled it turned out that it wasn't required anymore (BIOS A24), and a default reboot would work fine without the "harshness" of power cycling the machine (and disks) down and up like the PCI reboot does. Doing a bit more research, it seems that the "newest" BIOS for which the issue was reported[1] was version A06, however Dell[2] seemed to suggest only up to and including version A05, with the A06 having a large number of fixes[3] listed. As is typical with a new platform, the initial BIOS updates come frequently and then taper off (and in this case, with a revival for CPU CVEs); a search for O990-A.exe reveals the following dates: A02 16 Mar 2011 A03 11 May 2011 A06 14 Sep 2011 A07 24 Oct 2011 A10 08 Dec 2011 A14 06 Sep 2012 A16 15 Oct 2012 A18 30 Sep 2013 A19 23 Sep 2015 A20 02 Jun 2017 A23 07 Mar 2018 A24 21 Aug 2018 While it's overkill to flash and test each of the above, it would seem likely that the issue was contained within A0x BIOS versions, given the dates above and the dates of issue reports[4] from distros. So rather than just throw out the quirk entirely, limit the scope to just those early BIOS versions, in case people are still running systems from 2011 with the original as-shipped early A0x BIOS versions. [1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/ [2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems [3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10 [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039 Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot") Signed-off-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com Signed-off-by: Greg Kroah-Hartman commit 51dc4d68b810847211cb0b7be772f262fe3ee5c5 Author: Sergio Paracuellos Date: Mon Aug 23 19:08:03 2021 +0200 staging: mt7621-pci: fix hang when nothing is connected to pcie ports commit 7d761b084b3c785e1fbbe707fbdf7baba905c6ad upstream. When nothing is connected to pcie ports, each port is set to reset state. When this occurs, next access result in a hang on boot as follows: mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK) mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK) mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK) [ HANGS HERE ] Fix this just detecting 'nothing is connected state' to avoid next accesses to pcie port related configuration registers. Fixes: b99cc3a2b6b6 ("staging: mt7621-pci: avoid custom 'map_irq' function") Cc: stable Reported-by: DENG Qingfang Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210823170803.2108-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2fd136212dc171a3665ebb3bf0f49a14fdbc406e Author: Mathias Nyman Date: Fri Aug 20 15:35:00 2021 +0300 xhci: Fix failure to give back some cached cancelled URBs. commit 94f339147fc3eb9edef7ee4ef6e39c569c073753 upstream. Only TDs with status TD_CLEARING_CACHE will be given back after cache is cleared with a set TR deq command. xhci_invalidate_cached_td() failed to set the TD_CLEARING_CACHE status for some cancelled TDs as it assumed an endpoint only needs to clear the TD it stopped on. This isn't always true. For example with streams enabled an endpoint may have several stream rings, each stopping on a different TDs. Note that if an endpoint has several stream rings, the current code will still only clear the cache of the stream pointed to by the last cancelled TD in the cancel list. This patch only focus on making sure all canceled TDs are given back, avoiding hung task after device removal. Another fix to solve clearing the caches of all stream rings with cancelled TDs is needed, but not as urgent. This issue was simultanously discovered and debugged by by Tao Wang, with a slightly different fix proposal. Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps") Cc: #5.12 Reported-by: Tao Wang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b5671930136357c295ffa1643de7b5f5ac921c3f Author: Mathias Nyman Date: Fri Aug 20 15:34:58 2021 +0300 xhci: fix unsafe memory usage in xhci tracing commit cbf286e8ef8337308c259ff5b9ce2e74d403be5a upstream. Removes static char buffer usage in the following decode functions: xhci_decode_trb() xhci_decode_ptortsc() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor chanes are needed in xhci debugfs code as these functions are also used there. Changes include moving XHCI_MSG_MAX definititon from xhci-trace.h to xhci.h Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 57fb99d159d0d0cce9813745b963ed25c68f575b Author: Mathias Nyman Date: Fri Aug 20 15:34:59 2021 +0300 xhci: fix even more unsafe memory usage in xhci tracing commit 4843b4b5ec64b875a5e334f280508f1f75e7d3e4 upstream. Removes static char buffer usage in the following decode functions: xhci_decode_ctrl_ctx() xhci_decode_slot_context() xhci_decode_usbsts() xhci_decode_doorbell() xhci_decode_ep_context() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor changes are needed in other xhci code as these functions are also used elsewhere Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4502a2fb422aa8597801b794ccd8a8b5974ac419 Author: Chunfeng Yun Date: Fri Aug 13 14:30:49 2021 +0800 usb: mtu3: fix the wrong HS mult value commit 44e4439d8f9f8d0e9da767d1f31e7c211081feca upstream. usb_endpoint_maxp() returns actual max packet size, @mult will always be zero, fix it by using usb_endpoint_maxp_mult() instead to get mult. Fixes: 4d79e042ed8b ("usb: mtu3: add support for usb3.1 IP") Cc: stable@vger.kernel.org Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1628836253-7432-3-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit fbcb43dfd12cd995f2ae417decab418630b319b8 Author: Chunfeng Yun Date: Fri Aug 13 14:30:48 2021 +0800 usb: mtu3: use @mult for HS isoc or intr commit fd7cb394ec7efccc3985feb0978cee4d352e1817 upstream. For HS isoc or intr, should use @mult but not @burst to save mult value. Fixes: 4d79e042ed8b ("usb: mtu3: add support for usb3.1 IP") Cc: stable@vger.kernel.org Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1628836253-7432-2-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit ad1289a6ff456a408cdf7f891abdc6588e45aca1 Author: Chunfeng Yun Date: Fri Aug 13 14:30:47 2021 +0800 usb: mtu3: restore HS function when set SS/SSP commit e88f28514065a6c48aadc367efb0ef6378a01543 upstream. Due to HS function is disabled when set as FS, need restore it when set as SS/SSP. Fixes: dc4c1aa7eae9 ("usb: mtu3: add ->udc_set_speed()") Cc: stable@vger.kernel.org Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1628836253-7432-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 0efc9dcc45f02b4d186cb5d8d979912dc1bc2daf Author: Chunfeng Yun Date: Fri Aug 13 14:30:51 2021 +0800 usb: gadget: tegra-xudc: fix the wrong mult value for HS isoc or intr commit eeb0cfb6b2b6b731902e68af641e30bd31be3c7b upstream. usb_endpoint_maxp() only returns the bit[10:0] of wMaxPacketSize of endpoint descriptor, not includes bit[12:11] anymore, so use usb_endpoint_maxp_mult() instead. Meanwhile no need AND 0x7ff when get maxp, remove it. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable@vger.kernel.org Acked-by: Felipe Balbi Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1628836253-7432-5-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 973bce85d41a2f4b1d1626a1d54f43426bc8bdc5 Author: Chunfeng Yun Date: Fri Aug 13 14:30:50 2021 +0800 usb: cdnsp: fix the wrong mult value for HS isoc or intr commit e9ab75f26eb9354dfc03aea3401b8cfb42cd6718 upstream. usb_endpoint_maxp() only returns the bit[10:0] of wMaxPacketSize of endpoint descriptor, not include bit[12:11] anymore, so use usb_endpoint_maxp_mult() instead. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable@vger.kernel.org Acked-by: Felipe Balbi Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1628836253-7432-4-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 2ec12af2b61d62fdea9f9f17e55801a623ade203 Author: Chunfeng Yun Date: Tue Aug 17 16:36:25 2021 +0800 usb: xhci-mtk: fix issue of out-of-bounds array access commit de5107f473190538a65aac7edea85209cd5c1a8f upstream. Bus bandwidth array access is based on esit, increase one will cause out-of-bounds issue; for example, when esit is XHCI_MTK_MAX_ESIT, will overstep boundary. Fixes: 7c986fbc16ae ("usb: xhci-mtk: get the microframe boundary for ESIT") Cc: Reported-by: Stan Lu Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1629189389-18779-5-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 6216e83076d6f7f0b035a423dbd0191281397329 Author: Yoshihiro Shimoda Date: Fri Aug 27 15:32:27 2021 +0900 usb: host: xhci-rcar: Don't reload firmware after the completion commit 57f3ffdc11143f56f1314972fe86fe17a0dcde85 upstream. According to the datasheet, "Upon the completion of FW Download, there is no need to write or reload FW.". Otherwise, it's possible to cause unexpected behaviors. So, adds such a condition. Fixes: 4ac8918f3a73 ("usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers") Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210827063227.81990-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit 755b1981479e5bb80a17d3a5abdfa5a0957f0ce2 Author: Ismael Ferreras Morezuelas Date: Sat Jul 17 01:21:43 2021 +0200 Bluetooth: btusb: Make the CSR clone chip force-suspend workaround more generic commit f4292e2faf522f899b642d2040a2edbcbd455b9f upstream. Turns out Hans de Goede completed the work I started last year trying to improve Chinese-clone detection of CSR controller chips. Quirk after quirk these Bluetooth dongles are more usable now. Even after a few BlueZ regressions; these clones are so fickle that some days they stop working altogether. Except on Windows, they work fine. But this force-suspend initialization quirk seems to mostly do the trick, after a lot of testing Bluetooth now seems to work *all* the time. The only problem is that the solution ended up being masked under a very stringent check; when there are probably hundreds of fake dongle models out there that benefit from a good reset. Make it so. Fixes: 81cac64ba258a ("Bluetooth: Deal with USB devices that are faking CSR vendor") Fixes: cde1a8a992875 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers") Fixes: d74e0ae7e0303 ("Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134") Fixes: 0671c0662383e ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers") Cc: stable@vger.kernel.org Cc: Hans de Goede Tested-by: Ismael Ferreras Morezuelas Signed-off-by: Ismael Ferreras Morezuelas Reviewed-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit e496809d7fcae115dd94fc918d067c36559a2bf1 Author: Larry Finger Date: Wed Aug 4 09:50:33 2021 -0500 Bluetooth: Add additional Bluetooth part for Realtek 8852AE commit 6eefec4a0b668de9bbb33bd3e7acfbcc794162b0 upstream. This Realtek device has both wifi and BT components. The latter reports a USB ID of 04ca:4006, which is not in the table. The portion of /sys/kernel/debug/usb/devices pertaining to this device is T: Bus=02 Lev=01 Prnt=01 Port=12 Cnt=04 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=4006 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 2ba31c34084bdc78460367caf0d8537c477d89e4 Author: Alexander Tsoy Date: Tue Aug 31 03:25:31 2021 +0300 ALSA: usb-audio: Add registration quirk for JBL Quantum 800 commit c8b177b6e3a005bd8fb0395a4bc5db3470301c28 upstream. Add another device ID for JBL Quantum 800. It requires the same quirk as other JBL Quantum devices. Signed-off-by: Alexander Tsoy Cc: Link: https://lore.kernel.org/r/20210831002531.116957-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f2a098d562616e2a9b73d474c083bd30265edcaa Author: Hayes Wang Date: Fri Aug 6 17:15:55 2021 +0800 Revert "r8169: avoid link-up interrupt issue on RTL8106e if user enables ASPM" commit 2115d3d482656ea702f7cf308c0ded3500282903 upstream. This reverts commit 1ee8856de82faec9bc8bd0f2308a7f27e30ba207. This is used to re-enable ASPM on RTL8106e, if it is possible. Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d1a3c6d5925a8d00a32c5ef2d674dd9c0ce89c95 Author: Liu Jian Date: Fri Jul 16 12:06:17 2021 +0800 igmp: Add ip_mc_list lock in ip_check_mc_rcu commit 23d2b94043ca8835bd1e67749020e839f396a1c2 upstream. I got below panic when doing fuzz test: Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4056 Comm: syz-executor.3 Tainted: G B 5.14.0-rc1-00195-gcff5c4254439-dirty #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x7a/0x9b panic+0x2cd/0x5af end_report.cold+0x5a/0x5a kasan_report+0xec/0x110 ip_check_mc_rcu+0x556/0x5d0 __mkroute_output+0x895/0x1740 ip_route_output_key_hash_rcu+0x2d0/0x1050 ip_route_output_key_hash+0x182/0x2e0 ip_route_output_flow+0x28/0x130 udp_sendmsg+0x165d/0x2280 udpv6_sendmsg+0x121e/0x24f0 inet6_sendmsg+0xf7/0x140 sock_sendmsg+0xe9/0x180 ____sys_sendmsg+0x2b8/0x7a0 ___sys_sendmsg+0xf0/0x160 __sys_sendmmsg+0x17e/0x3c0 __x64_sys_sendmmsg+0x9e/0x100 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x462eb9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3df5af1c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462eb9 RDX: 0000000000000312 RSI: 0000000020001700 RDI: 0000000000000007 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3df5af26bc R13: 00000000004c372d R14: 0000000000700b10 R15: 00000000ffffffff It is one use-after-free in ip_check_mc_rcu. In ip_mc_del_src, the ip_sf_list of pmc has been freed under pmc->lock protection. But access to ip_sf_list in ip_check_mc_rcu is not protected by the lock. Signed-off-by: Liu Jian Signed-off-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 9306259f16f2a37dc321229f8729879ba0301a02 Author: Tong Zhang Date: Mon Sep 6 16:37:02 2021 -0700 can: c_can: fix null-ptr-deref on ioctl() commit 644d0a5bcc3361170d84fb8d0b13943c354119db upstream. The pdev maybe not a platform device, e.g. c_can_pci device, in this case, calling to_platform_device() would not make sense. Also, per the comment in drivers/net/can/c_can/c_can_ethtool.c, @bus_info should match dev_name() string, so I am replacing this with dev_name() to fix this issue. [ 1.458583] BUG: unable to handle page fault for address: 0000000100000000 [ 1.460921] RIP: 0010:strnlen+0x1a/0x30 [ 1.466336] ? c_can_get_drvinfo+0x65/0xb0 [c_can] [ 1.466597] ethtool_get_drvinfo+0xae/0x360 [ 1.466826] dev_ethtool+0x10f8/0x2970 [ 1.467880] sock_ioctl+0xef/0x300 Fixes: 2722ac986e93 ("can: c_can: add ethtool support") Link: https://lore.kernel.org/r/20210906233704.1162666-1-ztong0001@gmail.com Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Tong Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 9d1db6a315738823cca04a69616fe402c8b2db6e Author: Hans de Goede Date: Thu Sep 2 17:28:53 2021 +0200 firmware: dmi: Move product_sku info to the end of the modalias commit f97a2103f1a75ca70f23deadb4d96a16c4d85e7d upstream. Commit e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") added a new field to the modalias in the middle of the modalias, breaking some existing udev/hwdb matches on the whole modalias without a wildcard ('*') in between the pvr and rvn fields. All modalias matches in e.g. : https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb deliberately end in ':*' so that new fields can be added at *the end* of the modalias, but adding a new field in the middle like this breaks things. Move the new sku field to the end of the modalias to fix some hwdb entries no longer matching. The new sku field has already been put to use in 2 new hwdb entries: sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0A3E:* ACCEL_LOCATION=base sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0B0B:* ACCEL_LOCATION=base The wildcard use before and after the sku in these matches means that they should keep working with the sku moved to the end. Note that there is a second instance of in essence the same problem, commit f5152f4ded3c ("firmware/dmi: Report DMI Bios & EC firmware release") Added 2 new br and efr fields in the middle of the modalias. This too breaks some hwdb modalias matches, but this has gone unnoticed for over a year. So some newer hwdb modalias matches actually depend on these fields being in the middle of the string. Moving these to the end now would break 3 hwdb entries, while fixing 8 entries. Since there is no good answer for the new br and efr fields I have chosen to leave these as is. Instead I'll submit a hwdb update to put a wildcard at the place where these fields may or may not be present depending on the kernel version. BugLink: https://github.com/systemd/systemd/issues/20550 Link: https://github.com/systemd/systemd/pull/20562 Fixes: e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") Cc: stable@vger.kernel.org Cc: Kai-Chuan Hsieh Cc: Erwan Velu Signed-off-by: Hans de Goede Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman