commit 1797d8bf8d0c2e74defad605d14e3553d43a3caf Author: Greg Kroah-Hartman Date: Mon Sep 14 13:19:19 2026 +0200 Linux 5.10.270 Link: https://lore.kernel.org/r/20260912065516.948645775@linuxfoundation.org Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Dominique Martinet Tested-by: Woody Suwalski Signed-off-by: Greg Kroah-Hartman commit 335d81d04bba96e428ffeb05667c89b8192cee4e Author: Zhang Chen Date: Thu Mar 19 17:32:11 2026 +0800 Bluetooth: L2CAP: Fix send LE flow credits in ACL link [ Upstream commit f39f905e55f529b036321220af1ba4f4085564a5 ] When the L2CAP channel mode is L2CAP_MODE_ERTM/L2CAP_MODE_STREAMING, l2cap_publish_rx_avail will be called and le flow credits will be sent in l2cap_chan_rx_avail, even though the link type is ACL. The logs in question as follows: > ACL Data RX: Handle 129 flags 0x02 dlen 12 L2CAP: Unknown (0x16) ident 4 len 4 40 00 ed 05 < ACL Data TX: Handle 129 flags 0x00 dlen 10 L2CAP: Command Reject (0x01) ident 4 len 2 Reason: Command not understood (0x0000) Bluetooth: Unknown BR/EDR signaling command 0x16 Bluetooth: Wrong link type (-22) Fixes: ce60b9231b66 ("Bluetooth: compute LE flow credits based on recvbuf space") Signed-off-by: Zhang Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f83bc9e6d797c7a6dfd4dfa499bf1f633c1fd7df Author: Dan Carpenter Date: Tue Jun 6 11:20:54 2023 +0300 HID: fix an error code in hid_check_device_match() [ Upstream commit 89e756e3cc8d9c1ebc0f2b2f6912227073d93118 ] The hid_check_device_match() returns true if we find a match and false if we don't. But here it returns -ENODEV which becomes true instead of false. Fixes: 207733f92661 ("HID: split apart hid_device_probe to make logic more apparent") Signed-off-by: Dan Carpenter Reviewed-by: Benjamin Tissoires Reviewed-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 29a22a3d495c147117137719d2c39045c44ccebf Author: Rafael Mendonca Date: Tue Sep 13 23:49:24 2022 -0300 scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() [ Upstream commit 601be20fc6a1b762044d2398befffd6bf236cebf ] Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command. Link: https://lore.kernel.org/r/20220914024924.695604-1-rafaelmendsr@gmail.com Fixes: 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") Reviewed-by: Himanshu Madhani Signed-off-by: Rafael Mendonca Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5c2b4d4bd8b5a6f5aed15d6f2a71398206ceb270 Author: Andy Shevchenko Date: Tue Apr 13 02:20:51 2021 +0300 ACPI: utils: Document for_each_acpi_dev_match() macro [ Upstream commit 81eeb2f57782d0dff15db97665599121e289b614 ] The macro requires to call acpi_dev_put() on each iteration. Due to this it doesn't tolerate sudden disappearence of the devices. Document all these nuances to prevent users blindly call it without understanding the possible issues. While at it, add the note to the acpi_dev_get_next_match_dev() and advertise acpi_dev_put() instead of put_device() in the whole family of the helper functions. Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro") Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ca8975e3a74d67fb55b490a62739b00a1577db9b Author: Thomas Gleixner Date: Thu Nov 12 11:59:32 2020 +0100 mm/highmem: Take kmap_high_get() properly into account [ Upstream commit 2a656cad337e0e1ca582f58847d7b0c7eeba4dc8 ] kunmap_local() warns when the virtual address to unmap is below PAGE_OFFSET. This is correct except for the case that the mapping was obtained via kmap_high_get() because the PKMAP addresses are right below PAGE_OFFSET. Cure it by skipping the WARN_ON() when the unmap was handled by kunmap_high(). Fixes: 298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*") Reported-by: vtolkm@googlemail.com Reported-by: Marek Szyprowski Signed-off-by: Thomas Gleixner Tested-by: Marek Szyprowski Tested-by: Sebastian Andrzej Siewior Cc: Andrew Morton Link: https://lore.kernel.org/r/87y2j6n8mj.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 51b7806259d3d9ac69f2bfa3f171ba4dd74567c5 Author: Bjorn Andersson Date: Wed Jul 13 14:28:18 2022 -0700 clk: qcom: gdsc: Bump parent usage count when GDSC is found enabled [ Upstream commit 41fff779d7948147f2440c4bb134cdf8b45b22d7 ] When a GDSC is found to be enabled at boot the pm_runtime state will be unbalanced as the GDSC is later turned off. Fix this by increasing the usage counter on the power-domain, in line with how we handled the regulator state. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Signed-off-by: Bjorn Andersson Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/20220713212818.130277-1-bjorn.andersson@linaro.org Signed-off-by: Sasha Levin commit 99a86f097884c682873f566475562f574d6bdff3 Author: Hui Tang Date: Mon May 10 16:54:08 2021 +0800 crypto: testmgr - fix initialization of 'secret_size' [ Upstream commit 2d016672528a592ada5188e53ac746e1b8b7a978 ] Actual data length of the 'secret' is not equal to the 'secret_size'. Since the 'curve_id' has removed in the 'secret', the 'secret_size' should subtract the length of the 'curve_id'. Fixes: 6763f5ea2d9a ("crypto: ecdh - move curve_id of ECDH from ...") Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8ec4aa80e52587cdc9f24270bcd23fc0f10f17e9 Author: Hui Tang Date: Sat May 22 10:44:28 2021 +0800 crypto: ecdh - fix ecdh-nist-p192's entry in testmgr commit 6889fc2104e5d20899b91e61daf07a7524b2010d upstream. Add a comment that p192 will fail to register in FIPS mode. Fix ecdh-nist-p192's entry in testmgr by removing the ifdefs and not setting fips_allowed. Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 02ef3f579e89131e5fa6de09c9f327e2dd541d9c Author: Hui Tang Date: Sat May 22 10:44:29 2021 +0800 crypto: ecdh - fix 'ecdh_init' commit 8fd28fa5046b377039d5bbc0ab2f625dec703980 upstream. NIST P192 is not unregistered if failed to register NIST P256, actually it need to unregister the algorithms already registered. Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c977b8cf066c38b8c7dcea07ac0e2c9c139f003e Author: Hui Tang Date: Mon May 10 16:59:47 2021 +0800 crypto: ecdh - extend 'cra_driver_name' with curve name [ Upstream commit c5ae16f5c6b91dc78a08885a753489d608de4abd ] Currently, 'cra_driver_name' cannot be used to specify ecdh algorithm with a special curve, so extending it with curve name. Although using 'cra_name' can also specify a special curve, but ecdh generic driver cannot be specified when vendor hardware accelerator has registered. Fixes: 6763f5ea2d9a ("crypto: ecdh - move curve_id of ECDH from ...") Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d97e6f276f208959e0ed16c8856a3cf8ff95ca55 Author: Dmitry Baryshkov Date: Sun Dec 13 02:55:33 2020 +0300 driver core: platform: don't oops in platform_shutdown() on unbound devices commit 46e85af0cc53f35584e00bb5db7db6893d0e16e5 upstream. On shutdown the driver core calls the bus' shutdown callback also for unbound devices. A driver's shutdown callback however is only called for devices bound to this driver. Commit 9c30921fe799 ("driver core: platform: use bus_type functions") changed the platform bus from driver callbacks to bus callbacks, so the shutdown function must be prepared to be called without a driver. Add the corresponding check in the shutdown function. Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions") Tested-by: Guenter Roeck Reviewed-by: Uwe Kleine-König Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20201212235533.247537-1-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman commit 8eb51013b6308870479a64b4a2a018697b997849 Author: Jiayuan Chen Date: Wed Aug 26 22:11:26 2026 +0800 tcp: fix corruption of urgent data on multi-segment retransmit [ Upstream commit ce2b807f42ed5e55567b8864ab72963f90779270 ] On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: /* tcp_write_xmit() */ limit = mss_now; if (tso_segs > 1 && !tcp_urg_mode(tp)) limit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: /* __tcp_retransmit_skb() */ len = cur_mss * segs; /* segs > 1, no urg_mode check */ ... /* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode. Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826141145.67823-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8442586526c406527bf31206e538c0ce6bc672e6 Author: Deepanshu Kartikey Date: Wed Aug 26 19:02:58 2026 +0530 usb: atm: usbatm: fix invalid ci_range initialization [ Upstream commit a60fd8c6dbaa76da4163cf225ed2b9e982540f39 ] syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci. Fixes: c59bba75fa50 ("[PATCH] USB ATM: new usbatm core") Reported-by: syzbot+6665d3db5fef15914802@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802 Suggested-by: Eric Dumazet Link: https://lore.kernel.org/all/20260824024620.23485-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260826133258.8306-1-kartikey406@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0dc8b3a395c3a749ab62c078f2fd54a402ae7e2b Author: bui duc phuc Date: Wed Aug 26 17:34:28 2026 +0700 net: fec: only stop PTP if it was initialized [ Upstream commit dd890ae29299636fb037276fc1b5238698d08b03 ] fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized. Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path") Reviewed-by: Wei Fang Reviewed-by: Frank Li Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f0f4b09a95ef602fbdae948326beadd9c20eab3 Author: Jamal Hadi Salim Date: Tue Aug 25 04:14:03 2026 -0400 net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup [ Upstream commit 8f735d64382dcf162f4276d6699d03ad2f859c0b ] qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081403.133992-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e87d78a14103724381b66dcf4168b5a3d8bfb2af Author: Maxime Chevallier Date: Wed Aug 26 16:04:57 2026 +0200 net: stmmac: selftests: Account for the UC filter list for filtering tests [ Upstream commit cd8c3b2752c684141eab2282e294cae2971a9759 ] On dwmac, one of the Unicast filter entries is used to store the local HW addr. This means that we have to use promisc mode for any kind of unicast filtering if we only have one slot in our unicast filter. The number of slots available depends on how the IP is integrated, and we can't autodiscover how many of these slots we have available, so the DT property snps,perfect-filter-entries can be used to specify how many are available. Most IP variants default to 1 if this isn't specified, which is the case for the amlogic variants (in this case, S905X3). The stmmac selftests for UC filtering look if we have enough slots in the filter to store the dev->uc list, but doesn't account for the device's own MAC address. The dev->uc list's size we get with netdev_uc_count() also doesn't account for the HW addr. As the selftest only requires one available slot, in the case of single-slot platforms, that means we erroneously consider we have enough room for the test, when we actually don't, and the filtering test fails. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87ed160b98cfedfb9ae1a45b145753c2292bed3a Author: Maxime Chevallier Date: Wed Aug 26 16:04:56 2026 +0200 net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering [ Upstream commit 2739d6f9a2b8729b0d85cbe0dc93e1d68670b6f2 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97afcd57609b2f07d2956ae8447f7be03b800505 Author: Maxime Chevallier Date: Wed Aug 26 16:04:55 2026 +0200 net: stmmac: dwmac4: Account for the primary MAC address for UC filtering [ Upstream commit 82187f42c014d22520b9c3c4e2cfb519223fb29b ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1225508e960d16e9ca06918df726ecf59160be47 Author: Maxime Chevallier Date: Wed Aug 26 16:04:54 2026 +0200 net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering [ Upstream commit 9698b6da3714fd2ef47846cb63098d2b2d252e25 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 940bc5936487e52b8dfcdc88d10f0a6cd17ac122 Author: Maxime Chevallier Date: Wed Aug 26 16:04:53 2026 +0200 net: stmmac: selftests: Check multiple MMC counters [ Upstream commit d29b399150b07796dfa81d8778d4804c08c2a41d ] The MMC counters report MAC statistics. Multiple counters can be enabled when the IP is integrated, however there's no way to know exactly which ones. Un-implemented counters seem to report 0. It was found that on StarFive JH7110 and Amlogic SM1, the counter that's used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering an MMC selftest failure. Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use this counter as well for MMC counter validation. Note that this doesn't guarantee that we won't encounter the same issue again if another IP implements yet another set of counters that don't include that new one. If the game of whack-a-mole with implemented counters becomes too hard to maintain, we may simply consider removing the MMC selftest entirely. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd3c3ebddd63b199227f26879f549eebbc89c7ef Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:35 2026 +0100 selftests/arm64: Treat KSM merge_across_nodes as optional [ Upstream commit 1a0dba077f34a2f8faa98308d30d4b546d073145 ] The MTE KSM test requires write access to KSM sysfs but does not check that it is running as root. It also unconditionally saves, enables and restores the merge_across_nodes attribute. The kernel only creates this attribute when CONFIG_NUMA=y, so a non-NUMA kernel prints the following message three times even though every KSM subtest passes: # ERR: missing /sys/kernel/mm/ksm/merge_across_nodes Skip the test when it is not running as root. Check that the optional attribute is readable and writable, treating ENOENT as its expected absence on non-NUMA kernels and skipping the test for other access failures. Only save, enable and restore the attribute when it is available. Check MTE availability before the privilege and sysfs checks so systems without MTE retain the existing feature-unavailable skip result. This preserves the existing behavior on NUMA kernels without requiring NUMA or reducing KSM coverage on single-node systems. Fixes: f981d8fa2646 ("kselftest/arm64: Verify KSM page merge for MTE pages") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 88338e9bd73010424267cef40cef6f09adba5cf4 Author: Pablo Neira Ayuso Date: Tue Aug 18 10:31:24 2026 +0200 netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited() [ Upstream commit 793d9eda4821f75b5f7cc9e6a870b72a58b44c2b ] Several xtables extension still use pr_err() or pr_info() without ratelimit. For xt_cgroup, while at this, remove redundant "xt_cgroup:" prefix since pr_fmt is already set on. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit dce8865d03ff0ba553951842889603d299ac3789 Author: Marino Dzalto Date: Fri Apr 3 22:59:07 2026 +0200 netfilter: xt_HL: add pr_fmt and checkentry validation [ Upstream commit 24bd5c2679caf8a228d90cafa221da4b47fd6642 ] Add pr_fmt to prefix log messages with the module name for easier debugging in dmesg. Add checkentry functions for IPv4 (ttl_mt_check) and IPv6 (hl_mt6_check) to validate the match mode at rule registration time, rejecting invalid modes with -EINVAL. The evaluation function returns false in case the mode is unknown, so this is a cleanup, not a bug fix. Signed-off-by: Marino Dzalto Signed-off-by: Florian Westphal Stable-dep-of: 793d9eda4821 ("netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()") Signed-off-by: Sasha Levin commit f240f0781799f04e94142859ff9f3ce3042df595 Author: Michal Koutný Date: Tue Apr 1 13:57:30 2025 +0200 netfilter: xt_cgroup: Make it independent from net_cls [ Upstream commit 3ba0032afea888d0edebf5ece3c6b36417189b63 ] The xt_group matching supports the default hierarchy since commit c38c4597e4bf3 ("netfilter: implement xt_cgroup cgroup2 path match"). The cgroup v1 matching (based on clsid) and cgroup v2 matching (based on path) are rather independent. Downgrade the Kconfig dependency to mere CONFIG_SOCK_GROUP_DATA so that xt_group can be built even without CONFIG_NET_CLS_CGROUP for path matching. Also add a message for users when they attempt to specify any clsid. Link: https://lists.opensuse.org/archives/list/kernel@lists.opensuse.org/thread/S23NOILB7MUIRHSKPBOQKJHVSK26GP6X/ Cc: Jan Engelhardt Cc: Florian Westphal Signed-off-by: Michal Koutný Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 793d9eda4821 ("netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()") Signed-off-by: Sasha Levin commit 923f824f30faebc5560c3061a595063cecdbdbb8 Author: Pablo Neira Ayuso Date: Thu Aug 13 02:16:02 2026 +0200 netfilter: nf_tables: move hardware offload step after building the chain blob [ Upstream commit b1881d362e1924b66f6016c3efd28807032b41bf ] Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f94cf20dba40b0f22310dfd43e9e3722f62b1550 Author: bui duc phuc Date: Mon Aug 24 17:09:01 2026 +0700 net: ethernet: sun4i-emac: Fix IRQ error handling [ Upstream commit 991c2be78257cba5bf53cf935fe70f8836964288 ] irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails. The current code checks for -ENXIO and therefore does not detect the failure. Check for a zero return value and convert it to -ENXIO. Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: bui duc phuc Reviewed-by: Andre Przywara Link: https://patch.msgid.link/20260824100901.31675-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 57ab955bde747327fb2042516ae1b7192c30e881 Author: HyeongJun An Date: Tue Aug 25 21:57:45 2026 +0900 ASoC: dapm: Fix off-by-one check on the second enum channel [ Upstream commit 14511c9b54ceeeef487409d73947c89ee8563590 ] The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off. Fixes: 3727b4968453 ("ASoC: dapm: Consolidate MUXs and value MUXs") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260825125745.932832-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 88ba930e7d0586ca2700757249f1e6fc0bbab0fc Author: John Johansen Date: Mon Aug 24 11:01:18 2026 -0700 apparmor: policy_int make sure list heads are initialized before fail path [ Upstream commit 3daad923a8685adb66087e0d819559b7eb6ba975 ] If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18 Reported-by: syzbot+faed97c4ed43bfe7fee5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=faed97c4ed43bfe7fee5 Fixes: fe6bb31f590c9 ("apparmor: split out shared policy_XXX fns to lib") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit cf555bfdbdaa4165e66bca631a185f11d86ebb85 Author: Thorsten Blum Date: Sat Nov 22 12:55:51 2025 +0100 apparmor: Replace sprintf/strcpy with scnprintf/strscpy in aa_policy_init [ Upstream commit b31d3f7385fbb49681d44e7104cfa033cba4b1e8 ] strcpy() is deprecated and sprintf() does not perform bounds checking either. Although an overflow is unlikely, it's better to proactively avoid it by using the safer strscpy() and scnprintf(), respectively. Additionally, unify memory allocation for 'hname' to simplify and improve aa_policy_init(). Closes: https://github.com/KSPP/linux/issues/88 Reviewed-by: Serge Hallyn Signed-off-by: Thorsten Blum Signed-off-by: John Johansen Stable-dep-of: 3daad923a868 ("apparmor: policy_int make sure list heads are initialized before fail path") Signed-off-by: Sasha Levin commit e6a475f2d2390e972ff8e8bb15114684a027060e Author: Ruoyu Wang Date: Thu Aug 13 23:30:32 2026 +0800 tpm: st33zp24: Validate locality read result [ Upstream commit 264216889d39df509b9c8045df53529480b0b718 ] check_locality() treats every nonzero transport return as success. SPI errors remain negative, while the I2C path can convert a negative write error through its byte-sized status variable. Either result is nonzero even though the TPM_ACCESS byte can remain unwritten, so indeterminate ACTIVE_LOCALITY and VALID bits can falsely report an active locality. Require recv() to return exactly the requested byte before examining TPM_ACCESS. Transport errors and short reads now report an inactive locality, while successful reads retain the existing behavior. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-2-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit d732cfc4befe28f02ec82ed5fd2bc2a21fbabd42 Author: Ruoyu Wang Date: Fri Aug 21 04:38:05 2026 +0300 tpm: st33zp24: Return zero on status read failure [ Upstream commit 8b92687708f5ef980de01c2042dbd76d11f78547 ] st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-1-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 1360bc93f5be1be3cf937ebea667b3418dd30a79 Author: Victor Nogueira Date: Mon Aug 24 08:59:28 2026 -0300 net/sched: sch_teql: restore skb->dev on the slave failure path [ Upstream commit dc4b95b8fee95113587e93ca116356032d271371 ] teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration. Fixes: 0cc0c2e661af ("net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824115928.4099988-1-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 86799499585af06a9431c9e7782658667bd62650 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:09 2026 -0400 net/sched: sfq: clamp quantum to avoid signed overflow soft lockup [ Upstream commit 816e90057ab1879562a5b7cc688e35bb9027ae97 ] sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-7-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2e0f0729f922c8de13801004e2131b57646c7c5f Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:08 2026 -0400 net/sched: hhf: clamp quantum before hhf_change() to avoid overflow [ Upstream commit 2164b512b97bb053e8ce4d6e95576f11bed6a005 ] hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-6-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1f43e4dbc93b7d02761a024d5f895df823c07b72 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:07 2026 -0400 net/sched: fq_pie: clamp default quantum to avoid signed overflow [ Upstream commit c86cd7ed0b0e44779a3d1683f03e4353baf4bdc9 ] fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-5-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c0bc1901b5039ce46b8322f4cbff69c5f0e4d9a4 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:06 2026 -0400 net/sched: sch_codel: clamp default mtu to avoid disabling CoDel [ Upstream commit 6439461f1618ae176c048673ad28bdb6c68efbfc ] codel_init() sets q->params.mtu = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000. In codel_should_drop() the test "*backlog <= params->mtu" then compares the backlog against ~2 GiB; with the default sch->limit of DEFAULT_CODEL_LIMIT (1000) packets the backlog can never reach it, so the test is always true and CoDel is silently and completely disabled i.e no drops, no ECN marking, codel degrades to a tail-drop FIFO. codel_change() never updates params.mtu, so the init path is the only place to clamp it. Constrain to [256, 1 << 20], matching the fq_codel bound; 256 is a sane floor that only makes CoDel slightly more willing to act on very small queues, which is the safe direction. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-4-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d315ee8a07fd1810880227319cf60e6cd925ef22 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:05 2026 -0400 net/sched: fq_codel: clamp default quantum and mtu [ Upstream commit d9ebd8f9aa8b2773235889cb903fafd61f2d8585 ] fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests "*backlog <= params->mtu"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-3-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 74cd3aa92a67e69d8dd4b39e2f8ef758e6524595 Author: Eric Dumazet Date: Mon Oct 2 13:17:36 2023 +0000 net_sched: export pfifo_fast prio2band[] [ Upstream commit 5579ee462dfe768297563a6083e21df52c3ad856 ] pfifo_fast prio2band[] is renamed to sch_default_prio2band[] and exported because we want to share it in FQ. Signed-off-by: Eric Dumazet Acked-by: Dave Taht Reviewed-by: Willem de Bruijn Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Paolo Abeni Stable-dep-of: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Signed-off-by: Sasha Levin commit 8fac3bd41c5272cf6d01e49cc4e628e7697fa000 Author: Eric Dumazet Date: Wed Sep 20 20:17:13 2023 +0000 net_sched: sch_fq: change how @inactive is tracked [ Upstream commit ee9af4e14d166c34ec78896bb1ba545249445df0 ] Currently, when one fq qdisc has no more packets to send, it can still have some flows stored in its RR lists (q->new_flows & q->old_flows) This was a design choice, but what is a bit disturbing is that the inactive_flows counter does not include the count of empty flows in RR lists. As next patch needs to know better if there are active flows, this change makes inactive_flows exact. Before the patch, following command on an empty qdisc could have returned: lpaa17:~# tc -s -d qd sh dev eth1 | grep inactive flows 1322 (inactive 1316 throttled 0) flows 1330 (inactive 1325 throttled 0) flows 1193 (inactive 1190 throttled 0) flows 1208 (inactive 1202 throttled 0) After the patch, we now have: lpaa17:~# tc -s -d qd sh dev eth1 | grep inactive flows 1322 (inactive 1322 throttled 0) flows 1330 (inactive 1330 throttled 0) flows 1193 (inactive 1193 throttled 0) flows 1208 (inactive 1208 throttled 0) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Signed-off-by: Sasha Levin commit b7901fc5c32c9443babe8cb0b6858b155b95e7cc Author: Eric Dumazet Date: Wed Sep 20 20:17:12 2023 +0000 net_sched: sch_fq: struct sched_data reorg [ Upstream commit 54ff8ad69c6e93c0767451ae170b41c000e565dd ] q->flows can be often modified, and q->timer_slack is read mostly. Exchange the two fields, so that cache line countaining quantum, initial_quantum, and other critical parameters stay clean (read-mostly). Move q->watchdog next to q->stat_throttled Add comments explaining how the structure is split in three different parts. pahole output before the patch: struct fq_sched_data { struct fq_flow_head new_flows; /* 0 0x10 */ struct fq_flow_head old_flows; /* 0x10 0x10 */ struct rb_root delayed; /* 0x20 0x8 */ u64 time_next_delayed_flow; /* 0x28 0x8 */ u64 ktime_cache; /* 0x30 0x8 */ unsigned long unthrottle_latency_ns; /* 0x38 0x8 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct fq_flow internal __attribute__((__aligned__(64))); /* 0x40 0x80 */ /* XXX last struct has 16 bytes of padding */ /* --- cacheline 3 boundary (192 bytes) --- */ u32 quantum; /* 0xc0 0x4 */ u32 initial_quantum; /* 0xc4 0x4 */ u32 flow_refill_delay; /* 0xc8 0x4 */ u32 flow_plimit; /* 0xcc 0x4 */ unsigned long flow_max_rate; /* 0xd0 0x8 */ u64 ce_threshold; /* 0xd8 0x8 */ u64 horizon; /* 0xe0 0x8 */ u32 orphan_mask; /* 0xe8 0x4 */ u32 low_rate_threshold; /* 0xec 0x4 */ struct rb_root * fq_root; /* 0xf0 0x8 */ u8 rate_enable; /* 0xf8 0x1 */ u8 fq_trees_log; /* 0xf9 0x1 */ u8 horizon_drop; /* 0xfa 0x1 */ /* XXX 1 byte hole, try to pack */ u32 flows; /* 0xfc 0x4 */ /* --- cacheline 4 boundary (256 bytes) --- */ u32 inactive_flows; /* 0x100 0x4 */ u32 throttled_flows; /* 0x104 0x4 */ u64 stat_gc_flows; /* 0x108 0x8 */ u64 stat_internal_packets; /* 0x110 0x8 */ u64 stat_throttled; /* 0x118 0x8 */ u64 stat_ce_mark; /* 0x120 0x8 */ u64 stat_horizon_drops; /* 0x128 0x8 */ u64 stat_horizon_caps; /* 0x130 0x8 */ u64 stat_flows_plimit; /* 0x138 0x8 */ /* --- cacheline 5 boundary (320 bytes) --- */ u64 stat_pkts_too_long; /* 0x140 0x8 */ u64 stat_allocation_errors; /* 0x148 0x8 */ u32 timer_slack; /* 0x150 0x4 */ /* XXX 4 bytes hole, try to pack */ struct qdisc_watchdog watchdog; /* 0x158 0x48 */ /* size: 448, cachelines: 7, members: 34 */ /* sum members: 411, holes: 2, sum holes: 5 */ /* padding: 32 */ /* paddings: 1, sum paddings: 16 */ /* forced alignments: 1 */ }; pahole output after the patch: struct fq_sched_data { struct fq_flow_head new_flows; /* 0 0x10 */ struct fq_flow_head old_flows; /* 0x10 0x10 */ struct rb_root delayed; /* 0x20 0x8 */ u64 time_next_delayed_flow; /* 0x28 0x8 */ u64 ktime_cache; /* 0x30 0x8 */ unsigned long unthrottle_latency_ns; /* 0x38 0x8 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct fq_flow internal __attribute__((__aligned__(64))); /* 0x40 0x80 */ /* XXX last struct has 16 bytes of padding */ /* --- cacheline 3 boundary (192 bytes) --- */ u32 quantum; /* 0xc0 0x4 */ u32 initial_quantum; /* 0xc4 0x4 */ u32 flow_refill_delay; /* 0xc8 0x4 */ u32 flow_plimit; /* 0xcc 0x4 */ unsigned long flow_max_rate; /* 0xd0 0x8 */ u64 ce_threshold; /* 0xd8 0x8 */ u64 horizon; /* 0xe0 0x8 */ u32 orphan_mask; /* 0xe8 0x4 */ u32 low_rate_threshold; /* 0xec 0x4 */ struct rb_root * fq_root; /* 0xf0 0x8 */ u8 rate_enable; /* 0xf8 0x1 */ u8 fq_trees_log; /* 0xf9 0x1 */ u8 horizon_drop; /* 0xfa 0x1 */ /* XXX 1 byte hole, try to pack */ u32 timer_slack; /* 0xfc 0x4 */ /* --- cacheline 4 boundary (256 bytes) --- */ u32 flows; /* 0x100 0x4 */ u32 inactive_flows; /* 0x104 0x4 */ u32 throttled_flows; /* 0x108 0x4 */ /* XXX 4 bytes hole, try to pack */ u64 stat_throttled; /* 0x110 0x8 */ struct qdisc_watchdog watchdog; /* 0x118 0x48 */ /* --- cacheline 5 boundary (320 bytes) was 32 bytes ago --- */ u64 stat_gc_flows; /* 0x160 0x8 */ u64 stat_internal_packets; /* 0x168 0x8 */ u64 stat_ce_mark; /* 0x170 0x8 */ u64 stat_horizon_drops; /* 0x178 0x8 */ /* --- cacheline 6 boundary (384 bytes) --- */ u64 stat_horizon_caps; /* 0x180 0x8 */ u64 stat_flows_plimit; /* 0x188 0x8 */ u64 stat_pkts_too_long; /* 0x190 0x8 */ u64 stat_allocation_errors; /* 0x198 0x8 */ /* Force padding: */ u64 :64; u64 :64; u64 :64; u64 :64; /* size: 448, cachelines: 7, members: 34 */ /* sum members: 411, holes: 2, sum holes: 5 */ /* padding: 32 */ /* paddings: 1, sum paddings: 16 */ /* forced alignments: 1 */ }; Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Signed-off-by: Sasha Levin commit 4f707870afeeaee72d3b51e1b4508f175eafcef5 Author: Jiapeng Chong Date: Mon Oct 17 17:35:40 2022 +0800 net: ip6_gre: Remove the unused function ip6gre_tnl_addr_conflict() [ Upstream commit f00909e2e6fe4ac6b2420e3863a0c533fe4f15e0 ] The function ip6gre_tnl_addr_conflict() is defined in the ip6_gre.c file, but not called elsewhere, so delete this unused function. net/ipv6/ip6_gre.c:887:20: warning: unused function 'ip6gre_tnl_addr_conflict'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2419 Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Link: https://lore.kernel.org/r/20221017093540.26806-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Paolo Abeni Stable-dep-of: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Signed-off-by: Sasha Levin commit 650381e0c6536f112a0f922b72c4f81e1f24777a Author: Frank Sorenson Date: Sat Aug 8 15:29:03 2026 -0500 cifs: fix clearing stats for fastest execution of each smb2 command [ Upstream commit 48cab1fd5720508148673f59d8ed52c7c7fffca2 ] The code to clear the 'fastest_cmd' statistics has a typo that repeatedly clears the stat for cmd 0, rather than iterating through each cmd. Fix the typo (0->i). Fixes: 433b8dd7672be ("SMB3: Track total time spent on roundtrips for each SMB3 command") Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 2a809d7896dbf18e1ecfbdd930f71c9fc298b16d Author: Allison Henderson Date: Fri Aug 21 22:26:47 2026 -0700 net/rds: use wq_has_sleeper() in rds_cong_map_updated() [ Upstream commit d4f484661961636eb90d287050959e613795f73a ] rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern. Fixes: 922cb17a5c81 ("RDS: Congestion-handling code") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260822052647.88318-1-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5aaa7409c1b4ca4c60d66e2afa99703bf4eb7ddd Author: Xiang Mei Date: Thu Aug 20 12:52:40 2026 -0700 net: qualcomm: rmnet: restore skb->dev on deaggregated frames [ Upstream commit a66734a1c5e36525ea07e9f4547fddc51e916de3 ] rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 378e25357ac7 ("net: qualcomm: rmnet: Remove unnecessary device assignment") Reported-by: co+4638111fe2a12980@bugs.sh Closes: https://lore.kernel.org/netdev/ijg79FFMfIvKJbivdJEKvTO90Q9dTvyBkJck@bugs.sh/T/#u Signed-off-by: Xiang Mei Reviewed-by: Subash Abhinov Kasiviswanathan Link: https://patch.msgid.link/20260820195240.1631458-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fcafb2b1430824bae4258c01a439ec97ca0c6973 Author: Cen Zhang (Microsoft) Date: Wed Aug 19 22:07:35 2026 -0400 gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free [ Upstream commit d989e22ae9802c52c56ad4284d0caf26696cf6ae ] gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets(). Fixes: 459aa660eb1d8ce6 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260820020735.59474-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e7c0aa45ae6c5a338661b23812bfcdef50bf3e96 Author: Hyunwoo Kim Date: Fri Mar 20 00:14:58 2026 +0900 Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop [ Upstream commit 44c98fd082eafd49d55a8a4077ff488175b2fe24 ] rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 14cf26d6dbedb82d8a33c7761bbff8a92078ec7d Author: Chris Lu Date: Mon Aug 17 17:53:31 2026 +0800 Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX [ Upstream commit 155e3003d1e614f85566b636973df7118e1b4851 ] btmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push() and writes into that space after only checking the headroom size. On a cloned SKB that headroom belongs to a buffer shared with the other owner, which the driver has no right to write to. Cloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every HCI command in hdev->sent_cmd before handing the SKB to the driver, and l2cap_ertm_send() clones SKBs for retransmission. Replace the open-coded headroom check with skb_cow_head(), which both guarantees the headroom and reallocates a private buffer when the SKB is cloned. The cost is one reallocation and copy per cloned packet, the usual price of this pattern in network drivers. This has no observable effect on its own, as the driver only writes in front of skb->data where no other owner looks. It is a prerequisite for "Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", which writes padding behind skb->tail, and carries the same Fixes: tag so that both are backported together. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bd9997c3ccce3d76996cdd22c81222f3b8edeb08 Author: Pauli Virtanen Date: Sat Apr 11 21:15:09 2026 +0300 Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister [ Upstream commit 9707a015fe8f3ba8ec7c270f3b2b8efb38823d6b ] 6lowpan.c has theoretically conflicting lock orderings, which lockdep complains about: a) rtnl_lock > hdev->workqueue from 6lowpan.c:delete_netdev -> rtnl_lock -> device_del -> put_device(parent) -> hci_release_dev -> destroy_workqueue b) hdev->workqueue > l2cap_conn->lock > chan->lock > rtnl_lock from hci_rx_work -> 6lowpan.c:chan_ready_cb -> lowpan_register_netdev, ifup -> rtnl_lock Actual deadlock appears not possible, as hci_rx_work is disabled and l2cap_conn flushed already on hdev unregister. Hence, do minimal thing to make lockdep happy by breaking chain a) by holding hdev refcount until after netdev put in 6lowpan.c. Fixes the lockdep complaint: WARNING: possible circular locking dependency detected. kworker/0:1/11 is trying to acquire lock: ffff8880023b3940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x8b/0x130 but task is already holding lock: ffffffff95e4f9c0 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30 Workqueue: events delete_netdev Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: d4bfa78fd679 ("Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN") Signed-off-by: Sasha Levin commit 2243127db6ba20cbef90c6349a2b1000af401d2e Author: Edward Adam Davis Date: Sat Jun 15 09:45:54 2024 +0800 bluetooth/l2cap: sync sock recv cb and release [ Upstream commit 89e856e124f9ae548572c56b1b70c2255705f8fe ] The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. Reported-and-tested-by: syzbot+b7f6f8c9303466e16c8a@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: d4bfa78fd679 ("Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN") Signed-off-by: Sasha Levin commit ee91a3ced6c964fe299d9818447789d8533258dc Author: Sebastian Urban Date: Wed May 1 12:08:58 2024 +0200 Bluetooth: compute LE flow credits based on recvbuf space [ Upstream commit ce60b9231b66710b6ee24042ded26efee120ecfc ] Previously LE flow credits were returned to the sender even if the socket's receive buffer was full. This meant that no back-pressure was applied to the sender, thus it continued to send data, resulting in data loss without any error being reported. Furthermore, the amount of credits was essentially fixed to a small amount, leading to reduced performance. This is fixed by computing the number of returned LE flow credits based on the estimated available space in the receive buffer of an L2CAP socket. Consequently, if the receive buffer is full, no credits are returned until the buffer is read and thus cleared by user-space. Since the computation of available receive buffer space can only be performed approximately (due to sk_buff overhead) and the receive buffer size may be changed by user-space after flow credits have been sent, superfluous received data is temporary stored within l2cap_pinfo. This is necessary because Bluetooth LE provides no retransmission mechanism once the data has been acked by the physical layer. If receive buffer space estimation is not possible at the moment, we fall back to providing credits for one full packet as before. This is currently the case during connection setup, when MPS is not yet available. Fixes: b1c325c23d75 ("Bluetooth: Implement returning of LE L2CAP credits") Signed-off-by: Sebastian Urban Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: d4bfa78fd679 ("Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN") Signed-off-by: Sasha Levin commit ceaff037e08a1ced682434ff6702c4cfcbce564f Author: Dan Carpenter Date: Thu Aug 13 10:09:53 2026 +0300 scsi: qla2xxx: Fix an loop timeout test [ Upstream commit 11e48f5201fd86ffa038809dd9c41144d43ee2e4 ] This loop timeout with "retries" set to -1, not 0. Fix the test for failure. Fixes: 7ec0effd30bb ("[SCSI] qla2xxx: Add support for ISP8044.") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1twcxTYSFkkUTA@stanley.mountain Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit ffb100b0da0e217d5d63ce6fe092f9c29e59f7dd Author: Junrui Luo Date: Sun Aug 16 16:01:28 2026 +0800 NFSv4/pnfs: key the data server cache on the NFS version [ Upstream commit 13c23c5cb977f66390795437fd3837887ce1fd75 ] nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 345c7891658630d6e102ce6ce928f8101bfc2430 Author: Jeff Layton Date: Thu Apr 10 16:42:04 2025 -0400 nfs: move the nfs4_data_server_cache into struct nfs_net [ Upstream commit d5fb22a7c585b12ec3e6cef150689f7386e8cfd0 ] Since struct nfs4_pnfs_ds should not be shared between net namespaces, move from a global list of objects to a per-netns list and spinlock. Tested-by: Sargun Dillon Signed-off-by: Jeff Layton Reviewed-by: Benjamin Coddington Link: https://lore.kernel.org/r/20250410-nfs-ds-netns-v2-2-f80b7979ba80@kernel.org Signed-off-by: Trond Myklebust Stable-dep-of: 13c23c5cb977 ("NFSv4/pnfs: key the data server cache on the NFS version") Signed-off-by: Sasha Levin commit 842ac26615424577f24f0486b9d3bf97f28fad9c Author: Junrui Luo Date: Sun Aug 16 16:01:27 2026 +0800 NFSv4.2: fix LAYOUTSTATS send buffer exhaustion [ Upstream commit c75ef2137e749f2673f0617cfdaae53b2bb7195a ] encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation. Fixes: 27c430644369 ("pnfs/flexfiles: encode LAYOUTSTATS flexfiles specific data") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 8e3deb150a5237b672c4579e69a6deb02027dbed Author: Mahanta Jambigi Date: Tue Aug 18 09:39:43 2026 +0200 net/smc: free pending qentry in smc_llc_flow_stop() before memset [ Upstream commit 5ee0ceddc7785c6dcf4a8107fef01f0414a354f4 ] smc_llc_flow_stop() resets a flow struct with a blind memset: spin_lock_bh(&lgr->llc_flow_lock); memset(flow, 0, sizeof(*flow)); flow->type = SMC_LLC_FLOW_NONE; spin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op. Fixes: 555da9af827d ("net/smc: add event-based llc_flow framework") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073943.1108383-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8250d85e7b5ee7da0ab8ea8d7308c6d2b3d988b9 Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: stop the tx_timeout register dump past the requested window [ Upstream commit cfa9178ce2e5b4f2e2a9e8b577a6cff841665aa0 ] nv_tx_timeout() dumps the register window in rows of eight dwords: for (i = 0; i <= np->register_size; i += 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base = ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <= register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >= register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <= to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367886.3748309.6978554332066826294@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f842beb02945efc57f29aa62f4a26f740feeeea4 Author: Fan Ye Date: Sat Aug 15 10:21:52 2026 +0000 net: thunderbolt: Count delivered packets in rx_packets and rx_bytes [ Upstream commit c5ae83ee02c04487b1be1d143b791ec2caca888e ] tbnet_poll() increments rx_packets once per received frame because that is the NAPI work unit, and then adds the same number to stats.rx_packets. An skb is handed to the stack only when the last frame of a packet arrives, so once the MTU exceeds TBNET_MAX_PAYLOAD_SIZE the statistic reports frames. tx_packets is bumped once per skb, so the two ends of a link disagree: at MTU 65330 the receiver reports 16 times the packets its sender sent. rx_bytes has the matching problem: frames of a packet that is later dropped mid-assembly are already accounted, so it does not correspond to rx_packets as documented. Account for both where the packet is completed, and leave the NAPI work counter alone. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan Ye Reviewed-by: Simon Horman Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260815-tbnet-rx-stats-v1-1-8da375c2cd09@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1181f6bad009408a259bab6aaf0681f11b487972 Author: Ruoyu Wang Date: Fri Aug 14 21:40:53 2026 +0800 net: bridge: Reject descending VLAN tunnel ranges [ Upstream commit b74a072d8fb71d3c9ffba4a17d5943e63266fb38 ] A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api") Signed-off-by: Ruoyu Wang Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260814134053.1387275-1-ruoyuw560@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a26ca41961cfdd2b3f26e9be00b4f41ed64c774 Author: Serhat Kumral Date: Thu Aug 6 23:13:58 2026 +0300 RDMA/ucma: Allow path records to exactly fit the output buffer [ Upstream commit 8049741ac93acd3a590dac070e12571fddf0e294 ] ucma_query_path() emits a path record only when the remaining output buffer is strictly larger than struct ib_path_rec_data. A buffer sized exactly for the response header and N complete records therefore gets only N - 1 records, while resp->num_paths still advertises N. A caller sizing its buffer for a single record gets a header claiming one path and no path data at all. ucma_query_ib_service() in the same file computes the record count with a plain division and so accepts an exact fit; make ucma_query_path() behave the same way. Current librdmacm is unaffected because it always sizes the response for six records while the kernel currently reports at most two paths. Other users of the UAPI that provide an exactly sized buffer can observe the truncated response. Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not reversible") Signed-off-by: Serhat Kumral Link: https://patch.msgid.link/20260806201358.147478-1-serhatkumral1@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e22e5a7fabf4f1755d98eb9838ece714b97bdf51 Author: Bradley Morgan Date: Sun Aug 9 00:29:01 2026 +0000 prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator [ Upstream commit 5146e0688d86f0654263e4b0e4ff1719b4072f16 ] prctl_set_auxv() copies the user vector into a stack buffer, forces AT_NULL on the last two entries there, and then copies only len bytes into mm->saved_auxv. Which is fine until the vector is shorter than the buffer, because then the forced terminator sits past the end of the copy and never lands in saved_auxv at all. The code even says /* Make sure the last entry is always AT_NULL */ and it does, just not in the part that gets copied. So mm->saved_auxv keeps the stale tail from exec. Reproducing it is easy: from a process with CAP_SYS_RESOURCE (just run it as root), call prctl(PR_SET_MM, PR_SET_MM_AUXV, ...) with a vector that has a couple of entries and no AT_NULL inside len (32 bytes on arm64), and then hexdump /proc/self/auxv, or gcore the process and look at the AUXV note with readelf -n. This is arm64, the new vector was just { AT_UID, 0x1111, AT_GID, 0x2222 }: idx before (from exec) after the prctl [0] AT_SYSINFO_EHDR 0x7ed1d6e000 AT_UID 0x1111 <- new [1] AT_MINSIGSTKSZ 0x1270 AT_GID 0x2222 <- new [2] AT_HWCAP 0x119fff AT_HWCAP 0x119fff <- stale [3] AT_PAGESZ 0x1000 AT_PAGESZ 0x1000 <- stale ... 16 more entries ... <- stale [20] AT_NULL 0x0 AT_NULL 0x0 21 entries before the prctl, still 21 after: the two new ones plus all 19 left over from exec. Every consumer walks the vector until AT_NULL, so what they get now is a vector that never existed at exec, the head from the prctl glued onto the tail of the old binary. gdb and crash pull the AUXV note out of coredumps to find AT_PHDR, AT_ENTRY, AT_SYSINFO_EHDR and friends, and a mixed vector points them at the wrong layout. /proc//auxv and PR_GET_AUXV hand the same mess out to live processes too. Nothing crashes, everything just quietly reads a frankenstein auxv. And callers that terminate their own vector hide the whole thing, which is likely why nobody noticed since PR_SET_MM_AUXV landed in 2012. Nothing exciting security wise either, I mean it needs CAP_SYS_RESOURCE to begin with. prctl_set_mm_map() right above already copies the whole buffer for exactly this reason, so just do the same here. user_auxv is zero initialized and only partially filled from userspace, so the rest is zeros and nothing leaks. Link: https://lore.kernel.org/20260809002901.32591-1-include@grrlz.net Fixes: fe8c7f5cbf91 ("c/r: prctl: extend PR_SET_MM to set up more mm_struct entries") Signed-off-by: Bradley Morgan Cc: Alexey Dobriyan Cc: Cyrill Gorcuno Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2b5622cf4ee218b6f98d31dbf3fbd44b9b6bd675 Author: Yi Ding Date: Mon Jun 1 20:51:35 2026 -0700 rtc: pcf8563: fix clock provider leak on unbind [ Upstream commit 9c48a53685040bb0de45a640b34055cbbfc69d4f ] pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own). Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Link: https://patch.msgid.link/20260602035135.62264-1-yi.s.ding@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c93defccf5eb0a92bdafa43487be6ce0221a2477 Author: Li RongQing Date: Wed Jul 1 19:36:08 2026 +0800 vdpa/mlx5: fix wrong list iterated in add_direct_chain error path [ Upstream commit 23ae56d9e74c122f95cae71ae3b9fc259fb88446 ] In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Li RongQing Acked-by: Eugenio Pérez Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-ID: <20260701113608.1972-1-lirongqing@baidu.com> Signed-off-by: Sasha Levin commit ad4fed329b6d0ee09b3f0bf7ed598c7a4ea14553 Author: Michael S. Tsirkin Date: Sun Jul 5 02:24:18 2026 -0400 virtio_balloon: disable indirect descriptors [ Upstream commit 281eb4732aae5473141b84e106fe906c69b2ff3d ] The page reporting callback submits an sg list to the reporting virtqueue. With VIRTIO_RING_F_INDIRECT_DESC negotiated and total_sg > 1 (which it typically is), virtqueue_add reports it to the host by allocating an indirect descriptor via kmalloc(GFP_KERNEL). This is not pretty: the reporting worker isolates potentially hundreds of MB of free pages from the buddy allocator (reported pages are at least pageblock_order, and the sg can contain up to PAGE_REPORTING_CAPACITY entries of varying orders). As the result, very theoretically, the kmalloc might trigger OOM when we have in fact a ton of free memory. Clear VIRTIO_RING_F_INDIRECT_DESC, to avoid using indirect descriptors. Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <73fac8a629fd9aca7bb3265ac243a769c28af25d.1783232420.git.mst@redhat.com> Signed-off-by: Sasha Levin commit 1be48fef50a56ab941d78622fdf0845119720119 Author: Ruoyu Wang Date: Thu Aug 13 23:31:26 2026 +0800 bonding: initialize err for empty target lists [ Upstream commit 8ccc9bf9afeeb46a437081c07154fbf5964682b2 ] Empty NLA_NESTED attributes are valid, and bonding uses them to clear the ARP and NS target lists. When either target attribute is empty, nla_for_each_nested() does not execute, so err retains an uninitialized value before it is tested. The request can consequently return an unpredictable error after clearing the targets. Initialize err to zero so an empty target list completes successfully. Non-empty lists still propagate errors from __bond_opt_set() unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 4fb0ef585eb2 ("bonding: convert arp_ip_target to use the new option API") Signed-off-by: Ruoyu Wang Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260813153126.3952893-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ff319d34fffb63c6dcc19ed0ef87f358bb4b2ef Author: Nguyen Dinh Phi Date: Fri Aug 14 01:30:20 2026 +0800 vsock: use sock_error() to consume sk_err after a failed connect [ Upstream commit 96cbf89993091a163bfedec52a3bd683dc94b3b4 ] vsock_connect() returns sk_err to userspace but does not clear it: if (sk->sk_err) { err = -sk->sk_err; For a blocking connect() the error has already been delivered as connect()'s return value, so leaving it set causes subsequent operations like poll()/epoll() to keep reporting POLLERR even though the connect failure was already delivered. The error should be consumed once it has been returned to userspace. Switch to sock_error(), which reads and clears sk_err atomically, matching the behavior of other protocol implementations such as __inet_stream_connect(). Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Tested-by: Wupeng Ma Reviewed-by: Stefano Garzarella Signed-off-by: Nguyen Dinh Phi Link: https://patch.msgid.link/20260813173024.2362935-4-phind.uet@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8b332e1aa57c225bc1cd6f0058af18ec68f6ba2c Author: Karl Mehltretter Date: Mon Aug 17 06:30:57 2026 +0200 8139cp: fix Rx and Tx not being disabled in cp_suspend [ Upstream commit cb7643b78d35392f0f434774d78b4c77b80f677f ] On QEMU rtl8139 model, frames that arrive while the interface is suspended still end up in the stack after resume. With pm_test=devices, which keeps devices suspended for 5s, 200 frames sent to interface during that time and 50 frames after resume, eth0 reports 113 received frames. cp_suspend() is supposed to stop receiver and the transmitter, but the mask is wrong: (~RxOn | ~TxOn) is ~0, nothing is cleared and Cmd still reads 0x0d when cp_suspend() returns. Use ~(RxOn | TxOn) so both bits are actually cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260817043057.20099-1-kmehltretter@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 94d830835ce7560fbeb3effda799b085547ca244 Author: Xu Rao Date: Tue Aug 18 16:38:08 2026 +0800 ALSA: hda: Fix connection list comparison in proc output [ Upstream commit c139e7e44f58a6f8ddc9d850ea9924d34963b5da ] print_conn_list() compares the raw hardware connection list with the connection list cached by the HDA driver. When they differ, it prints an additional "In-driver Connection" line so that /proc/asound/card*/codec#* shows the topology actually used by the driver. The comparison currently passes conn_len directly to memcmp(). However, conn_len is a number of connection-list entries, while memcmp() expects a size in bytes. Both list and conn are arrays of hda_nid_t, which is u16, so only half of the connection data is compared. For example, for two-entry lists such as: hardware: 0x0c 0x0d cached: 0x0c 0x0e conn_len is 2, and the current comparison checks only the first hda_nid_t. The lists are therefore incorrectly treated as identical even though the second connection differs. This can happen legitimately when codec fixups replace a cached connection list with snd_hda_override_conn_list(). The codec routing used by the driver is not affected, but the proc output can hide the overridden driver-visible routing and provide misleading topology information during codec debugging. Convert the entry count to a byte size so that memcmp() covers the complete connection list. Fixes: 8b2c7a5c404d ("ALSA: hda - Add In-driver connection info") Signed-off-by: Xu Rao Link: https://patch.msgid.link/7B802A4E225CC808+20260818083808.2735120-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 613b6cc2af7accee1a55e34f2987a830545228ab Author: Nikolay Aleksandrov Date: Fri Aug 14 17:16:40 2026 +0300 net: bridge: vlan: fix inverted default vlan notification [ Upstream commit 21040c7f931502070dcc66bb0f1aeed07dec032b ] A notification should be emitted only when the vlan delete was successful and not otherwise. The proper check is if br/nbp_vlan_delete returned 0. Fixes: f545923b4a6b ("net: bridge: vlan: notify on vlan add/delete/change flags") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260814141640.64958-1-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d02de9a7a7e2484da0cf37e50614840623b98a62 Author: Joas Antonio dos Santos Date: Thu Aug 13 15:34:24 2026 -0300 ipvs: fix integer overflow in ftp helper port/address parsing [ Upstream commit e625a9477d12baaff4025c5f9989184a907ea8fc ] ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba ("netfilter: nf_conntrack_ftp: avoid u16 overflows"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Joas Antonio dos Santos Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f18d5960f0a3e4e9537ccab4088d8dd9cc750701 Author: Lukasz Majewski Date: Tue Mar 26 09:56:49 2024 +0100 net: hsr: Use full string description when opening HSR network device [ Upstream commit 10e52ad5ced2a7dcdb3fb18c9cef111d5f30471d ] Up till now only single character ('A' or 'B') was used to provide information of HSR slave network device status. As it is also possible and valid, that Interlink network device may be supported as well, the description must be more verbose. As a result the full string description is now used. Signed-off-by: Lukasz Majewski Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Stable-dep-of: 7f16289b91eb ("net: hsr: free learned nodes on device setup failure") Signed-off-by: Sasha Levin commit 660a7c97023e8bddd2c3e0a8494af12ff1d3540c Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:14 2022 +0100 hsr: Use a single struct for self_node. [ Upstream commit 20d3c1e9b861b85e1a774e1876d6adeeb0251fc3 ] self_node_db is a list_head with one entry of struct hsr_node. The purpose is to hold the two MAC addresses of the node itself. It is convenient to recycle the structure. However having a list_head and fetching always the first entry is not really optimal. Created a new data strucure contaning the two MAC addresses named hsr_self_node. Access that structure like an RCU protected pointer so it can be replaced on the fly without blocking the reader. Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Kurt Kanzenbach Signed-off-by: Jakub Kicinski Stable-dep-of: 7f16289b91eb ("net: hsr: free learned nodes on device setup failure") Signed-off-by: Sasha Levin commit d7d54570fa309f0e9cb50d1df522790e375d7d50 Author: Qingfang Deng Date: Tue Aug 11 11:53:10 2026 +0800 pppox: drain queued packets on channel handoff [ Upstream commit 92c1bf630abf0af646562398eaa36f80b5ff677d ] PPPIOCGCHAN both returns the channel index and marks a PPPOX socket as bound to generic PPP, despite its getter semantic. Packets received before that transition are queued on sk_receive_queue, but a bound socket is no longer readable. Such packets therefore remain queued until the socket is destroyed. After marking a socket bound, wait for receive paths that observed the old state to finish queueing packets, and then drain the queue into generic PPP. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260811035314.302878-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37108861cf7bd909d4a372069bcd61c8f489e232 Author: Junseo Lim Date: Thu Aug 13 12:51:36 2026 +0900 net: kcm: Hold RCU read lock while running BPF parser [ Upstream commit b0346dd64e4905291cc9c479f2e6cf1884ced4e6 ] kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program. Fixes: 9b73896a81dc ("kcm: Use stream parser") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Link: https://patch.msgid.link/20260813035136.106167-1-zirajs7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68c721391b761dbe38d5b0094d2bb6e8489ad92b Author: Ruoyu Wang Date: Wed Jun 24 11:58:58 2026 +0800 NFSv4: remove callback IDR entry on client allocation failure [ Upstream commit d05c2007b3d84ccba11dc6e9cb3202768cc72f14 ] nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection. Fixes: f4eecd5da342 ("NFS implement v4.0 callback_ident") Signed-off-by: Ruoyu Wang Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit af7b8502fc42261217ee47d5858efe4d8d5c11f3 Author: Arnaud Bonnet Date: Mon Jun 22 19:55:11 2026 +0200 nfs: refactor pNFS functions using clear_and_wake_up_bit [ Upstream commit 187bfc974eefa9e5d88a0b4ee9d08ae8fe485df4 ] Commit 8236b0ae31c83 ("bdi: wake up concurrent wb_shutdown() callers.") introduces the clear_and_wake_up_bit() helper as a wrapper for the common clear -> barrier -> wake up bitops sequence. The file pnfs.c has several helpers with identical contents. Thus they are replaced with the more recent clean_and_wake_up_bit() global helper which describes accurately its effects at the call and still specifies the cleared bit. This also homogenizes the code with other subsystems. Since the helpers are no longer used after this, they can be safely removed. Suggested-by: Agatha Isabelle Moreira Link: https://kernelnewbies.org/Beginner%20Cleanup%20and%20Refactor%20Tasks%20by%20Agatha%20Isabelle%20Moreira#task_007 Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Arnaud Bonnet Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 561d34ddbe26c8e82035e6efd681a77881977dec Author: Trond Myklebust Date: Fri Jul 2 17:24:22 2021 -0400 NFSv4/pnfs: Clean up layout get on open [ Upstream commit b4e89bcba2b3a966e043107cb52c682bb860cee7 ] Cache the layout in the arguments so we don't have to keep looking it up from the inode. Signed-off-by: Trond Myklebust Stable-dep-of: 187bfc974eef ("nfs: refactor pNFS functions using clear_and_wake_up_bit") Signed-off-by: Sasha Levin commit 17c3bba7e45bb52dacfcd4497709a61ddb55f5c5 Author: Arnaud Bonnet Date: Mon Jun 22 19:55:10 2026 +0200 nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper [ Upstream commit 61461050da42401b484d03e0fdac02878d235fe6 ] Commit 8236b0ae31c83 ("bdi: wake up concurrent wb_shutdown() callers.") introduces the clear_and_wake_up_bit() helper as a wrapper for the common clear -> barrier -> wake up bitops sequence. Use the helper in nfs_clear_invalid_mapping as inode.c already relies on functions from and to homogenize with other subsystems. Suggested-by: Agatha Isabelle Moreira Link: https://kernelnewbies.org/Beginner%20Cleanup%20and%20Refactor%20Tasks%20by%20Agatha%20Isabelle%20Moreira#task_007 Fixes: d529ef83c355 ("NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping") Signed-off-by: Arnaud Bonnet Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit e4ba6d3113701321fd6338c0930b30f72948a3c6 Author: Trond Myklebust Date: Mon Feb 8 08:55:47 2021 -0500 NFS: Always clear an invalid mapping when attempting a buffered write [ Upstream commit 28aa2f9e73e762dbaa28fdca20cccb59c74cc139 ] If the page cache is invalid, then we can't do read-modify-write, so ensure that we do clear it when we know it is invalid. Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Stable-dep-of: 61461050da42 ("nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper") Signed-off-by: Sasha Levin commit 5b09d984b38b018b123c3a9e02a96bbc6468dbe5 Author: Junseo Lim Date: Tue Aug 11 23:19:07 2026 +0900 bpf: Reject negative optlen in cgroup getsockopt hook [ Upstream commit 1b5aacd5b2419b0790e955e466d389a61c79b4b1 ] A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook. Fixes: 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/187a4d756275aaaee5d65eecb63c1477b3b66554.1786448307.git.zirajs7@gmail.com Signed-off-by: Sasha Levin commit 753e5cdcca5474d230d62bb3489e5168ab27c272 Author: Junseo Lim Date: Tue Aug 11 13:41:49 2026 +0900 lwt_bpf: Restore reserved headroom after xmit program [ Upstream commit 5fe7007aed9ad069b2bd77e5d0c875c64f5c0269 ] ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: Sechang Lim Suggested-by: Daniel Borkmann Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260811044149.118235-1-zirajs7@gmail.com Signed-off-by: Sasha Levin commit 679c2964921590b96987c6b22a943be3f0dc5aef Author: Delphine CC Chiu Date: Thu Nov 2 17:08:07 2023 +0800 hwmon: (emc1403) Add support for EMC1442 [ Upstream commit 9350163aff24530f2aa3357ee1c7bd8771a443e4 ] Add support for EMC1442 which is compatible with EMC1402. Signed-off-by: Delphine CC Chiu Reviewed-by: Patrick Williams Link: https://lore.kernel.org/r/20231102090808.427351-1-Delphine_CC_Chiu@wiwynn.com [groeck: compatible with EMC1402, not EMC1403] Signed-off-by: Guenter Roeck Stable-dep-of: 75f2c0b36907 ("hwmon: (emc1403) Drop hysteresis for low limit temperature") Signed-off-by: Sasha Levin commit e9021f2e287e51523cf59ea210ef04c9564890c7 Author: Linmao Li Date: Tue Jul 28 17:16:22 2026 +0800 mailbox: rockchip: disable pclk on probe failure and unbind [ Upstream commit ded48fcbdc1e3ed1dc8e1974b7fe9639fcea6dd6 ] rockchip_mbox_probe() enables the peripheral clock and then keeps going. None of the later failure paths - platform_get_irq(), devm_request_threaded_irq() and devm_mbox_controller_register() - disables it again. The driver has no remove callback either, so the clock also stays prepared and enabled once the device is unbound, and its enable count keeps growing over bind/unbind cycles. Use devm_clk_get_enabled() to tie disabling and unpreparing the clock to the device lifetime. It is registered before the interrupts and the mailbox controller, so devres releases it after both are gone. While rewriting the error path, switch it to dev_err_probe() so that a deferred probe is not reported as an error. Fixes: f70ed3b5dc8b ("mailbox: rockchip: Add Rockchip mailbox driver") Signed-off-by: Linmao Li Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c62c07b3a20288a58d33adb09da5744c6490b283 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:45 2026 -0300 perf dso: Guard against cache underflow on short reads in dso_cache__memcpy() [ Upstream commit 390a9461cd73bdd13acc0f6d763618ae1ff8fa17 ] dso_cache__memcpy() computes cache_offset = offset - cache->offset, then cache_size = min(cache->size - cache_offset, size). The RB tree lookup in __dso_cache__find() matches using the full DSO__DATA_CACHE_SIZE window, but cache->size reflects the actual pread return value from dso_cache__populate(). A short pread (e.g. near end-of-file) makes cache->size smaller than DSO__DATA_CACHE_SIZE. If a subsequent access targets an offset past cache->offset + cache->size but within the DSO__DATA_CACHE_SIZE window, the cache entry is found but cache_offset exceeds cache->size. Since both are u64, the subtraction cache->size - cache_offset wraps to a large value, min() selects the caller's size, and memcpy reads out of bounds. Return 0 for an offset past the valid cached data. For a regular file a short pread only happens at end-of-file, so 0 is what a direct pread() at that offset would return: cached_io() stops its read loop as on EOF. Re-reading from the backing file would not help — a second pread at the same offset returns the same short count. Fixes: 366df72657e0 ("perf dso: Refactor dso_cache__read()") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0a6d4678dead450afd2755f5ffb2931df68a9500 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:43 2026 -0300 perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path() [ Upstream commit 10f452dc2de401be76ae8e7395c9663313df8b53 ] dso__decompress_kmodule_path() unconditionally calls close(fd) on the return value of decompress_kmodule(). When decompression fails or the DSO is not compressed, decompress_kmodule() returns -1. close(-1) fails with EBADF and clobbers errno, which callers up the chain (dso__get_filename → __open_dso) depend on for error propagation. Guard the close() call with fd >= 0 so only valid file descriptors are closed. Fixes: 42b3fa670825 ("perf tools: Introduce dso__decompress_kmodule_{fd,path}") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 35cac6f430de2e790f02f8cfb9bbc5ec3dc203d0 Author: Israel Téllez García Date: Fri Aug 14 14:48:40 2026 +0200 bpf: Fix pending_pos walk on 32-bit ring position wrap [ Upstream commit 6ff5b56a50c5351aeeb180e34327736576c038fa ] The reservation path caches the position of the oldest not-yet-committed record in rb->pending_pos and advances it past already committed records on every reservation: while (pend_pos < prod_pos) { consumer_pos, producer_pos and pending_pos are unsigned long, i.e. 32-bit on 32-bit architectures, and Documentation/bpf/ringbuf.rst states that these counters may wrap around there. Every other comparison in the file is written as a difference, so modular arithmetic keeps them correct across the wrap. This one is an ordering comparison, and it is not wrap-safe. Once producer_pos wraps past 2^32, prod_pos is small while pend_pos still holds its pre-wrap value, so the loop condition is false and pending_pos is never advanced again. Reservations keep succeeding for a while, because bpf_ringbuf_has_space() uses differences, but new_prod_pos - pend_pos grows as the producer advances, and once it exceeds rb->mask every subsequent __bpf_ringbuf_reserve() call fails: the kernel believes a pending record spans the whole buffer. The ring never recovers, bpf_ringbuf_output() drops every event from then on, and nothing is logged. Observed on four armv7 devices (i.MX7 Dual, 6.6.52) running a tracepoint-based collector with a 512 KiB ring and 160-byte records. Every one of them stopped delivering after exactly 26846821 records and 4295491360 bytes had passed through the ring, at event rates between 441 and 862 records/s, that is after 8 h to 17 h of uptime: the trigger is the byte count, not time or load. That figure is 2^32 plus 524064 bytes, and the excess is one ring's worth of grace period, as expected while new_prod_pos - pend_pos is still below rb->mask. The last reservation that fits is the largest record boundary X with X + 160 <= 524287, and since 2^32 mod 160 = 96 the boundaries after the wrap sit at X = 64 (mod 160), giving X = 524064. Userspace kept consuming normally until the producer stopped, then read zero records for good. With this patch applied, one of the four devices took 10 GiB through the same ring with no stall, while the three unpatched ones kept wedging at the same byte count. 64-bit hosts are unaffected in practice: their counters would need 16 EiB to wrap. Compare the two positions as a difference instead. pending_pos never runs ahead of producer_pos, so the unsigned difference is the real distance between them and stays correct across the wrap. Fixes: cfa1a2329a69 ("bpf: Fix overrunning reservations in ringbuf") Signed-off-by: Israel Téllez García Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814124843.22041-2-i.tellez@btesa.com Signed-off-by: Sasha Levin commit 3361709fb6f6568b157c6f24ed21a4a5d86d73db Author: Chandrakanth Patil Date: Sat Aug 8 20:40:10 2026 +0530 scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers [ Upstream commit b9f679dfe629004b593f018df33b330d799bcee4 ] _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a "bad dma" warning on debug kernels or a NULL pointer dereference otherwise. Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission") Reported-by: Laurence Oberman Signed-off-by: Chandrakanth Patil Link: https://patch.msgid.link/20260808151010.185603-1-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit b169185d5c672b989985c6c2e38cafab2548ba88 Author: Phillip Lougher Date: Fri Aug 7 17:29:51 2026 +0100 Squashfs: check block offset is not negative [ Upstream commit e300eb5002925b29be803d2661af07266cfa267e ] If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset. Link: https://lore.kernel.org/20260807162951.672510-1-phillip@squashfs.org.uk Fixes: f400e12656ab ("Squashfs: cache operations") Signed-off-by: Phillip Lougher Reported-by: Yuejie Shi Closes: https://lore.kernel.org/all/20260803032735.81785-1-syjcnss@gmail.com/ Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4936d4464d1ae10b5fbba64374085a0dcc060560 Author: Krystian Kaniewski Date: Thu Jul 30 07:42:21 2026 +0000 ocfs2: fix circular locking dependency in ocfs2_init_acl() [ Upstream commit bd7c05fb4a4776dff5a87b19008d28458647d15d ] A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary. Link: https://lore.kernel.org/4094de06-9b69-4174-b2ee-08126dffc693@mail.kernel.org Fixes: 16c8d569f570 ("ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute") Signed-off-by: Krystian Kaniewski Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4007ab5229e732466d9f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4007ab5229e732466d9f Link: https://syzkaller.appspot.com/ai_job?id=cc75363d-c672-499e-8fc5-44bcdc1cee39 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit af10ef1dff1581862e0eb41cfc01a137c3cfd167 Author: Yuan Chen Date: Mon Aug 10 22:22:22 2026 +0800 bpftool: Fix double close in map dump [ Upstream commit 259d60f5bfa41056fe01cbf2ba3f6f0331865a16 ] map_dump() closes the map fd in its error path, and do_dump() then closes the same fd again after a successful dump. Closing an already closed fd leaves errno set to EBADF, which poisons later errno checks such as the batch file read check in do_batch(). Let do_dump() own the fd and remove the close from map_dump(). The same double-close pattern exists in do_show_subset(): both show_map_close_json() and show_map_close_plain() already close the fd, so drop the extra close() there as well. Also propagate the error when bpf_map_get_info_by_fd() fails on a subsequent map in do_dump(): set err = -1 before breaking out of the loop, so a later failure is not silently hidden after an earlier iteration succeeded. Fixes: 99f9863a0c45f ("bpftool: Match maps by name") Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260810142224.2907373-2-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit b0f1a62d1d244d8e88ccce6565549e5f9b6033f4 Author: Bijan Tabatabai Date: Thu Jul 16 17:06:04 2026 -0500 x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported [ Upstream commit dee87e09b0dd63da9b1e1876167ccae37842dfd0 ] The man page for pkey_alloc(2) specifies that it should return -1 with the errno set to ENOSPC when pkeys are not supported [1]. However, on x86 pkey_alloc() sets errno to EINVAL when called for the first time on a CPU that does not support pkeys. The root cause of this is the x86 implementation of mm_pkey_alloc() not directly checking if pkeys are supported. It only checks if all the pkeys have been allocated by comparing the allocation map against all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the initialization of the allocation map, leaving it as 0, while all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a pkey available and it returns pkey 0. Then, pkey_alloc() fails with -EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC. Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is left marked as allocated. Change mm_pkey_alloc() to directly check if OSPKE is enabled, and return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The arm64 and powerpc implementations of mm_pkey_alloc() already do this check. [1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html [ dhansen: use arch_pkeys_enabled() to follow arm ] Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Bijan Tabatabai Signed-off-by: Dave Hansen Link: https://patch.msgid.link/20260716220604.26452-1-bijan311@gmail.com Signed-off-by: Sasha Levin commit 28a9ec6fb51aab4c9f50129227b13b9f2a884fb6 Author: Yuho Choi Date: Sun Aug 2 17:35:45 2026 -0400 clocksource/drivers/armada: Unwind timer clock on init failure [ Upstream commit 8b4127f6db40381229f3564d34ac35f36311c201 ] The Armada timer init paths enable their clock before calling the common initialization routine. If that routine returns an error, the clock is left enabled even though the timer was not initialized successfully. Fixes: 12549e27c63c ("clocksource/drivers/time-armada-370-xp: Convert init function to return error") Signed-off-by: Yuho Choi Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260802213545.565913-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit bfba90e920b36ad315acb20f99f232e664dc2108 Author: Guangshuo Li Date: Sun Jul 5 01:54:51 2026 +0800 clocksource/drivers/clps711x: Do not unmap clocksource MMIO [ Upstream commit e998c6300ef4e062a704ee17b5a812c0b595cf42 ] clps711x_clksrc_init() stores the timer base address in the static tcd pointer and registers it as both the clocksource MMIO address and the sched_clock read address. The clocksource init path must therefore keep the mapping alive after clps711x_timer_init() returns. However, the shared unmap_io exit path is also reached after successful clocksource registration, so the MMIO mapping is torn down while the clocksource and sched_clock readers may still access it. Return directly after successful clocksource registration and leave the mapping alive for the registered readers. Keep the unmap_io path for the error paths and for the clockevent init path. Fixes: cd32e596f02f ("clocksource/drivers/clps711x: Fix resource leaks in error paths") Signed-off-by: Guangshuo Li Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260704175451.256364-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 68f25e292fbd878197fafc6adbec65967f6d88bf Author: Yuho Choi Date: Thu Aug 6 23:23:26 2026 -0400 xenbus: Unregister reboot notifier on init failure [ Upstream commit d330fb86a7170f845123ae82d95df440fad9b707 ] xs_init() registers xs_reboot_nb before initializing XenStore communications and starting xenwatch. If either operation fails, the notifier remains registered and a later initialization attempt can hit a duplicate registration. Check the notifier registration result and unregister it on every subsequent failure path. Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") Signed-off-by: Yuho Choi Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260807032326.940377-1-dbgh9129@gmail.com> Signed-off-by: Sasha Levin commit 2310492c53159aabfc7e22826f0d0ef6e4d8dbfa Author: Henrik Grimler Date: Tue Aug 11 13:47:47 2026 +0200 power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address [ Upstream commit 2da28b059e0ddcd2e1956eeae383246207965573 ] bq27z561 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-5-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b24adcb0d3b50a3fe367efeff2d2a2f98d2916d7 Author: Henrik Grimler Date: Tue Aug 11 13:47:46 2026 +0200 power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address [ Upstream commit e9387e9ab5121f330d313afb90430c02200f9782 ] bq28z610 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 707d678a5c7c ("power: supply: bq27xxx_battery: Add the BQ28z610 Battery monitor") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-4-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8a673b7672a359f7a9eb38bc52804d14919fca40 Author: Henrik Grimler Date: Tue Aug 11 13:47:45 2026 +0200 power: supply: bq27xxx: bq27520g4: fix REG_TTES address [ Upstream commit c774a623c821a173c950e1297f8e8c85a89455be ] According to the technical reference manual the StandbyTimeToEmpty (TTES) register is at 0x1a, not 0x1c. At 0x1c StateOfHealth instead resides. Fixes: 8835cae5f2ab ("power: supply: bq27xxx: adds specific support for bq27520-g4 revision.") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-3-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3c68615c74364e970cfd3daac7b72640cd28cf9a Author: Matti Vaittinen Date: Mon Aug 10 13:10:03 2026 +0300 power: supply: bd99954: Drop bad register fields [ Upstream commit 177299384a224377b4152242d875e752e5958c02 ] The bd99954 driver creates regmap fields for all the registers. All the fields for VBUS_UCD_FCTRL_SET (extended command 0x33) are accidentally created for VCC_UCD_FCTRL_SET (extended command 0x2b), causing all reads/writes for the fields to access wrong register. Luckily the fields for VBUS_UCD_FCTRL_SET are unused. Taking a look at the data-sheet all the fields in the VBUS_UCD_FCTRL_SET are marked as: "In normal operation, please don’t set these registers" with not much of additional documentation. As the fields are wrong and because there seems to be no users of the fields - it is better to just drop them. This will also decrease the memory footprint. Drop incorrect VBUS_UCD_FCTRL_SET fields. Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/battery_management/bd99954xxx-e.pdf Signed-off-by: Matti Vaittinen Fixes: 0902f8366491 ("power: supply: Support ROHM bd99954 charger") Tested-by: Kalle Niemi Link: https://patch.msgid.link/758fd430d02286a6f18603a8aecfe443f5ddeb8e.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 37b87b62e07f194899fad92f4f54e094c4511979 Author: Felix Gu Date: Sat Aug 8 01:41:43 2026 +0800 spi: img-spfi: don't disable runtime PM on DMA deferred probe [ Upstream commit 923e41ed59511cffe98357c7d58d0294a1c157ee ] When dma_request_chan() returns -EPROBE_DEFER, the error path jumps to disable_pm and calls pm_runtime_disable() even though pm_runtime_enable() was never called, leaving disable_depth unbalanced and the device permanently PM-disabled. Route the defer path through free_dma to skip pm_runtime_disable(). Fixes: 6bfbf4d0aa0c ("spi: img-spfi: Use dma_request_chan() instead dma_request_slave_channel()") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260808-spfi-v1-1-6bc4345be430@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 935317aa38000c0360bab45354f7b24713932a2a Author: Ran Hongyun Date: Thu Jul 23 10:02:32 2026 +0800 UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC [ Upstream commit ff7937d14f5333ec7e6fb50d00a152d7974f4105 ] Fix two issues introduced before: - The parameter format string was missing the enable_fm and need_resv_pool tokens introduced in an earlier commit. - The bad-block reservation note was misplaced after Example 5 instead of after Example 3. It was misplaced due to an earlier patch. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Ran Hongyun Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 5e1a2d9fff57f3a2b1a0f54d128d64245a253004 Author: Rosen Penev Date: Tue Aug 11 11:51:40 2026 -0700 ASoC: xilinx: formatter_pcm: fix stream_data leak on open error [ Upstream commit b992511180e126150c6ad3580a6fd568c385f4c6 ] In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths. Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Rosen Penev Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260811185140.27149-1-rosenp@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 83c978921688af40dcab6db74882d1ff9b0b765c Author: Yuho Choi Date: Mon Jun 8 00:06:39 2026 -0400 ubi: Fix rollback for explicit UBI device numbers [ Upstream commit 5b0a6b554e12a97f9771a9a9f4ea1f5457373c73 ] ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Yuho Choi Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit deb0b17e271b81ed7c68b0314fe06a989790c629 Author: Zhihao Cheng Date: Mon Aug 28 14:38:44 2023 +0800 ubi: fastmap: Add module parameter to control reserving filling pool PEBs [ Upstream commit d4c48e5b58f12835de779f5425ef741c4d0fb53e ] Adding 6th module parameter in 'mtd=xxx' to control whether or not reserving PEBs for filling pool/wl_pool. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit a6b2188872e785ba4ce5330b47e48ae8d6c768ab Author: Zhihao Cheng Date: Mon Aug 28 14:38:43 2023 +0800 ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs [ Upstream commit 90e0be56144b064be1a816cbdd184d2a8be7061b ] The anchor PEB must be picked from first 64 PEBs, these PEBs could have large erase counter greater than other PEBs especially when free space is nearly running out. The ubi_update_fastmap will be called as long as pool/wl_pool is empty, old anchor PEB is erased when updating fastmap. Given an UBI device with N PEBs, free PEBs is nearly running out and pool will be filled with 1 PEB every time ubi_update_fastmap invoked. So t=N/POOL_SIZE[1]/64 means that in worst case the erase counter of first 64 PEBs is t times greater than other PEBs in theory. After running fsstress for 24h, the erase counter statistics for two UBI devices shown as follow(CONFIG_MTD_UBI_WL_THRESHOLD=128): Device A(1024 PEBs, pool=50, wl_pool=25): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 0 0 0 0 10000 .. 99999: 960 29224 29282 29362 100000 .. inf: 64 117897 117934 117940 --------------------------------------------------------- Total : 1024 29224 34822 117940 Device B(8192 PEBs, pool=256, wl_pool=128): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 8128 2253 2321 2387 10000 .. 99999: 64 35387 35387 35388 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 8192 2253 2579 35388 The key point is reducing fastmap updating frequency by enlarging POOL_SIZE, so let UBI reserve ubi->fm_pool.max_size PEBs during attaching. Then POOL_SIZE will become ubi->fm_pool.max_size/2 even in free space running out case. Given an UBI device with 8192 PEBs(16384\8192\4096 is common large-capacity flash), t=8192/128/64=1. The fastmap updating will happen in either wl_pool or pool is empty, so setting fm_pool_rsv_cnt as ubi->fm_pool.max_size can fill wl_pool in full state. After pool reservation, running fsstress for 24h: Device A(1024 PEBs, pool=50, wl_pool=25): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 0 0 0 0 10000 .. 99999: 1024 33801 33997 34056 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 1024 33801 33997 34056 Device B(8192 PEBs, pool=256, wl_pool=128): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 8192 2205 2397 2460 10000 .. 99999: 0 0 0 0 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 8192 2205 2397 2460 The difference of erase counter between first 64 PEBs and others is under WL_FREE_MAX_DIFF(2*UBI_WL_THRESHOLD=2*128=256). Device A: 34056 - 33801 = 255 Device B: 2460 - 2205 = 255 Next patch will add a switch to control whether UBI needs to reserve PEBs for filling pool. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit 8867ddf3ef9991ad74460156bc1a7d49d8f22d38 Author: Zhihao Cheng Date: Mon Aug 28 14:38:39 2023 +0800 ubi: fastmap: Wait until there are enough free PEBs before filling pools [ Upstream commit a2ea69dac674df0fba59c66146a21145108a85ed ] Wait until there are enough free PEBs before filling pool/wl_pool, sometimes erase_worker is not scheduled in time, which causes two situations: A. There are few PEBs filled in pool, which makes ubi_update_fastmap is frequently called and leads first 64 PEBs are erased more times than other PEBs. So waiting free PEBs before filling pool reduces fastmap updating frequency and prolongs flash service life. B. In situation that space is nearly running out, ubi_refill_pools() cannot make sure pool and wl_pool are filled with free PEBs, caused by the delay of erase_worker. After this patch applied, there must exist free PEBs in pool after one call of ubi_update_fastmap. Besides, this patch is a preparetion for fixing large erase counter in fastmap data block and fixing lapsed wear leveling for first 64 PEBs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit 1dd8e5f6d4986b32b36e78335f7cf6879e9b0ecb Author: Yang Li Date: Wed Feb 15 09:21:17 2023 +0800 ubi: Simplify bool conversion [ Upstream commit ef5031137b90c5338792f7073ba3bf38d14c8cf1 ] ./drivers/mtd/ubi/build.c:1261:33-38: WARNING: conversion to bool not needed here Reported-by: Abaci Robot Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4061 Signed-off-by: Yang Li Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit 0b30b2cda050c868abac387386cbdd6a9dae3ef7 Author: ZhaoLong Wang Date: Tue Oct 25 16:52:49 2022 +0800 ubi: fastmap: Add fastmap control support for module parameter [ Upstream commit 7af73882dd1cea5d32ac0cc9eda263635295de50 ] The UBI driver can use the IOCTL to disable the fastmap after the mainline 669d204469c4 ("ubi: fastmap: Add fastmap control support for 'UBI_IOCATT' ioctl"). To destroy the fastmap on a old image, we need to reattach the device in user space. However, if the UBI driver build in kernel and the UBI volume is the root partition, the UBI device cannot be reattached in user space. To disable fastmap in this case, the UBI must provide the kernel cmdline parameters to disable fastmap during attach. This patch add 'enable_fm' as 5th module init parameter of mtd=xx to control fastmap enable or not. When the value is 0, fastmap will not create and existed fastmap will destroyed for the given ubi device. Default value is 0. To enable or disable fastmap during module loading, fm_autoconvert must be set to non-zero. +-----------------+---------------+---------------------------+ | \ | enable_fm=0 | enable_fm=1 | +-----------------+---------------+---------------------------+ |fm_autoconvert=Y | disable fm | enable fm | +---------------------------------+---------------------------+ |fm_autoconvert=N | disable fm | Enable fastmap if fastmap | | | | exists on the old image | +-------------------------------------------------------------+ Example: # - Attach mtd1 to ubi1, disable fastmap, mtd2 to ubi2, enable fastmap. # modprobe ubi mtd=1,0,0,1,0 mtd=2,0,0,2,1 fm_autoconvert=1 # - If 5th parameter is not specified, the value is 0, fastmap is disable # modprobe ubi mtd=1 fm_autoconvert=1 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216623 Signed-off-by: ZhaoLong Wang Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit 883156dbe5a812798e0532d72fcfbceca1f1e043 Author: Zhihao Cheng Date: Wed Aug 17 11:27:35 2022 +0800 ubi: fastmap: Add fastmap control support for 'UBI_IOCATT' ioctl [ Upstream commit 669d204469c46e91d99da24914130f78277a71d3 ] [1] suggests that fastmap is suitable for large flash devices. Module parameter 'fm_autoconvert' is a coarse grained switch to enable all ubi devices to generate fastmap, which may turn on fastmap even for small flash devices. This patch imports a new field 'disable_fm' in struct 'ubi_attach_req' to support following situations by ioctl 'UBI_IOCATT'. [old functions] A. Disable 'fm_autoconvert': Disbable fastmap for all ubi devices B. Enable 'fm_autoconvert': Enable fastmap for all ubi devices [new function] C. Enable 'fm_autoconvert', set 'disable_fm' for given device: Don't create new fastmap and do full scan (existed fastmap will be destroyed) for the given ubi device. A simple test case in [2]. [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_fastmap [2] https://bugzilla.kernel.org/show_bug.cgi?id=216278 Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 5b0a6b554e12 ("ubi: Fix rollback for explicit UBI device numbers") Signed-off-by: Sasha Levin commit 284a105f57fe0f8fd4aec898f9c0af6eef82b95f Author: Zhihao Cheng Date: Sat Jul 4 16:30:41 2026 +0800 UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs [ Upstream commit be04fce9945aac2a843f5d16725391eb80d948ef ] In ubi_update_fastmap(), when no fresh PEB is available to replace an old fastmap PEB, the old PEB is reused by erasing it synchronously via ubi_sync_erase() with the torture flag hardcoded to zero. However, old_fm->to_be_tortured[] may be non-zero: it is set during fastmap scanning when ubi_io_read_data()/ubi_io_read_ec_hdr() reports UBI_IO_BITFLIPS, meaning the PEB showed signs of bit decay and should be tortured to verify it is still reliable. When the old PEB is instead returned to the WL sub-system via ubi_wl_put_fm_peb(), the to_be_tortured flag is honored. The synchronous reuse path is inconsistent: it silently skips the torture test for PEBs that exhibited bit-flips. Fix it by passing &old_fm->to_be_tortured[i] to ubi_sync_erase(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 7bcc340b75880518bdefc08e8455248c0a7b1534 Author: Zhihao Cheng Date: Sat Jul 4 16:30:40 2026 +0800 UBI: Preserve torture flag when rescheduling failed erasures [ Upstream commit 420477a84f1e52babfe60a43dbdd0988ed956845 ] In __erase_worker(), when ubi_sync_erase() returns -EINTR, -ENOMEM, -EAGAIN, or -EBUSY, the physical eraseblock is rescheduled for erasure via schedule_erase() with the torture flag hardcoded to 0. This unconditionally drops the torture request. If the error occurred before torture_peb() completed (e.g., -ENOMEM from the ec_hdr allocation in ubi_sync_erase(), errors from self_check_not_bad()/nor_erase_prepare() in ubi_io_sync_erase(), or torture_peb() failing mid-test because its internal do_sync_erase()/ ubi_io_read()/ubi_io_write() returned one of the above error codes), the torture test was never finished. Such a PEB may reach the free pool without being tortured, defeating the purpose of the torture test for detecting marginally-bad eraseblocks. If the error occurred after torture_peb() succeeded (the final do_sync_erase() in ubi_io_sync_erase() or ubi_io_write_ec_hdr() in ubi_sync_erase() failed), the torture has already been done and need not be repeated. Pass the torture flag by pointer to ubi_sync_erase() and ubi_io_sync_erase(), and clear it to zero once torture_peb() has completed successfully. __erase_worker() then forwards the updated wl_wrk->torture to schedule_erase(): torture already done is dropped, torture not completed is preserved across the reschedule. Fixes: 784c145444e7 ("UBI: fix error handling in erase worker") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 150e3bc9e52c2e83c5f8e92bc072d61e62c0bb47 Author: Zhihao Cheng Date: Mon Aug 28 14:38:37 2023 +0800 ubi: Replace erase_block() with sync_erase() [ Upstream commit c19286d70aaa361cdb073a68a1f66232c359e2fd ] Since erase_block() has same logic with sync_erase(), just replace it with sync_erase(), also rename 'sync_erase()' to 'ubi_sync_erase()'. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit 621046cdd58d278ac0df7add6deaf6f710cebcc9 Author: Zhihao Cheng Date: Mon Aug 28 14:38:36 2023 +0800 ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap [ Upstream commit a033ab4fec5fd9194d1b6c0306efbdc75f70b142 ] Function ubi_update_fastmap could be called in IO context, for example: ubifs_writepage do_writepage ubifs_jnl_write_data write_head ubifs_wbuf_write_nolock ubifs_leb_write ubi_leb_write ubi_eba_write_leb try_write_vid_and_data ubi_wl_get_peb ubi_update_fastmap erase_block So it's better to allocate memory with GFP_NOFS mode, in case waiting page writeback(dead loop). Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit 2c88a87c1d0d9f15e4660d34ed3bcb401b0932a4 Author: Zhihao Cheng Date: Mon Aug 28 14:38:35 2023 +0800 ubi: fastmap: erase_block: Get erase counter from wl_entry rather than flash [ Upstream commit 08a4267874164b2e9c8c50831acd466f47208acc ] Just like sync_erase() does, getting erase counter from wl_entry is faster than reading from flash. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit a07ffbf0590cd4cab3ffd91f942c5fb361ac2867 Author: Zhihao Cheng Date: Mon Aug 28 14:38:34 2023 +0800 ubi: fastmap: Fix missed ec updating after erasing old fastmap data block [ Upstream commit 4d18b5a57b16c21cf868369ca555068722c32b2d ] After running fsstress on ubifs for a long time, UBI(16384 blocks, fastmap takes 2 blocks) has an erase block with different erase counters displayed from two views: From ubiscan view: PEB 8031 has erase counter 31581 ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 16383 290 315 781 1000 .. 9999: 0 0 0 0 10000 .. 99999: 1 31581 31581 31581 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 16384 290 317 31581 From detailed_erase_block_info view: PEB 8031 has erase counter 7 physical_block_number erase_count 8030 421 8031 7 # mem info is different from disk info 8032 434 8033 425 8034 431 Following process missed updating erase counter in wl_entry(in memory): ubi_update_fastmap for (i = 1; i < new_fm->used_blocks; i++) // update fastmap data if (!tmp_e) if (old_fm && old_fm->e[i]) erase_block(ubi, old_fm->e[i]->pnum) ret = ubi_io_sync_erase(ubi, pnum, 0) ec = be64_to_cpu(ec_hdr->ec) ec += ret ec_hdr->ec = cpu_to_be64(ec) ubi_io_write_ec_hdr(ubi, pnum, ec_hdr) // ec is updated on flash // ec is not updated in old_fm->e[i] (in memory) Fix it by passing wl_enter into erase_block() and updating erase counter in erase_block(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit 9641ea3a30f6fc02928ce0971f2ab1bddaa2e5bf Author: Christophe JAILLET Date: Mon Jul 4 20:46:00 2022 +0200 ubi: fastmap: Use the bitmap API to allocate bitmaps [ Upstream commit e7f35da21f6f8c6a8c7d262dd4e4bd32e3083f79 ] Use bitmap_zalloc()/bitmap_free() instead of hand-writing them. It is less verbose and it improves the semantic. Signed-off-by: Christophe JAILLET Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit 804fc1c6c9f1f06cc739dc62b704bb3b215ade10 Author: Jilin Yuan Date: Wed Aug 10 21:38:56 2022 +0800 ubi: Fix repeated words in comments [ Upstream commit ec1f97f501a746403990515bbefcaecd7562b042 ] Delete the redundant word 'a'. Delete the redundant word 'the'. Signed-off-by: Jilin Yuan Signed-off-by: Richard Weinberger Stable-dep-of: 420477a84f1e ("UBI: Preserve torture flag when rescheduling failed erasures") Signed-off-by: Sasha Levin commit 993484a5d7d8b22b7e2f7191c11d9cdb17cae543 Author: LiangCheng Wang Date: Wed Aug 5 15:55:43 2026 +0800 ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready [ Upstream commit 0286324da660875dc504fd65b3be87e9c8b9a547 ] fsl_asoc_card_probe() hard-fails with -EINVAL when the CPU DAI (SAI) platform device is not found. Like the codec, the CPU DAI may just be probed later than the machine driver; the order is not guaranteed and varies across kernel versions, so a permanent -EINVAL leaves the card unregistered with no analog playback or capture. Defer probe instead, mirroring commit e396dec46c56 ("ASoC: fsl-asoc-card: Defer probe when fail to find codec device"). Tested on i.MX8MP with an ALC5672 on SAI3: the card that failed to register on v6.18 now comes up during boot. Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support") Signed-off-by: LiangCheng Wang Link: https://patch.msgid.link/20260805-fsl-asoc-defer-cpu-dai-v1-1-43f7f538e384@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c8783582c382232314ef80f59eb58f2ba9f951c9 Author: bui duc phuc Date: Tue Aug 11 17:09:49 2026 +0700 ASoC: pxa: Use devm_clk_get_optional() for extclk clock [ Upstream commit 6ec64d757af9b75a3c64f9f7dad76bdc1efc06ca ] The Device Tree binding defines the extclk clock as an optional property, but the driver currently uses devm_clk_get() and manually handles the absence of the clock. Use devm_clk_get_optional() to match the binding and simplify the optional clock handling. This also propagates errors other than the absence of the optional clock, including -EPROBE_DEFER. This changes the existing behavior for errors other than -EPROBE_DEFER. RFC to discuss whether these errors should cause probe to fail rather than being treated as an unavailable optional clock. Fixes: 90eb6b59d311 ("ASoC: pxa-ssp: add support for an external clock in devicetree") Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260811100949.61142-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d7e55ea64dd15769318ba2e0fe0956db82ba3c3 Author: Zhu Yanjun Date: Tue Aug 11 00:01:23 2026 +0200 RDMA/cma: Fix WARNING in res_to_rt [ Upstream commit c6d1ec4fbe56492bb88987d577f04a5fb6955f26 ] syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: " WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 " In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds. Reported-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72eddfbadda3e3928e72 Tested-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Fixes: cb5cd0ea4eb3 ("RDMA/core: Add CM to restrack after successful attachment to a device") Link: https://patch.msgid.link/r/20260810220123.191696-1-yanjun.zhu@linux.dev Signed-off-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 459b59f7ed56511d6529311cb4e5e482ebfcfb8e Author: Fan Wu Date: Thu Aug 6 13:01:28 2026 +0000 RDMA/cxgb4: Free debugfs on registration failure [ Upstream commit fe5c16bb6252dea6025b748257ddc3b2665495b0 ] c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree. Fixes: 49ea0c036ede ("RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove") Link: https://patch.msgid.link/r/20260806130128.465460-2-fanwu01@zju.edu.cn Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit be94299d0a918a6db1cf0f75b1f08780357ea882 Author: Guangshuo Li Date: Sat Aug 8 19:06:42 2026 +0800 dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal [ Upstream commit a50184171235045d96104811414b25cf5338cf86 ] bam_dma_probe() calls pm_runtime_use_autosuspend(), but bam_dma_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before forcing the device into runtime suspend during removal. This issue was found by manual code inspection. Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support") Signed-off-by: Guangshuo Li Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260808110642.2770355-1-lgs201920130244@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2535c6f095f0e7d765beaaa6c69ff00f0ba6ff62 Author: Linmao Li Date: Fri Jul 10 14:12:54 2026 +0800 nfc: digital: Do not dump a NULL response in command completion [ Upstream commit 1c7dd70c0adfa58fd66b5cbd03efb747ad6d8d8d ] digital_wq_cmd_complete() dumps the response data whenever cmd->resp is not an error pointer. However, a driver can legitimately complete a command with no response skb at all. digital_tg_send_psl_res() is the only caller that passes timeout=0, meaning no response is expected once the command has been transmitted. On that path trf7970a completes the command with trf->rx_skb = ERR_PTR(0); which evaluates to NULL. IS_ERR(NULL) is false, so the NULL response passes the !IS_ERR() check and cmd->resp->data and cmd->resp->len are dereferenced whenever the debug print site is enabled. The driver guards its own dump with "trf->rx_skb && !IS_ERR(trf->rx_skb)"; the digital layer is missing the NULL half of that test. Use IS_ERR_OR_NULL() so that NULL responses are skipped as well. The callback on that path, digital_tg_send_psl_res_complete(), never dereferences resp and dev_kfree_skb() accepts NULL, so only the debug dump needs fixing. Fixes: 59ee2361c924 ("NFC Digital: Implement driver commands mechanism") Signed-off-by: Linmao Li Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/20260710061254.80975-1-lilinmao@kylinos.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8710faddef4ad8b2a6bfa985d896e2e1bfb77018 Author: Yinhao Hu Date: Fri Jun 26 00:34:34 2026 -0700 nfc: pn533: hold a reference to the request skb during send_frame [ Upstream commit 47792358a624ea066455ef86b744159928cd7716 ] __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths. Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation") Signed-off-by: Yinhao Hu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260626073434.3977525-1-dddddd@hust.edu.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 88b36d36e12c9ba76decdb580d9c1907c084e587 Author: Doruk Tan Ozturk Date: Tue Jun 9 22:25:43 2026 +0200 nfc: llcp: bound SNL TLV parsing to the skb and add length checks [ Upstream commit f4c7f37f0ab990952539dc68d931d65c3657600a ] nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made "service_name_len = length - 1" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 19cfe5843e86 ("NFC: Initial SNL support") Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260609202543.42282-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 3f075832734005310740d148d1cf1c1e792ebdca Author: Zhenghang Xiao Date: Tue May 26 18:31:21 2026 +0800 nfc: nci: fix double completion race in nci_data_exchange_complete [ Upstream commit 8265a626cc14a48e46e6dc8c47667e72b4232ac2 ] nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 ("nfc: nci: fix circular locking dependency in nci_close_device") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback. Fixes: 4527025d440c ("nfc: nci: fix circular locking dependency in nci_close_device") Signed-off-by: Zhenghang Xiao Link: https://patch.msgid.link/20260526103121.47957-1-kipreyyy@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 56fd158fef20268f48db6cdfe5d722e930134eda Author: Breno Leitao Date: Thu May 21 07:32:10 2026 -0700 nfc: llcp: read llcp_sock->local under the socket lock in getsockopt [ Upstream commit 36812527052c5bfb1ec6c1e292d67a5bf76b750f ] nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use. Fixes: 26fd76cab2e6 ("NFC: llcp: Implement socket options") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260521-fix_llc-v2-2-ab44cc09179c@debian.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 42859562b7cc4313a84a584f338118edb7087066 Author: Breno Leitao Date: Thu May 21 07:32:09 2026 -0700 nfc: llcp: avoid userspace overflow on invalid optlen [ Upstream commit 99985bfa8336fadcc69190ba2dcbd5386af3d661 ] nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare. Fixes: 26fd76cab2e6 ("NFC: llcp: Implement socket options") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260521-fix_llc-v2-1-ab44cc09179c@debian.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 533775af5ad41a1bc6bf35c366d0fb425f3ad1e1 Author: Babanpreet Singh Date: Wed Jul 29 05:35:43 2026 +0000 spi: sprd-adi: Fix probe succeeding without registering the controller [ Upstream commit f092e1c935015ee0a0fea1a0374f4cab7b71953c ] With CONFIG_HWSPINLOCK=n the of_hwspin_lock_get_id() stub returns 0 unconditionally. In sprd_adi_probe() the guard if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) is false for that 0, so it takes the else branch, where the switch has no case for 0 and lands in default: return dev_err_probe(&pdev->dev, ret, "failed to find hwlock id\n"); dev_err_probe() returns its err argument unchanged, so probe logs "failed to find hwlock id" and then returns 0, reporting success. sprd_adi_hw_init(), the restart handler and devm_spi_register_controller() are all skipped: the device binds but no SPI controller is ever registered. The hardware spinlock is optional for this controller and the -ENOENT arm already covers "no hardware spinlock supplied". Treat the stub's 0 the same way and continue without a lock; all four users of sadi->hwlock already test it for NULL. This is not reachable on production kernels. Kconfig has depends on HWSPINLOCK || (COMPILE_TEST && !HWSPINLOCK) so the affected configuration exists only under COMPILE_TEST, where no real hardware is present. Found by smatch: drivers/spi/spi-sprd-adi.c:560 sprd_adi_probe() warn: passing zero to 'dev_err_probe' Fixes: f9adf61e983f ("spi: sprd: adi: Change hwlock to be optional") Assisted-by: Claude:claude-opus-5 Reviewed-by: Baolin Wang Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260729053543.7-1-bbnpreetsingh@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 621acf9c3b6f48910f9d6149fe74c15af6da2ba3 Author: Michael Walle Date: Thu Jul 30 12:52:18 2026 +0200 powerpc/configs: enable CONFIG_RAS to fix EDAC support [ Upstream commit 3921cfc2e8155a767235801be88cbd0e4c73508d ] Before commit e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") EDAC_MM_EDAC selected RAS, after that commit, EDAC depends on RAS, but nobody enables it. Enable it in the config again. Fixes: e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") Signed-off-by: Michael Walle Acked-by: Borislav Petkov (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730105546.3658570-1-mwalle@kernel.org Signed-off-by: Sasha Levin commit 04441b792ec40eb66349b5fab34b6a2090b5b2dd Author: Weiming Shi Date: Sun Jun 7 07:06:46 2026 -0700 SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 [ Upstream commit fd22370226a0d8109045d0831fd5aaadee921693 ] rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder. Fixes: d77385f23830 ("SUNRPC: Fix rpc_sockaddr2uaddr") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reviewed-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit a5c4157394a0f2f1569295e1cdf4fb5f923bb9ac Author: Karl Mehltretter Date: Thu Jul 23 06:10:55 2026 +0200 m68k: Fix backtraces for non-running tasks [ Upstream commit 09f71dbeb287e367beea56d9ac8a3d356ef5e02a ] When no stack pointer is supplied, show_stack() starts at thread.esp0. This is the saved userspace register frame, not where a task was switched out. For kernel threads it points to the zeroed frame created by copy_thread(), so sched_show_task() prints no useful backtrace. Use thread.ksp for non-current tasks. It is saved by switch_to() and is already used by __get_wchan(). For current, start at the current stack frame, as is already done when no task is supplied. Tested on qemu-system-m68k -M virt using SysRq-t. All task dumps contained resolved frames. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Karl Mehltretter Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260723041055.47289-1-kmehltretter@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit be0e9b5c708c8d783d6a9307e92734d518ec5a81 Author: Desnes Nunes Date: Wed Aug 5 07:42:55 2026 +0800 iommu/vt-d: Fix UCTP context table slot when copying root entries [ Upstream commit c6e63fc8e8fcefa5c32145dc0a3c82975b0ce152 ] When translation is already enabled at boot (e.g. kdump), the vt-d driver copies context tables from the previous kernel's root table. In scalable mode, buses that only populate the upper root half (UCTP, devfn >= 0x80) should be written to ctxt_tbls[tbl_idx + 1] through copy_context_table(). However, the current copy path always uses tbl[tbl_idx + 0] in this situa- tion. Since idx wraps to 0 at devfn 0x80 due to a zeroed LCTP, new_ce for LCTP will be NULL and keep pos equals to 0. Thus, UCTP entries will be co- pied into tbl[tbl_idx + 0] instead of tbl[tbl_idx + 1], and written after- wards to root_entry[bus].lo instead of .hi in copy_translation_tables(). In short, devices on bus 0x80 with devfn >= 0x80 fail DMA with fault 0x39, which will break drivers running in kernels with translation pre-enabled. This fixes NO_PASID DMAR faults for UCTP-only buses such as: DMAR: [DMA Read NO_PASID] Request device [80:14.0] fault addr 0xe81759000 [fault reason 0x39] SM: Present bit in Root Entry is clear For instance, this fault yielded to locking issues between systemd and xHCI, blocking a system's reboot after a vmcore was captured with kdump: systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 is taking a long time dracut-initqueue[277]: Timed out while waiting for udev queue to empty. systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 killed systemd-udevd[246]: usb3: Worker [255] terminated by signal 9 (KILL). ... kdump[569]: saving vmcore complete ... systemd-shutdown[1]: Rebooting. INFO: task kworker/0:1:11 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00080000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_timeout+0xbd/0x100 __wait_for_common+0x97/0x1b0 ? __pfx_schedule_timeout+0x10/0x10 xhci_alloc_dev+0x9e/0x2b0 usb_alloc_dev+0x7a/0x3b0 hub_port_connect+0x285/0x960 hub_port_connect_change+0x94/0x290 port_event+0x4bb/0x840 hub_event+0x141/0x460 process_one_work+0x196/0x390 worker_thread+0x1af/0x320 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task systemd-shutdow:1 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:systemd-shutdow state:D stack:0 pid:1 tgid:1 ppid:0 task_flags:0x400100 flags:0x00080000 Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x547/0xac0 device_shutdown+0xac/0x1b0 kernel_restart+0x3a/0x70 __do_sys_reboot+0x147/0x240 do_syscall_64+0x11b/0x6a0 ? handle_mm_fault+0x110/0x350 ? do_user_addr_fault+0x206/0x680 ? irqentry_exit+0x7a/0x4d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fe2958da917 RSP: 002b:00007ffc5c458618 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe2958da917 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007ffc5c458790 R08: 0000000000000069 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffc5c4588b8 R15: 0000000000000000 INFO: task systemd-shutdow:1 is blocked on a mutex likely owned by task kworker/0:1:11. Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel") Signed-off-by: Desnes Nunes Tested-by: Tao Liu Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d8c1a9579cbd8f4ac5cbd5a10f1afb5ee64adf30 Author: Danila Chernetsov Date: Fri Jul 24 00:42:45 2026 +0000 fbdev: kyro: Validate overlay viewport coordinates [ Upstream commit 7b5c7bc55e13e7f5ac7b1eaf5c6d690389ea5ee3 ] The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Danila Chernetsov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 99bc325d3c8b502778e89be97bb09583e605fcdc Author: Ian Rogers Date: Sun Aug 9 00:14:54 2026 -0700 perf synthetic-events: Fix divide by zero in perf_event__synthesize_threads [ Upstream commit 16a12a54e9a1151a37aab74914a51b86f7f58d0e ] If scandir() finds no matching tasks in /proc, n is 0. If thread_nr is > 1, we bypass the single-thread fast path and then clamp thread_nr to n, making it 0. This results in a divide by zero when calculating num_per_thread. Handle n <= 1 early to use the single-thread fast path and prevent the crash. Fixes: 340b47f510bb ("perf top: Implement multithreading for perf_event__synthesize_threads") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a81d088955da2bd5c0152efb6bc3c52286fedf78 Author: Ian Rogers Date: Sun Aug 9 00:14:44 2026 -0700 perf synthetic-events: Fix uninitialized pthread_join [ Upstream commit 54ba44db4dddc4ca06b49bae0f9d6c5861430b18 ] In perf_event__synthesize_threads(), fix an uninitialized pthread_join() call when thread creation fails by only joining the successfully created threads. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 340b47f510bb ("perf top: Implement multithreading for perf_event__synthesize_threads") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3ea8b17a81f062fb051464bedf07ed1f2d1360b2 Author: Ian Rogers Date: Sun Aug 9 00:14:41 2026 -0700 perf stat: Fix evsel_list leak in cmd_stat [ Upstream commit 340641a4b5fff4f4b12261c9d92169f6e2ea11f4 ] Fix a memory leak in cmd_stat() where evsel_list is leaked if an error occurs while opening the output file. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 361c99a661a7 ("perf evsel: Introduce perf_evlist") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3ce214001fb6fbd136dd4209ef9a21247b9e53d4 Author: Namhyung Kim Date: Mon Nov 14 15:02:09 2022 -0800 perf stat: Clear screen only if output file is a tty [ Upstream commit 81a02c6577ecfee7056ccafbd028984d0d670c0c ] The --interval-clear option makes perf stat to clear the terminal at each interval. But it doesn't need to clear the screen when it saves to a file. Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Cc: Xing Zhengjun Link: https://lore.kernel.org/r/20221107213314.3239159-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo to a file. Make it fail when it's enabled with the output options. $ perf stat -I 1 --interval-clear -o myfile true --interval-clear does not work with output Usage: perf stat [] [] -o, --output output file name --log-fd log output to fd, instead of stderr --interval-clear clear screen in between new interval Stable-dep-of: 340641a4b5ff ("perf stat: Fix evsel_list leak in cmd_stat") Signed-off-by: Sasha Levin commit af39b8083d8d2365ecc462d469e8e054e4f1406d Author: Rosen Penev Date: Wed Jul 8 17:50:05 2026 -0700 ARM: dts: helios4: add SATA regulator supplies [ Upstream commit 7a90520e8c9a8f48fe6f3e741cf34d8c2b6dbc61 ] The ahci-mvebu driver and libahci_platform request three supplies on SATA controller and port nodes: - ahci-supply (controller power) - phy-supply (PHY power) - target-supply (disk power per port) Without them the regulator core prints notices at boot, e.g.: supply ahci not found, using dummy regulator supply phy not found, using dummy regulator supply target not found, using dummy regulator The SATA controller and PHY inside the Armada 388 SoC are powered by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD rail. Wire the existing fixed regulators accordingly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 3206b509efd9cc5e94695dbc6b6e0f7a9291b9dd Author: Rosen Penev Date: Wed Jul 8 17:50:04 2026 -0700 ARM: dts: helios4: add vcc-supply to GPIO expander [ Upstream commit c23988f84496e937dd255564cb30bec67608dcc6 ] The pca953x driver requests a 'vcc' supply, producing: pca953x 0-0020: supply vcc not found, using dummy regulator The PCA9655 (PCA9555-compatible) expander is powered by the same always-on 3.3V rail as the other I2C devices on the bus. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 2ff79256f5142c5ffdab59f2ff527af14501e321 Author: Rosen Penev Date: Wed Jul 8 17:50:03 2026 -0700 ARM: dts: helios4: add vcc-supply to EEPROM [ Upstream commit ef65cf08bd1aa723de2854d02fb8eb8cca273c90 ] The at24 driver requests a 'vcc' supply for the EEPROM, producing 'supply vcc not found, using dummy regulator' at boot when the property is missing. The EEPROM sits on the Helios 4 and is powered by the same always-on 3.3V rail used by other on-board I2C devices. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 5db3b8b70fef21b7653b5a442dd5af3af7304708 Author: Tomáš Macholda Date: Tue Jul 7 23:08:29 2026 +0200 arm64: dts: turris-mox: fix usb3 phys [ Upstream commit 0c2a8eed95160e41b367a1fa605a2c1b24a9639a ] After commit 00e6d608fe80b0f6 ("arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node") swapped USB3 PHY order, USB initialization breaks on Turris MOX. This regression was exposed by commit 91ddf6f722084383 ("phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access") which made USB2 devices not work at all. Fix the issue by explicitly adding all USB3 PHYs and PHY names to Turris MOX device-tree. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Tomáš Macholda Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 04aa895e280e20e508cd3df147e54594064c6f20 Author: Nikhil Gautam Date: Wed Jul 22 21:52:46 2026 +0530 iio: light: gp2ap002: re-enable irq if runtime suspend fails [ Upstream commit 5d89e7cbac40057f5241a0832a86ce0fe97e4818 ] gp2ap002_runtime_suspend() disables the irq before writing OPMOD. If the write fails, the callback returns an error with the irq still disabled while the PM core marks the device active again. re-enable the irq before returning the error so the irq state matches the active state the PM core restores. Fixes: 97d642e23037c ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Nikhil Gautam Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b2d7a97d75b648a643f60d77f4d6d70161268855 Author: Nikhil Gautam Date: Wed Jul 22 21:52:45 2026 +0530 iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes [ Upstream commit 579c049b4cb6fc72ce2c505fc5334540be0efcd3 ] The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a "Runtime PM usage count underflow" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled. Fixes: 97d642e23037c ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Nikhil Gautam Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit dce783a10e70f013410f5b583a29fc3286899629 Author: Ali Ahmet Memis Date: Fri Aug 7 01:25:54 2026 +0000 Bluetooth: MSFT: validate evt_prefix_len against the response length [ Upstream commit 0079e1a944634ab2dc1c7cdec1144486d096407e ] read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset. Fixes: 145373cb1b1f ("Bluetooth: Add framework for Microsoft vendor extension") Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4a31f497e45742a40c168e914210fbdcdd75fe04 Author: Tanushree Shah Date: Sun Jul 26 00:19:50 2026 +0530 perf trace-event: Fix integer truncation in do_read() and skip() [ Upstream commit c108c1391be0826920991d24532fbae8f6373ddc ] The do_read() and skip() functions use 'int' for size parameters, truncating 64-bit sizes from callers. This causes two issues: 1. Uninitialized memory dump: do_read() reads fewer bytes than allocated, leaving uninitialized heap memory that gets written to output files. 2. Out-of-bounds read: Parsing functions process the full 64-bit size while only partial data was read into the buffer. Change do_read(), __do_read(), and skip() to use size_t for size parameters and ssize_t for return values (where applicable), matching read()/write() system calls. Update callers to use ssize_t for storing return values. Fixes: 4a31e56599d4 ("perf tools: Get rid of read_or_die() in trace-event-read.c") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5ae18278e0b3a7d66fe8c964141136f8044af9f5 Author: Zijun Hu Date: Thu Jun 25 22:19:47 2026 -0700 Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855() [ Upstream commit d0b15d812688d3f0f3fe1c4426e12814d0c294dc ] btusb_set_bdaddr_wcn6855() sends the address without swapping byte order for VSC 0xFC14, but the command expects the address in reversed byte order compared to other HCI commands like HCI_Create_Connection, resulting in a wrong BD_ADDR being set. btmon log on WCN6855 shows VSC 0xFC14 is sent with swapped bytes 11 22 33 44 55 66, and Read BD ADDR returns the expected address 11:22:33:44:55:66: < HCI Command: Vendor (0x3f|0x0014) plen 6 #3 [hci0] 11 22 33 44 55 66 > HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] Vendor (0x3f|0x0014) ncmd 1 Status: Success (0x00) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 #11 [hci0] > HCI Event: Command Complete (0x0e) plen 10 #12 [hci0] Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: 11:22:33:44:55:66 (OUI 11-22-33) Fix by swapping the input address before issuing the command. Fixes: b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 71c1e78532c3b53bd2d2649a4940c2b96e7555a4 Author: Ricardo Neri Date: Mon Jul 20 19:43:19 2026 -0700 sched/fair: Check CPU capacity before comparing group types during load balance [ Upstream commit 50b101f6e586b4417d060a976fd831cd87e86e2b ] update_sd_pick_busiest() may incorrectly select a fully_busy group as the busiest group when its per-CPU capacity exceeds that of the destination CPU. This happens because the type of busiest group is initialized to group_has_spare and allows the fully_busy group to win the type comparison. update_sd_pick_busiest() should not choose a candidate scheduling group with at most one runnable task if its per-CPU capacity is greater than that of the destination CPU. Such a check already exists, but it is done too late: after the type comparison, preventing a subsequent fully_busy group of equal per-CPU capacity from being correctly selected. Move this check to occur before comparing group types. Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()") Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Christian Loehle Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Link: https://patch.msgid.link/20260720-rneri-fix-cas-clusters-v6-3-bb500bf4afd4@linux.intel.com Signed-off-by: Sasha Levin commit 6a87d209447b0ac1f2ed6c7b196419a41b063509 Author: Valentin Schneider Date: Wed Apr 7 23:06:28 2021 +0100 sched/fair: Introduce a CPU capacity comparison helper [ Upstream commit 4aed8aa41524a1fc6439171881c2bb7ace197528 ] During load-balance, groups classified as group_misfit_task are filtered out if they do not pass group_smaller_max_cpu_capacity(, ); which itself employs fits_capacity() to compare the sgc->max_capacity of both groups. Due to the underlying margin, fits_capacity(X, 1024) will return false for any X > 819. Tough luck, the capacity_orig's on e.g. the Pixel 4 are {261, 871, 1024}. If a CPU-bound task ends up on one of those "medium" CPUs, misfit migration will never intentionally upmigrate it to a CPU of higher capacity due to the aforementioned margin. One may argue the 20% margin of fits_capacity() is excessive in the advent of counter-enhanced load tracking (APERF/MPERF, AMUs), but one point here is that fits_capacity() is meant to compare a utilization value to a capacity value, whereas here it is being used to compare two capacity values. As CPU capacity and task utilization have different dynamics, a sensible approach here would be to add a new helper dedicated to comparing CPU capacities. Also note that comparing capacity extrema of local and source sched_group's doesn't make much sense when at the day of the day the imbalance will be pulled by a known env->dst_cpu, whose capacity can be anywhere within the local group's capacity extrema. While at it, replace group_smaller_{min, max}_cpu_capacity() with comparisons of the source group's min/max capacity and the destination CPU's capacity. Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Reviewed-by: Qais Yousef Reviewed-by: Vincent Guittot Tested-by: Lingutla Chandrasekhar Link: https://lkml.kernel.org/r/20210407220628.3798191-4-valentin.schneider@arm.com Stable-dep-of: 50b101f6e586 ("sched/fair: Check CPU capacity before comparing group types during load balance") Signed-off-by: Sasha Levin commit 7248b8fba4fb99344bd3d0d11e825dcece12641a Author: Kamal Wadhwa Date: Sat Aug 1 13:30:28 2026 +0530 regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling [ Upstream commit abd14bebb87e0fa2749371272c8b31d6ee5f0a36 ] Currently, when `rpmh_regulator_set_mode_bypass()` helper function is called to set bypass mode, it sends PMIC4's BOB bypass mode value for even if its a PMIC5 BOB. To fix this, introduce new hw_data parameter`pmic_bypass_mode` to store bypass mode value. Use it to send correct PMIC bypass mode value that corresponds to PMIC4/5 BOB regulators from the helper function. Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c5c08c94dd64c05679970d4eed8b06d36a889a8 Author: Loic Poulain Date: Wed Jul 22 15:45:18 2026 +0200 phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend [ Upstream commit c271a6926ea7d3c9566b033d63fd4e8c488dc860 ] Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup. Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-5-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f2d6cea221d777fab3ba18f805ba4c17c90e0b8b Author: Yichong Chen Date: Mon Jul 20 10:18:59 2026 +0800 hugetlbfs: release subpool on fill_super failure [ Upstream commit 308ab73e97c87bd0e142b11758faab7f88d82854 ] hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path. Link: https://lore.kernel.org/20260720021900.1376309-1-chenyichong@uniontech.com Fixes: 7ca02d0ae586 ("hugetlbfs: accept subpool min_size mount option and setup accordingly") Signed-off-by: Yichong Chen Cc: David Hildenbrand Cc: Muchun Song Cc: Oscar Salvador Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b9764db5e69d4721bc9376c1738d679586d6fa12 Author: Simon Glass Date: Mon Aug 3 08:10:23 2026 -0600 pinctrl: rockchip: Reset the pin count when recalculating SoC data [ Upstream commit 5b695c191cc85f0fd62eec885b55d01468dc9f2c ] rockchip_pinctrl_get_soc_data() mutates the static per-SoC data. The iomux and drive offsets are recalculated idempotently, since a rerun anchors at the values calculated before, but the total pin count only accumulates: each run adds every bank's pins again. When the probe is deferred and runs a second time, nr_pins doubles and every bank's pin_base shifts, so later pin lookups resolve to the wrong bank and the wrong registers. Reset the pin count at the start of the calculation, so that a rerun produces the same values. This is verified on a Luckfox Pico Mini B (RV1103, with the pending RV1106 series applied) by forcing the probe to defer once: without this patch the second probe calculates nr_pins=304 instead of 152 and no GPIO bank comes up; with it the recalculation matches the first run and all banks work. Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs") Link: https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=4 Assisted-by: Claude:claude-opus-5 Signed-off-by: Simon Glass Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c8b97c5130f27b64fa2cfe1aa4bebb13f724c6c7 Author: Mukesh Ojha Date: Thu Jul 16 13:46:01 2026 +0530 firmware_loader: do not queue completed sysfs fallback requests [ Upstream commit b48373c901951fad1a26bd7c33ad91172b3945b5 ] fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests. Fixes: 75d95e2e39b2 ("firmware_loader: fix use-after-free in firmware_fallback_sysfs") Signed-off-by: Mukesh Ojha Link: https://patch.msgid.link/20260716081601.1674470-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 2bd3a4d3192c222a8dca3bac5799dd940ae58970 Author: Russ Weight Date: Thu Apr 21 14:21:58 2022 -0700 firmware_loader: Check fw_state_is_done in loading_store [ Upstream commit 736da0b657f615db7e29606eb8818871534a8943 ] Rename fw_sysfs_done() and fw_sysfs_loading() to fw_state_is_done() and fw_state_is_loading() respectively, and place them along side companion functions in drivers/base/firmware_loader/firmware.h. Use the fw_state_is_done() function to exit early from firmware_loading_store() if the state is already "done". This is being done in preparation for supporting persistent sysfs nodes to allow userspace to upload firmware to a device, potentially reusing the sysfs loading and data files multiple times. Reviewed-by: Luis Chamberlain Reviewed-by: Tianfei zhang Tested-by: Matthew Gerlach Signed-off-by: Russ Weight Link: https://lore.kernel.org/r/20220421212204.36052-3-russell.h.weight@intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: b48373c90195 ("firmware_loader: do not queue completed sysfs fallback requests") Signed-off-by: Sasha Levin commit ea79c01ef23c2ec3ace8a98ada517d56763814c2 Author: Manish Rangankar Date: Thu Jul 23 10:33:23 2026 +0530 scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path [ Upstream commit 5cbc49d5c4cd20c18041e86958103045216d2190 ] qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call. Fixes: 5fa8774c7f38 ("scsi: qla2xxx: Add 28xx flash primary/secondary status/image mechanism") Signed-off-by: Manish Rangankar Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit f37211b9c01433f0bbb4709d25df7a0257cf915b Author: Timur Kristóf Date: Mon Aug 3 15:23:02 2026 +0200 drm/amdgpu/gfx6: Use PFP on the compute queues too [ Upstream commit 60f20946cd318518ddc2c0da12103c666b2b9564 ] On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8c9b5c736b8805726d06e9d9fb18d0d802d82635 Author: Timur Kristóf Date: Mon Aug 3 15:23:01 2026 +0200 drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets [ Upstream commit 7aac4242a11991d530eee3e141d6e445d5f11c22 ] Implement the emit_switch_buffer() function instead of emitting them duing emit_ib, emit_pipeline_sync and emit_vm_flush. Note that it isn't necessary to emit these in both emit_pipeline_sync() and emit_vm_flush() because amdgpu_vm_flush() already calls these when calling either of those functions. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 33d46a96add8a1689f8279330bc1fa543f65ba1f Author: Tanushree Shah Date: Sun Jul 26 00:19:49 2026 +0530 perf trace-event: Fix buffer overflow in read_string() [ Upstream commit 1121a7af1833f8b5723f1e32685b461614353d5d ] read_string() writes into buf[BUFSIZ] one byte at a time without checking 'size' against the buffer bound before each write. A string longer than BUFSIZ in the input overflows the stack buffer. Add a bounds check before each write to prevent overflow. On overflow the function returns NULL, matching its other error paths. Fixes: 9215545e99d8 ("perf: Convert perf tracing data into a tracing_data event") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3cbfeee7e60a4397bda0ad22f21b3fb661f61b3a Author: Timur Kristóf Date: Mon Aug 3 15:23:00 2026 +0200 drm/amdgpu/gfx6: Fixup emit_cntxcntl() [ Upstream commit 1edb323406aaf05739804d2faa2561f2d43bcd09 ] Set bits on dword 2 like GFX7-8 except load_global_uconfig which doesn't exist on GFX6. Emit VS_PARTIAL_FLUSH before VGT_FLUSH like GFX7-8. For reference see old PAL which explains the bit fields in this register and that load_global_uconfig doesn't exist on GFX6 and also see gfx_v7_ring_emit_cntxcntl() for the GFX7 code which this commit follows. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3f8249591ef595bfd50bacc651e270a2980d22d8 Author: Pengpeng Hou Date: Mon Jul 20 19:54:23 2026 +0800 mfd: iqs62x: Reject zero-length firmware records [ Upstream commit 08ea045e0b82cbcadb7a2efc43a23561489a00f2 ] struct iqs62x_fw_rec includes the first data byte in its fixed-size header, so the parser advances by len - 1 bytes after that header. A zero len makes the size_t cursor update move back by one byte, so the next record overlaps the current record instead of following a valid declared extent. Reject zero-length records and express the remaining-size check without an offset addition. Fixes: 4d9cf7df8d35 ("mfd: Add support for Azoteq IQS620A/621/622/624/625") Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/all/20260706091034.75865-1-pengpeng@iscas.ac.cn/ Link: https://patch.msgid.link/20260720115423.94994-1-pengpeng@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d2a644e493c5495919d113bcd2fe9a5cdc4d6c06 Author: Pengpeng Hou Date: Mon Jul 20 19:55:23 2026 +0800 mfd: rave-sp: validate received frame payload lengths [ Upstream commit 0be718b5451bd83865d6e2a8d750ca7886c4772a ] A received RAVE-SP frame contains protocol data followed by a variant-specific one- or two-byte checksum. rave_sp_receive_frame() derives a checksum pointer before proving that the frame contains the checksum, then passes the checksum-inclusive length to handlers that index the command, acknowledgment ID and event-data bytes or derive a reply payload length. Name those protocol field offsets, prove the checksum extent before deriving the protocol-data length, pass only that data length to the handlers, and require the complete event or reply prefix before consuming it. Fixes: 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/all/20260706092337.78754-1-pengpeng@iscas.ac.cn/ Link: https://patch.msgid.link/20260720115523.99956-1-pengpeng@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f5693dfaf28d66e7e880feafd1778d3715869efc Author: Vladimir Murzin Date: Mon Jul 27 17:34:12 2026 +0100 arm64: hibernate: Restore DAIF state on error [ Upstream commit 541549827889d0380fd73f8aacb5de6ef7a5a1ac ] Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path. Fixes: ee11f332af96 ("arm64: mte: Save tags when hibernating") Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c9c671e9ab87b639720db8f7f8648bdf0f3bc8ec Author: Ada Couprie Diaz Date: Mon Jul 27 17:34:11 2026 +0100 arm64: hibernate: mask DAIF before restoring hibernated kernel [ Upstream commit 684bde100117931f4c51c644a95f42f2dab041bc ] The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume. Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk") Signed-off-by: Ada Couprie Diaz Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d57db36e74cca4763e1c2c0c6eb9f84d19813879 Author: Shuangpeng Bai Date: Sat Aug 1 17:36:32 2026 -0400 RDMA/siw: Fix use-after-free in siw_accept() [ Upstream commit a9394971825933074032794a5feee5211509c774 ] siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint. Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260801213632.1086548-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a835d1054059909e771f1c9620396bf971edb102 Author: Guoqing Jiang Date: Mon Nov 13 19:57:20 2023 +0800 RDMA/siw: Introduce siw_free_cm_id [ Upstream commit 08456d4db73bbb3fcaa0d63252ea2399c65297a4 ] Factor out a helper to simplify code. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202310091656.JlrmcNXB-lkp@intel.com/ Acked-by: Bernard Metzler Signed-off-by: Guoqing Jiang Link: https://lore.kernel.org/r/20231113115726.12762-12-guoqing.jiang@linux.dev Signed-off-by: Leon Romanovsky Stable-dep-of: a93949718259 ("RDMA/siw: Fix use-after-free in siw_accept()") Signed-off-by: Sasha Levin commit 962edb9a6b0dae09d33a677485a398fc7d55968c Author: Yehyeong Lee Date: Fri Jul 31 13:12:12 2026 +0900 IB/isert: post the full-feature receive buffers after session registration [ Upstream commit 5247dde9daac7e107853b6fea043f7f47be033f7 ] isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260731041212.1733364-2-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e148dbac43308d9e4313070bfc5b355d03134809 Author: Yehyeong Lee Date: Fri Jul 31 13:12:11 2026 +0900 IB/isert: delay the final Login Response until the session is registered [ Upstream commit 464f5afa92d071a226f88424803b0fcf88093ede ] isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260731041212.1733364-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 263a35331169390f7f9ccb51d74e668610199af4 Author: Karl Mehltretter Date: Thu Aug 6 07:02:39 2026 +0200 cpufreq: imx6q: fix out-of-bounds write when probed more than once [ Upstream commit 8c3afcf27fa4582c1ab912503dc8a4ebb8dc0f82 ] imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 493c4d5982f037f288509a1cee352b8b9705fb38 Author: Karl Mehltretter Date: Thu Aug 6 07:09:02 2026 +0200 cpufreq: imx6q: fix devres accumulation across driver rebind [ Upstream commit 22c23c72c3b21fa3ec3db5070dfc0582794e0ef9 ] imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 843b56f09bd0001bc86d98d7575908eb479ba4af Author: Jernej Skrabec Date: Mon Aug 3 18:10:50 2026 +0200 drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz [ Upstream commit 0ba6deddaae74f0539c0303bfb5f860adbe1a68b ] The 8-bit entry of the last MPLL row (594 MHz) doesn't lock reliably on H6. 4K@60 RGB/YUV444, which is the mode that reaches this entry, doesn't come up. Align the value with the vendor driver. Other entries are left alone, they are used by lower pixel clocks which work fine. Tested with 4K@60 on a LG TV. Fixes: 0fb4b858b102 ("drm/sun4i: Add support for H6 HDMI PHY") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/aec9060209473b8176eb43bc7c63c20b21306adf.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit a5a7fe07a78540e9cd02b7ea86348890bd0778a4 Author: Jernej Skrabec Date: Mon Aug 3 18:10:48 2026 +0200 drm/sun4i: dw-hdmi: Drop TCON TOP port reference [ Upstream commit d2a242e5688a17b79c89cd966cd31820c5096d80 ] When the HDMI controller is fed by TCON TOP, the port node used to enumerate the possible CRTCs is never released. Fixes: 57e23de02f48 ("drm/sun4i: DW HDMI: Expand algorithm for possible crtcs") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/43ffcc17f7c3f94c1d7bd1ee89134c766e84df35.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 8b40cb306a0684f510de725e40222c15cfb1a767 Author: Jernej Skrabec Date: Mon Aug 3 18:10:47 2026 +0200 drm/sun4i: tcon: Drop remote endpoint reference [ Upstream commit 3f77e4072630e2301efdbe521e7fca10311043ec ] sun4i_tcon_of_get_id_from_port() never drops the reference taken by of_graph_get_remote_endpoint(). The function is not only called during bind, but also on every mode set through sun8i_r40_tcon_tv_set_mux(), so the leak accumulates. Fixes: e8d5bbf7f4c4 ("drm/sun4i: tcon: get TCON ID and matching engine with remote endpoint ID") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/3f5ec952ad80cb51efebf2fe230df50259041a23.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit aaf812960fb5ade24be7a1d8fea27a1ffc458c30 Author: Jernej Skrabec Date: Mon Aug 3 18:10:46 2026 +0200 drm/sun4i: crtc: Propagate layer initialization error [ Upstream commit 7061ff05ed4a3cf16e83f7e3ad09cbd212508a32 ] sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead. Fixes: dcd215801b02 ("drm/sun4i: Drop primary layer pointer from sun4i_drv") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/b26a0d427d9dfae9c82e3ca90a67d24d8ece5a28.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 31b54c92a49a2b40fcd59b0c8cf346b0b3fb288b Author: Jernej Skrabec Date: Mon Aug 3 18:10:44 2026 +0200 drm/sun4i: tcon: Drop TCON TOP device reference [ Upstream commit 8208832a38ff3d2560eb8a77a9d7a2f17d8ebcdc ] of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds. Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/871a3108086c15a483eef23301984c8d2254dfa7.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 9fac4da30b498ce8e3fd4a598bec282564cefbfa Author: Geert Uytterhoeven Date: Thu Nov 6 14:34:01 2025 +0100 bitfield: Add non-constant field_{prep,get}() helpers [ Upstream commit c1c6ab80b25c8db1e2ef5ae3ac8075d2c242ae13 ] The existing FIELD_{GET,PREP}() macros are limited to compile-time constants. However, it is very common to prepare or extract bitfield elements where the bitfield mask is not a compile-time constant. To avoid this limitation, the AT91 clock driver and several other drivers already have their own non-const field_{prep,get}() macros. Make them available for general use by adding them to , and improve them slightly: 1. Avoid evaluating macro parameters more than once, 2. Replace "ffs() - 1" by "__ffs()", 3. Support 64-bit use on 32-bit architectures, 4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is actually constant. This is deliberately not merged into the existing FIELD_{GET,PREP}() macros, as people expressed the desire to keep stricter variants for increased safety, or for performance critical paths. Yury: use __mask withing new macros. Signed-off-by: Geert Uytterhoeven Acked-by: Alexandre Belloni Acked-by: Jonathan Cameron Acked-by: Crt Mori Acked-by: Nuno Sá Acked-by: Richard Genoud Reviewed-by: Andy Shevchenko Reviewed-by: Yury Norov (NVIDIA) Signed-off-by: Yury Norov (NVIDIA) Stable-dep-of: 62bac3202042 ("drm/sun4i: tcon-top: Keep mixer routes distinct") Signed-off-by: Sasha Levin commit 52428ba21983aacb0315a0e2995dffc1f2dff0f9 Author: Geert Uytterhoeven Date: Thu Nov 6 14:34:00 2025 +0100 bitfield: Add less-checking __FIELD_{GET,PREP}() [ Upstream commit 2a6c045640c38a407a39cd40c3c4d8dd2fd89aa8 ] The BUILD_BUG_ON_MSG() check against "~0ull" works only with "unsigned (long) long" _mask types. For constant masks, that condition is usually met, as GENMASK() yields an UL value. The few places where the constant mask is stored in an intermediate variable were fixed by changing the variable type to u64 (see e.g. [1] and [2]). However, for non-constant masks, smaller unsigned types should be valid, too, but currently lead to "result of comparison of constant 18446744073709551615 with expression of type ... is always false"-warnings with clang and W=1. Hence refactor the __BF_FIELD_CHECK() helper, and factor out __FIELD_{GET,PREP}(). The later lack the single problematic check, but are otherwise identical to FIELD_{GET,PREP}(), and are intended to be used in the fully non-const variants later. [1] commit 5c667d5a5a3ec166 ("clk: sp7021: Adjust width of _m in HWM_FIELD_PREP()") [2] commit cfd6fb45cfaf46fa ("crypto: ccree - avoid out-of-range warnings from clang") Signed-off-by: Geert Uytterhoeven Link: https://git.kernel.org/torvalds/c/5c667d5a5a3ec166 [1] Signed-off-by: Yury Norov (NVIDIA) Stable-dep-of: 62bac3202042 ("drm/sun4i: tcon-top: Keep mixer routes distinct") Signed-off-by: Sasha Levin commit 00bc292e29a8ac25f6a62bb7c0d6db719c82c33e Author: Kuninori Morimoto Date: Mon Feb 5 05:37:28 2024 +0000 of: property: use unsigned int return on of_graph_get_endpoint_count() [ Upstream commit 574849054d97cee5be78d6c149d84685647fe774 ] Because of of_graph_get_endpoint_count() doesn't report error, just return count of endpoint, the return type should be unsigned. Tidyup it. Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/87plxbcvzb.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring Stable-dep-of: 62bac3202042 ("drm/sun4i: tcon-top: Keep mixer routes distinct") Signed-off-by: Sasha Levin commit 5c52816e96c292b29f2bc3a394e919fd8283fa4c Author: Kuninori Morimoto Date: Mon Feb 5 05:37:19 2024 +0000 of: property: add missing kerneldoc for of_graph_get_endpoint_count() [ Upstream commit 4c3b386c46065c0d26ae5503e73d6634f24e2d36 ] of_graph_get_endpoint_count() doesn't have kerneldoc. Add it. Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/87r0hrcvzk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring Stable-dep-of: 62bac3202042 ("drm/sun4i: tcon-top: Keep mixer routes distinct") Signed-off-by: Sasha Levin commit 88e109c99ec9313ab40c9ebea70addecd7a59b3c Author: Jernej Skrabec Date: Mon Aug 3 18:10:40 2026 +0200 drm/sun4i: vi scaler: Fix coefficient selection [ Upstream commit 5c31990b21f0b535732deb2b658b78b07464f56c ] Currently, vertical coefficients are selected based on horizontal scaling, which is wrong. Additionally, chroma coefficients should be selected based on format subsampling. Fix all that. Fixes: b862a648de3b ("drm/sun4i: Add support for HW scaling to DE2") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/263a4a41442a3c8b072b170256b72658f1b90802.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 7601db4c9d3bd9ab2482a863cb05204154d51ae8 Author: Cen Zhang Date: Wed Jun 24 17:53:09 2026 +0800 ocfs2: synchronize heartbeat callbacks with o2net teardown [ Upstream commit 3e326f3bf16506873777444608e8b715aab74a7a ] Patch series "ocfs2: harden heartbeat teardown races". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq. Link: https://lore.kernel.org/20260624095310.763763-1-zzzccc427@gmail.com Link: https://lore.kernel.org/20260624095310.763763-2-zzzccc427@gmail.com Fixes: 98211489d414 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Assisted-by: Codex:gpt-5.5 Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 02242632a46c67e40b083f3ea3484aab62f74d94 Author: Joseph Qi Date: Fri Oct 7 20:48:45 2022 +0800 ocfs2: use bitmap API in fill_node_map [ Upstream commit 6d4a93b6809270e5c7d7216b20f4ef2e88213eb3 ] Pass bits directly into fill_node_map helper and use bitmap API directly to simplify code. Link: https://lkml.kernel.org/r/20221007124846.186453-2-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Signed-off-by: Andrew Morton Stable-dep-of: 3e326f3bf165 ("ocfs2: synchronize heartbeat callbacks with o2net teardown") Signed-off-by: Sasha Levin commit ab14f07952adfe735d86a53518f8cd576dfd5892 Author: Xie Yuanbin Date: Tue Jul 28 03:16:42 2026 +0100 ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults [ Upstream commit 1039bffd6ae9c75b42b7d148d6c1106134107b66 ] When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the "oops" state, acquiring a lock may risk a deadlock. Co-developed-by: Qi Xi Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults") Link: https://lore.kernel.org/20260716014022.2823-1-xieyuanbin1@huawei.com Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Linus Walleij Signed-off-by: Qi Xi Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 3f7fdf561f1ec3b523c39708df00bd808671668d Author: Yehyeong Lee Date: Wed Jul 29 18:32:03 2026 +0900 RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ [ Upstream commit 961ac0f0c5e414abdd6b33fae84b311d9fde0bd0 ] srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned ".strtab". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read. Fixes: bb12588a38e6 ("IB/srp: Implement SRP_CRED_REQ and SRP_AER_REQ") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260729093203.1503201-1-yhlee@isslab.korea.ac.kr Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0820078dd8ce8e34189345db210ebc127c4858cb Author: Sergei Litvin Date: Tue Jul 14 10:33:31 2026 +0200 scripts/tags.sh: Prevent binary files appearing in cscope.files [ Upstream commit a9b93c34625a27bed5dc0f80ee2a359ceb955172 ] When executing the command `make COMPILED_SOURCE=1 cscope`, the resulting `cscope.files` file contains filenames with the extensions *.rlib, *.rmeta, and *.so. To fix this, modify the regular expression in the `all_compiled_sources()` function so that only files with the extensions *.h, *.c, *.S, and *.rs are accepted. The issue has been introduced by commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which implemented the parsing of compiled sources from *.cmd files instead of using the "find" command. Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Sergei Litvin Acked-by: Miguel Ojeda Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260714083331.69482-1-litvindev@gmail.com [nsc: cleaned-up commit message line breaks and removed cc trailers] Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit c23952fe65d8611f79e87a21c0471d23fdb29d89 Author: Jialu Xu Date: Thu Jun 1 09:04:02 2023 +0800 scripts/tags.sh: improve compiled sources generation [ Upstream commit 82089b00ae026f638277c51bf3f36c68ed4021c7 ] Use grep instead of sed for all compiled sources generation, it is three times more efficient. Signed-off-by: Jialu Xu Tested-by: Carlos Llamas Link: https://lore.kernel.org/r/20230601010402.71040-1-xujialu@vimux.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: a9b93c34625a ("scripts/tags.sh: Prevent binary files appearing in cscope.files") Signed-off-by: Sasha Levin commit 0d385be8f199b349f325cf90584b47b6a044ea79 Author: Mukesh Ojha Date: Mon Aug 3 17:13:31 2026 +0530 remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() [ Upstream commit bb840ea69347aff7bde5a208e7b5b180669a7656 ] table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic. Signed-off-by: Mukesh Ojha Fixes: fd2c15ec1dd3 ("remoteproc: resource table overhaul") Link: https://lore.kernel.org/r/20260803114331.3277263-6-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8bf174233c9689effd25ae741b004715f1e3e506 Author: Mukesh Ojha Date: Wed May 6 10:31:04 2026 +0530 remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources() [ Upstream commit 49abb5d6e1ac8169cdfc0c3aa4408e0d90ee5696 ] Replace the open-coded resource table iteration loop in rproc_handle_resources() with the rsc_table_for_each_entry() helper. The remoteproc-specific dispatch logic (vendor resource handling via rproc_handle_rsc(), RSC_LAST bounds check, handler table lookup) is moved into a local callback rproc_handle_rsc_entry(), keeping the iteration mechanics in one canonical place. The callback receives the payload offset within the table so that handlers which write back into the resource table (e.g. rproc_handle_carveout() recording a dynamically allocated address via rsc_offset) continue to work correctly. No functional change. Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260506050107.1985033-3-mukesh.ojha@oss.qualcomm.com Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit 1a55230c63a373c2d5d8439335ab5ed54261bed1 Author: Mukesh Ojha Date: Wed May 6 10:31:03 2026 +0530 remoteproc: Move resource table data structure to its own header [ Upstream commit 0590420c2f90de497d342c9a41a618f46f4d09ab ] The resource table data structure has traditionally been associated with the remoteproc framework, where the resource table is included as a section within the remote processor firmware binary. However, it is also possible to obtain the resource table through other means—such as from a reserved memory region populated by the boot firmware, statically maintained driver data, or via a secure SMC call—when it is not embedded in the firmware. There are multiple Qualcomm remote processors (e.g., Venus, Iris, GPU, etc.) in the upstream kernel that do not use the remoteproc framework to manage their lifecycle for various reasons. When Linux is running at EL2, similar to the Qualcomm PAS driver (qcom_q6v5_pas.c), client drivers for subsystems like video and GPU may also want to use the resource table SMC call to retrieve and map resources before they are used by the remote processor. In such cases, the resource table data structure is no longer tightly coupled with the remoteproc headers. Client drivers that do not use the remoteproc framework should still be able to parse the resource table obtained through alternative means. Therefore, there is a need to decouple the resource table definitions from the remoteproc headers. Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260506050107.1985033-2-mukesh.ojha@oss.qualcomm.com Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit 8c467258c3fe22efdf93449f2bd2e708dfd8e2f2 Author: Suman Anna Date: Wed May 19 13:03:04 2021 -0500 remoteproc: Fix various kernel-doc warnings [ Upstream commit f2867434002387c9739494041ac81c17a3808150 ] Fix all the kernel-doc warnings in various remoteproc core files. Some of them just needed a formatting cleanup change, while others needed the Return statement to be added, or documenting the missed structure elements. Reviewed-by: Mathieu Poirier Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210519180304.23563-3-s-anna@ti.com Signed-off-by: Bjorn Andersson Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit cab21c9992042e339c0b1a8e47e235ef85a47cf0 Author: Mathieu Poirier Date: Fri Mar 12 09:24:46 2021 -0700 remoteproc: Introduce function rproc_detach() [ Upstream commit d3962a397885518a85d2dc6b0c51e6594f71c30f ] Introduce function rproc_detach() to enable the remoteproc core to release the resources associated with a remote processor without stopping its operation. Signed-off-by: Mathieu Poirier Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-11-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit e18d891647a4e50aa3593bdb477194175d145e83 Author: Mathieu Poirier Date: Fri Mar 12 09:24:45 2021 -0700 remoteproc: Introduce function __rproc_detach() [ Upstream commit 6070203fe43335a02b7fd103bae582095411adc5 ] Introduce function __rproc_detach() to perform the same kind of operation as rproc_stop(), but instead of switching off the remote processor using rproc->ops->stop(), it uses rproc->ops->detach(). That way it is possible for the core to release the resources associated with a remote processor while the latter is kept operating. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-10-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit 480579bc7f8434655baf3a121a35a0996c300e60 Author: Mathieu Poirier Date: Fri Mar 12 09:24:44 2021 -0700 remoteproc: Add new detach() remoteproc operation [ Upstream commit 7f3bd0c019cb813448d867c17c9b9dad205a13eb ] Add an new detach() operation in order to support scenarios where the remoteproc core is going away but the remote processor is kept operating. This could be the case when the system is rebooted or when the platform driver is removed. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-9-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit 5c8abf5e19f256c27a364b232cebb206b68561d5 Author: Suman Anna Date: Fri Nov 20 21:20:42 2020 -0600 remoteproc: Add a rproc_set_firmware() API [ Upstream commit 4c1ad562d303526b5d9b49f5e0d72da13ef78dec ] A new API, rproc_set_firmware() is added to allow the remoteproc platform drivers and remoteproc client drivers to be able to configure a custom firmware name that is different from the default name used during remoteproc registration. This function is being introduced to provide a kernel-level equivalent of the current sysfs interface to remoteproc client drivers, and can only change firmwares when the remoteproc is offline. This allows some remoteproc drivers to choose different firmwares at runtime based on the functionality the remote processor is providing. The TI PRU Ethernet driver will be an example of such usage as it requires to use different firmwares for different supported protocols. Also, update the firmware_store() function used by the sysfs interface to reuse this function to avoid code duplication. Reviewed-by: Rishabh Bhatnagar Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20201121032042.6195-1-s-anna@ti.com Signed-off-by: Bjorn Andersson Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit ae945c59e12b2101842c6bd249da9d1e14cf87f8 Author: Krzysztof Wilczyński Date: Fri May 8 04:35:25 2026 +0000 PCI/sysfs: Add static PCI resource attribute macros [ Upstream commit b15ac7e008bf0039f981da21e983b2df130152ff ] Add three macros for declaring static binary attributes for PCI resource files: - pci_dev_resource_io_attr(), for I/O BAR resources (read/write) - pci_dev_resource_uc_attr(), for memory BAR resources (mmap uncached) - pci_dev_resource_wc_attr(), for write-combine resources (mmap WC) Each macro only sets the callbacks its resource type needs. The I/O macro conditionally includes mmap support via __PCI_RESOURCE_IO_MMAP_ATTRS on architectures where arch_can_pci_mmap_io() is true at compile time (such as PowerPC, SPARC, and Xtensa). Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Shivaprasad G Bhat Link: https://patch.msgid.link/20260508043543.217179-7-kwilczynski@kernel.org Stable-dep-of: bad94d3d18c6 ("PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap") Signed-off-by: Sasha Levin commit 5e44b6944e11fd6647f028219ad0be4e85e9acee Author: Yichong Chen Date: Wed Jul 15 10:09:57 2026 +0800 fat: release buffer head after rebuilding parent [ Upstream commit 83e98dbf19ab64e8528e101e20f8d50e1aaa68a8 ] fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data. Link: https://lore.kernel.org/20260715020957.1096309-1-chenyichong@uniontech.com Fixes: f1e6fb0ab451 ("fat (exportfs): rebuild directory-inode if fat_dget()") Signed-off-by: Yichong Chen Acked-by: OGAWA Hirofumi Cc: Christian Brauner Cc: Amit Sahrawat Cc: chenyichong Cc: Namjae Jeon Cc: Ravishankar N Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 24f60ebabeb8757cec8ec2f97660d521bc9147ec Author: Guangshuo Li Date: Wed Jul 8 15:06:28 2026 +0800 rapidio: clear mport->net when rio_add_net() fails [ Upstream commit b74030fbf187b43c1f85b66a7082e9946511cb5d ] rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path. Link: https://lore.kernel.org/20260708070628.721010-1-lgs201920130244@gmail.com Fixes: e842f9a1edf3 ("rapidio: add check for rio_add_net() in rio_scan_alloc_net()") Signed-off-by: Guangshuo Li Cc: Alexandre Bounine Cc: Matt Porter Cc: Yang yingliang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2c8771476042e8f2590d29c3afce959ad788e290 Author: Calvin Owens Date: Fri Jun 12 11:52:09 2026 -0700 pps: don't try to wait for negative timeouts in PPS_FETCH [ Upstream commit 45217e98987a87ff2372386dbf82fd5325db28ea ] If userspace passes a negative timeout to PPS_FETCH, it triggers a kernel splat from schedule_timeout(): schedule_timeout: wrong timeout value fffffffffff0bfb4 CPU: 17 UID: 0 PID: 4720 Comm: a.out Not tainted 7.1.0-rc5-x86-kvm-00150-g331d97e36b37 #1 PREEMPT_RT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-20240910_120124-localhost 04/01/2014 Call Trace: dump_stack_lvl+0x4b/0x70 schedule_timeout+0xb7/0xe0 pps_cdev_pps_fetch.isra.0+0x93/0x150 pps_cdev_ioctl+0x70/0x310 __x64_sys_ioctl+0x7b/0xc0 do_syscall_64+0xb6/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Here is a trivial reproducer that works with the PPS_CLIENT_KTIMER test device enabled in the kernel: #include #include #include #include #include #include int main() { struct pps_fdata fdata; int fd; fd = open("/dev/pps0", O_RDWR); if (fd == -1) err(1, "Failed to open /dev/pps0"); fdata.timeout.sec = -1; fdata.timeout.nsec = 0; if (ioctl(fd, PPS_FETCH, &fdata)) err(2, "PPS_FETCH failed"); close(fd); return 0; } Sashiko imagines this to be some sort of security problem, which is obviously really silly. But I think it is still worth fixing, so buggy userspace code can't trigger the splat. Silence the splat by using timespec64_to_jiffies(), which hard limits the timeout to LONG_MAX jiffies. To be safe, explicitly preserve the -ETIMEDOUT return value userspace sees today if it passes a negative timeout. If you really squint, this is still a slight behavior change in that there are "denormalized" combinations of tv_sec and tv_nsec which used to work but will now return -ETIMEDOUT. I can't imagine anybody will care about that... Link: https://lore.kernel.org/c5c97c3b3c9d66010382094fd538e59a38f4aacf.1781289959.git.calvin@wbinvd.org Fixes: eae9d2ba0cfc ("LinuxPPS: core support") Signed-off-by: Calvin Owens Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=3 Acked-by: Rodolfo Giometti Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2f025d4b02d53b0d7597e3620c4bbada5853ddf8 Author: Bradley Morgan Date: Sun Jun 21 12:11:33 2026 +0000 lib/string: fix memchr_inv() for large ranges [ Upstream commit c04cffb8c51618538f0c05c478a931eb6e1a806b ] memchr_inv() takes a size_t length but counts 8 byte words in an unsigned int. At 32GiB that count wraps, so the scan can quietly miss most of the range. Use size_t for the word count. Link: https://lore.kernel.org/20260621121133.16460-1-include@grrlz.net Fixes: 798248206b59 ("lib/string.c: introduce memchr_inv()") Signed-off-by: Bradley Morgan Cc: Akinbou Mita Cc: Andy Shevchenko Cc: Christoph Lameer Cc: Joern Engel Cc: Kees Cook Cc: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7fd6e4fb7dcf116e39a16e2e7bf196b2d388c85d Author: Tao Cui Date: Mon Jul 20 17:37:26 2026 +0800 block/kyber-iosched: flush per-cpu latency buckets over possible CPUs [ Upstream commit 482fc257de95ab181688e9d1dfcc6b6a58857b1e ] kyber_timer_fn() sums the per-cpu latency histograms with for_each_online_cpu(). A CPU that goes offline mid-interval leaves its bucket un-flushed; the samples are lost from the current decision and re-appear (stale) when the CPU is onlined again. Fixes: 6e25cb01ea20 ("kyber: implement improved heuristics") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-5-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9e1425698bc4308b8b2dd2b641e2e48fc143aff0 Author: Tao Cui Date: Mon Jul 20 17:37:25 2026 +0800 block/blk-iocost: collect per-cpu latency stats over possible CPUs [ Upstream commit 4e050c5b92c1600415b2cd452583e543036f3d73 ] ioc_lat_stat() walks ioc->pcpu_stat with for_each_online_cpu() to compute missed-ppm and rq_wait deltas. An offlined CPU is skipped, so its delta is dropped from the period and its last_* watermark is not advanced; on re-online the next collection sees a delta spanning the whole offline interval, corrupting the latency/vrate picture. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-4-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 40b668453f0e870ca80548e798558934e3019dd9 Author: Tao Cui Date: Mon Jul 20 17:37:23 2026 +0800 block/blk-stat: drain per-cpu callback stats over possible CPUs [ Upstream commit 9d617828cfc4d9a4d385daa2cd61f9db0592c53f ] blk_stat_timer_fn() sums and resets a callback's per-cpu buckets using for_each_online_cpu(). A CPU that goes offline with pending samples is skipped, so its samples are neither accumulated into the window nor cleared; they sit in the bucket until the CPU comes back online, at which point the stale values are flushed into whatever window is then running. This silently corrupts the latency picture that consumers (notably writeback throttling via wbt, and blk-mq latency tracking) base decisions on around CPU hotplug: under-counting while the CPU is offline, then a burst of stale data on re-online. Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-2-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6054fed6bad08b6d03973e8ffca7f0c9394d1c30 Author: Breno Leitao Date: Wed Jul 29 02:29:47 2026 -0700 phonet: pep: do not write beyond optlen in getsockopt [ Upstream commit 77e5eb0e192aec6710c03ca8144582fd2af36ca4 ] pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace. Fixes: 02a47617cdce ("Phonet: implement GPRS virtual interface over PEP socket") Acked-by: Rémi Denis-Courmont Reviewed-by: Joe Damato Acked-by: Stanislav Fomichev Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-4-c44576757c17@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d381e8d669ed580360a503934ff131bd966581f3 Author: Sang-Heon Jeon Date: Tue Jul 28 03:47:39 2026 +0900 iio: light: tsl2583: return zero in write_raw() on success [ Upstream commit 42e8791841e0677418a3ccc97fa5c22a1455f417 ] tsl2583_write_raw() returns the value of pm_runtime_put_autosuspend(), which is 1 if the device is already runtime suspended. In that case write() on the sysfs attribute returns 1 instead of the number of bytes written. Make tsl2583_write_raw() always return zero on success. Fixes: 371894f5d1a0 ("iio: tsl2583: add runtime power management support") Signed-off-by: Sang-Heon Jeon Reviewed-by: Brian Masney Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 07846886d708218a0cd52d6df143d3541b86934d Author: Sang-Heon Jeon Date: Tue Jul 28 03:47:38 2026 +0900 iio: light: isl29028: return zero in write_raw() on success [ Upstream commit 55b75622829779223b9e32aa9600a8651d3e2df4 ] isl29028_write_raw() returns the value of pm_runtime_put_autosuspend(), which is 1 if the device is already runtime suspended. In that case write() on the sysfs attribute returns 1 instead of the number of bytes written. Make isl29028_write_raw() always return zero on success. Fixes: 2db5054ac28d ("staging: iio: isl29028: add runtime power management support") Signed-off-by: Sang-Heon Jeon Reviewed-by: Brian Masney Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c9478440cf1307a811cdf663bc9b811ab3f61d06 Author: Yuanshen Cao Date: Fri Jul 24 23:46:01 2026 +0000 iio: light: tsl2772: fix ALS calibscale readback [ Upstream commit ac75550ab5b5d73649bffea245c2075fd9249bd0 ] The read_raw() implementation uses IIO_LIGHT to distinguish between the ambient light and proximity channels when handling IIO_CHAN_INFO_CALIBSCALE. However, the ALS channel is registered as IIO_INTENSITY, while write_raw() correctly writes to IIO_INTENSITY. As a result, reading in_intensity0_calibscale incorrectly returns the proximity gain instead of the ALS gain. This causes the following user-visible behavior: - Writing in_intensity0_calibscale appears to have no effect because the readback reports the proximity gain. - Writing in_proximity0_calibscale causes both in_proximity0_calibscale and in_intensity0_calibscale to report the same value. Fix this by checking for IIO_INTENSITY in read_raw(), matching the channel definition and the existing write_raw() implementation. Fixes: 3c97c08b5735 ("staging: iio: add TAOS tsl2x7x driver") Signed-off-by: Yuanshen Cao Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2f679c89782ef90ded306642cf7b081e89877bd9 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:04 2026 -0300 perf intel-bts: Fix off-by-one in auxtrace_info minimum size check [ Upstream commit b9fb8225951ce27e62a2235a71f3ab01137aaec3 ] Same pattern as the Intel PT fix: min_sz is set to sizeof(u64) * INTEL_BTS_SNAPSHOT_MODE, but the code accesses auxtrace_info->priv[INTEL_BTS_SNAPSHOT_MODE], which requires at least INTEL_BTS_SNAPSHOT_MODE + 1 elements. Use (INTEL_BTS_SNAPSHOT_MODE + 1) to ensure the highest accessed index is within bounds. Fixes: d0170af7004dce9c ("perf tools: Add Intel BTS support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 52df869790826f8a19b825ea7c18da395a646c95 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:03 2026 -0300 perf intel-pt: Fix off-by-one in auxtrace_info minimum size check [ Upstream commit c4362d5e1a5ed4ce2098798f655a636c4340fa20 ] min_sz is set to sizeof(u64) * INTEL_PT_PER_CPU_MMAPS, but the code accesses auxtrace_info->priv[INTEL_PT_PER_CPU_MMAPS], which requires at least INTEL_PT_PER_CPU_MMAPS + 1 elements. A file with exactly min_sz bytes of priv data passes the size check but the access reads one u64 past the validated region. Use (INTEL_PT_PER_CPU_MMAPS + 1) to ensure the highest accessed index is within bounds. Fixes: 90e457f7be087005 ("perf tools: Add Intel PT support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4d4345432a1d7f028db9c4f6bceba58e9ec61d31 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:02 2026 -0300 perf auxtrace: Fix queue grow overflow and old array leak [ Upstream commit 96fcc9ea5f18c083a1fa73da23afef7e953f7dca ] auxtrace_queues__grow() has two bugs: 1. When idx is UINT_MAX, the caller passes new_nr_queues = idx + 1 = 0. The function skips growing (since any nr_queues >= 0), returns success, and the caller accesses queue_array[UINT_MAX] — an OOB heap write. Fix by rejecting new_nr_queues == 0 up front. 2. The function allocates a new queue_array via calloc and copies elements from the old array, but never frees the old array. Fix by saving the old pointer and freeing it after the copy. Fixes: e502789302a6ece9 ("perf auxtrace: Add helpers for queuing AUX area tracing data") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6cf4adbefe62c10e017384a93d97d1f2b1503c2d Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:01 2026 -0300 perf thread-stack: Fix heap buffer overflow on branch stack wrap copy [ Upstream commit ab9c84d1cd59e6b3b73de34982a35a76e3a9b032 ] thread_stack__br_sample() copies the wrap-around portion of the branch stack ring buffer with: nr = min(ts->br_stack_pos, sz); memcpy(be, &src->entries[0], bsz * ts->br_stack_pos); 'nr' is correctly bounded to min(br_stack_pos, sz) but the memcpy uses the unbounded ts->br_stack_pos directly. When br_stack_pos exceeds the remaining destination space 'sz', this writes past the destination buffer. Use 'nr' (the bounded value) in the memcpy size, matching the pattern of the first memcpy in the same function. Fixes: 86d67180b920 ("perf thread-stack: Add branch stack support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ca32235b4f0df234d5395e56107b10513ac68e5d Author: Jiancheng Huang Date: Fri Jul 24 20:19:17 2026 +0800 HID: lg4ff: validate report length before fixed offsets [ Upstream commit be00988cce4ed44db1e61231d0ab71a64bab44cd ] lg4ff_raw_event() rewrites fixed report offsets when combined pedals are enabled. It currently assumes that each product report contains every source and destination byte used by the rewrite. Return without rewriting a short report before each product-specific access. Apply the same bound to the computed offset path. Fixes: c832f86effbc ("HID: hid-logitech: Add combined pedal support Logitech wheels") Signed-off-by: Jiancheng Huang Assisted-by: Codex:gpt-5.6-luna Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6bf123f5a653a45ed2495e400668c14a4b0935c8 Author: Ai Chao Date: Thu Jul 16 19:29:32 2026 +0800 HID: i2c-hid: Fix "(null)" output when reading report descriptor fails [ Upstream commit 8da0f0951deec9f0728ed2d9c54ded1c344b7542 ] When i2c-hid fails to read the HID report descriptor during device initialization, the error message prints as: hid (null): reading report descriptor failed The HID device name is set in hid_add_device() after calling hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls hid_err(), the device name has not been set yet, resulting in "(null)" output. Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because the I2C client device is fully initialized with a proper name, providing meaningful error messages for debugging. Before: hid (null): reading report descriptor failed After: i2c_hid i2c-TPD0001:00: reading report descriptor failed Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation") Signed-off-by: Ai Chao Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f74eacf8e80a5c39ef24ae4f75335834204c6ddc Author: Hans de Goede Date: Sat Dec 2 23:46:10 2023 +0100 HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling [ Upstream commit aa69d6974185e9f7a552ba982540a38e34f69690 ] Switch i2c_hid_parse() to goto style error handling. This is a preparation patch for removing the need for I2C_HID_QUIRK_NO_IRQ_AFTER_RESET by making i2c-hid behave more like Windows. Note this changes the descriptor read error path to propagate the actual i2c_hid_read_register() error code (which is always negative) instead of hardcoding a -EIO return. Reviewed-by: Douglas Anderson Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Stable-dep-of: 8da0f0951dee ("HID: i2c-hid: Fix "(null)" output when reading report descriptor fails") Signed-off-by: Sasha Levin commit 3ffb088a2ed34ca982cfc2c81d107ce370aa45f1 Author: Yousef Alhouseen Date: Sun Jun 28 02:58:46 2026 +0200 HID: synchronize input before cleaning up a failed probe [ Upstream commit 207853d46f7ef2e28042344a1468da8754c3ddbf ] hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress. Fixes: c849a6143bec ("HID: Separate struct hid_device's driver_lock into two locks.") Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Yousef Alhouseen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e6ea3de7abef998aaab9f04a7a11a7c5f56bbe57 Author: Dmitry Torokhov Date: Tue May 23 14:04:32 2023 -0700 HID: ensure timely release of driver-allocated resources [ Upstream commit 62c68e7cee332e08e625af3bca3318814086490d ] More and more drivers rely on devres to manage their resources, however if bus' probe() and release() methods are not trivial and control some of resources as well (for example enable or disable clocks, or attach device to a power domain), we need to make sure that driver-allocated resources are released immediately after driver's remove() method returns, and not postponed until driver core gets around to releasing resources. In case of HID we should not try to close the report and release associated memory until after all devres callbacks are executed. To fix that we open a new devres group before calling driver's probe() and explicitly release it when we return from driver's remove(). This is similar to what we did for I2C bus in commit 5b5475826c52 ("i2c: ensure timely release of driver-allocated resources"). It is tempting to try and move this into driver core, but actually doing so is challenging, we need to split bus' remove() method into pre- and post-remove methods, which would make the logic even less clear. Reported-by: Stephen Boyd Link: https://lore.kernel.org/r/20230505232417.1377393-1-swboyd@chromium.org Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Stable-dep-of: 207853d46f7e ("HID: synchronize input before cleaning up a failed probe") Signed-off-by: Sasha Levin commit e51882f2bf470ef77484ebd3b648553173253511 Author: Dmitry Torokhov Date: Tue May 23 14:04:31 2023 -0700 HID: split apart hid_device_probe to make logic more apparent [ Upstream commit 207733f9266194b3cd90ddae723a1f82eb64030b ] hid_device_probe() has a complex flow and locks and unlocks a mutex. Move the most of the logic into __hid_device_probe() and hid_check_device_match() and leave the locking in hid_device_probe() which makes the code more clear. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Stable-dep-of: 207853d46f7e ("HID: synchronize input before cleaning up a failed probe") Signed-off-by: Sasha Levin commit fb1de260033c215dba438973d82b48562bdc86bb Author: Karl Mehltretter Date: Fri Jul 31 20:18:43 2026 +0200 tty: clear cdev pointer after cdev_add() failure [ Upstream commit 6645856f0df3aeecd45519cb611415b4b89c2223 ] tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference. Fixes: c1a752ba2d6b ("tty: don't leak cdev in tty_cdev_add()") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-5-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1474c684aba9477f78f54c886f66a8da80c37d35 Author: Karl Mehltretter Date: Fri Jul 24 23:33:47 2026 +0200 serial: amba-pl011: unprepare console clock on unregister [ Upstream commit 7f93da9d78d433c37836d85de475c5d884ad58ed ] pl011_console_setup() calls clk_prepare() on the UART clock, but the console provides no matching teardown, so the clock is never unprepared when the console is unregistered -- via the sysfs "console" attribute or a driver unbind. Each re-registration prepares the clock again, leaking one prepare reference per cycle. Even where preparing the clock has no hardware effect, the stale reference leaves the clock framework's prepare count unbalanced. For providers with prepare/unprepare operations or runtime-PM integration, it may also retain resources after the console is unregistered. Add a console .exit() callback that clk_unprepare()s the clock, balancing the clk_prepare() in pl011_console_setup(). Fixes: 4b4851c65d92 ("clk: amba-pl011: convert to clk_prepare()/clk_unprepare()") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260724213348.77418-2-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 991a4960cda3a034d18f24744cc41d8902d08cc8 Author: Thomas Bogendoerfer Date: Fri Jul 17 13:27:31 2026 +0200 MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL [ Upstream commit 5475c03fa25f31cfd5f8c7e552f8d10347bbaad9 ] If tracer wanted to skip a syscall return value was always overwritten with -ENOSYS. Fix this by checking against original syscall number and only return -ENOSYS, if it is negative. Fixes: b6318a903d06 ("MIPS/ptrace: Pick up ptrace/seccomp changed syscalls") Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 6deaa01f9f79baa652bf2c4443dce6c257d44b10 Author: Gou Hao Date: Mon Jul 27 18:42:15 2026 +0800 powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass [ Upstream commit 5aabc192702defb8950e7c81b05c3f4ca8ee43ec ] smp_muxed_ipi_message_pass() calls smp_ops->cause_ipi() without checking whether it has been set. On platforms using muxed IPI (e.g. powernv/pseries), smp_ops->cause_ipi is initialized to NULL in the static smp_ops and only assigned during the platform smp_probe() handler. If the IPI subsystem fails to initialize -- for example when xive_init_ipis() fails and xive_smp_probe() returns an error -- the probe handler returns early and cause_ipi is never set. Any subsequent IPI send (e.g. arch_smp_send_reschedule()) would dereference the NULL pointer. Add a NULL check to avoid the crash in that situation. Fixes: 23d72bfd8f9f ("powerpc: Consolidate ipi message mux and demux") Signed-off-by: Gou Hao Reviewed-by: jiazhenyuan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-6-gouhao@uniontech.com Signed-off-by: Sasha Levin commit 3cca0d6dd4c2636d2514234233cb02db76621607 Author: Laxman Acharya Padhya Date: Sat Aug 1 22:41:51 2026 +0545 firmware: coreboot: Validate table bounds [ Upstream commit a58a57a1076f8c5dae0327e3710899478c3be901 ] The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Signed-off-by: Laxman Acharya Padhya Link: https://lore.kernel.org/r/20260801165651.42172-1-acharyalaxman8848@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 59bd53a953daf72d6dff8f9468f60bd5067fb534 Author: Titouan Ameline de Cadeville Date: Sun Apr 26 23:47:39 2026 +0200 firmware: google: Add bounds checks in coreboot_table_populate() [ Upstream commit 7b1a1af4556a4f95ef273e91435fe804cbfcd223 ] coreboot_table_populate() iterates over firmware-provided table entries with no validation that the entries stay within the mapped memory region. A corrupt table with a large `entry->size` advances `ptr_entry` past the mapped region, causing an out-of-bounds read on the next iteration. Add a check before dereferencing `ptr_entry` to ensure the entry header is readable, and a second check after reading `entry->size` to ensure the full entry stays within the mapped region. Pass `len` from coreboot_table_probe() into coreboot_table_populate() to make the mapped region size available for validation. Signed-off-by: Titouan Ameline de Cadeville Reviewed-by: Julius Werner Link: https://lore.kernel.org/r/20260426214739.117131-1-titouan.ameline@gmail.com Signed-off-by: Tzung-Bi Shih Stable-dep-of: a58a57a1076f ("firmware: coreboot: Validate table bounds") Signed-off-by: Sasha Levin commit 1f56bed7e69d1d7ecddcea32e5e5712542b9a67f Author: Kees Cook Date: Thu Jan 12 15:03:16 2023 -0800 firmware: coreboot: Check size of table entry and use flex-array [ Upstream commit 3b293487b8752cc42c1cbf8a0447bc6076c075fa ] The memcpy() of the data following a coreboot_table_entry couldn't be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it easier to reason about, add an explicit flexible array member to struct coreboot_device so the entire entry can be copied at once. Additionally, validate the sizes before copying. Avoids this run-time false positive warning: memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8) Reported-by: Paul Menzel Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/ Cc: Jack Rosenthal Cc: Guenter Roeck Cc: Julius Werner Cc: Brian Norris Cc: Stephen Boyd Cc: Greg Kroah-Hartman Signed-off-by: Kees Cook Reviewed-by: Julius Werner Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org Reviewed-by: Stephen Boyd Reviewed-by: Jack Rosenthal Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org Stable-dep-of: a58a57a1076f ("firmware: coreboot: Validate table bounds") Signed-off-by: Sasha Levin commit b52799a8c9fdc8991aac3979026397804e1f6fd1 Author: Philipp Borgers Date: Wed May 19 14:20:17 2021 +0200 mac80211: add ieee80211_is_tx_data helper function [ Upstream commit cff7b5ca25353bef5909e357a9912f3d44b32af5 ] Add a helper function that checks if a frame is a data frame. Frames with hardware encapsulation enabled are data frames. Signed-off-by: Philipp Borgers Link: https://lore.kernel.org/r/20210519122019.92359-2-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg Stable-dep-of: fd2bf5e71810 ("wifi: mac80211: skip unused probe response countdown offsets") Signed-off-by: Sasha Levin commit 0b7a504b98ea0fb090dca85488ac2354af018942 Author: Slawomir Stepien Date: Thu Jul 30 08:52:31 2026 +0200 wifi: zd1211rw: reject secondary interfaces to prevent conflicts [ Upstream commit 0e4532ec658606f76f62eb277e7a933919d36cbb ] The zd1211rw driver is designed for single-function Wi-Fi dongles and hardcodes its USB endpoints. When a malformed USB device exposes multiple interfaces that match the driver's device ID, the driver blindly binds to all of them. During probe(), the driver calls usb_reset_device(), which iterates over all interfaces and invokes the pre_reset() callback for each bound interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is called sequentially for each instance, acquiring their respective &mac->chip.mutex. Because all instances initialize their mutexes with the same lock class, lockdep detects a task acquiring a lock of the same class it already holds and flags it as a possible recursive deadlock: WARNING: possible recursive locking detected kworker/0:1/11 is trying to acquire lock: ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: zd_chip_disable_rxtx+0x20/0x50 drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 but task is already holding lock: ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != 0) during probe(). This ensures that only a single instance of the driver binds to the device, eliminating the recursive locking scenario. Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260730065231.1644030-1-sst@poczta.fm Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a57f6bc2fcd87d1018620eec35926a13287dacb7 Author: Pranjal Shrivastava Date: Tue Jul 28 21:11:23 2026 +0000 iommu/arm-smmu-v3: Convert to use atomic poll timeout [ Upstream commit eced8058c82a3a81ae480a6546e2da32100dddfa ] The arm_smmu_write_reg_sync() helper is currently implemented using readl_relaxed_poll_timeout() (that relies on usleep_range() internally) which becomes a critical issue when used in the gerror irq handler. If the SMMU hits a gerror and enters Service Failure Mode (GERROR_SFM_ERR), the gerror handler calls arm_smmu_device_disable() in hard-irq context. This becomes a problem as arm_smmu_device_disable() inevitably calls arm_smmu_write_reg_sync() which might attempt to sleep inside a hard-irq context. Fix this by converting the arm_smmu_write_reg_sync to use the readl_relaxed_poll_timeout_atomic() polling helper. (Discovered while running Sashiko locally on another patch series). Reported-by: Sashiko Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Signed-off-by: Pranjal Shrivastava Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e5bc3658da9c8a535e3fa5c0c875b2a456954e81 Author: Linghui Wu Date: Mon Jul 27 12:56:29 2026 +0530 wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump [ Upstream commit 4f25071afe9218aaae1c63fbf75e229aa6405319 ] On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1 Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Signed-off-by: Linghui Wu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 323b6556d013b525e586cec882226720d250fe7b Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:14 2026 -0300 perf machine: Check snprintf truncation for guest kallsyms path [ Upstream commit d04ef71492fad7230d474efe33d05f4c0563d409 ] machines__create_guest_kernel_maps() builds the guest kallsyms path with snprintf() without checking the return value. A truncated path could pass the access() check if a prefix directory happens to contain a file named "kallsyms", leading to the wrong file being used for symbol resolution. Check for truncation and skip the directory. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 66a4540984cca32d762ec297232aa5c8a5d9cd9c Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:13 2026 -0300 perf machine: Free scandir entries in guest kernel map creation [ Upstream commit f53bf58dcd11e1cb088d3b91a035fef77062094b ] machines__create_guest_kernel_maps() calls scandir() which allocates both the namelist array and each individual dirent entry. The code frees the namelist array but not the individual entries, leaking memory proportional to the number of directories under guestmount. Free each namelist[i] after it is no longer needed. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e64ddd34db9ccfb3b00357e16d8009231f73fd88 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:12 2026 -0300 perf machine: Reset errno before strtol in guest kernel map creation [ Upstream commit 29ec46e43f6ca7d6a6651db724d4ffd820f46e8b ] machines__create_guest_kernel_maps() checks errno == ERANGE after strtol() to detect overflow, but does not clear errno first. A stale ERANGE from an earlier library call (e.g. scandir internals) causes valid numeric directory names to be incorrectly skipped. Set errno = 0 before strtol() so only the current conversion can trigger the ERANGE check. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1eddf7107c9132d2f318fe3b2c1631d976e22b05 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:11 2026 -0300 perf machine: Don't abort guest map creation on first inaccessible dir [ Upstream commit b687e1a418fb819ef83c362d84c216a6a841e3b0 ] machines__create_guest_kernel_maps() jumps to the failure label when one guest directory's kallsyms file fails access(), skipping all remaining valid guest directories. An inaccessible directory is not fatal — other guests may still be reachable. Replace 'goto failure' with 'continue' so the loop processes all directories, and remove the now-unreferenced failure label. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8a253747a3996960bb1a98722c0a77519899bb2b Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:10 2026 -0300 perf machine: Check snprintf truncation in machines__findnew() [ Upstream commit cc6abe0012bf8c04af8275266f8ed7c55ba4a5fb ] The guestmount path is built with snprintf() into a PATH_MAX buffer without checking the return value. If symbol_conf.guestmount is long enough to cause truncation, the truncated path could match a different directory, causing the wrong guest to be associated with the pid. Check for truncation and bail out early. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 738347a3e21fd86b49b3109593d79c0ed3b0c1d8 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 13:59:39 2026 -0300 perf machine: Use snprintf() for guestmount path construction [ Upstream commit fe63d3bca288c5bb983304efd5fc3a5ff3183403 ] machines__findnew() and machines__create_guest_kernel_maps() use sprintf() to build paths by prepending symbol_conf.guestmount. Both write into PATH_MAX stack buffers, but guestmount comes from user configuration and is not length-checked. A guestmount path at or near PATH_MAX causes a stack buffer overflow. Switch to snprintf() with sizeof() to prevent overflow. The subsequent access()/fopen() calls will fail on a truncated path. Fixes: a1645ce12adb6c9c ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: cc6abe0012bf ("perf machine: Check snprintf truncation in machines__findnew()") Signed-off-by: Sasha Levin commit 22b95c74cca41c8d65890f0f9058557007c86d9f Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:09 2026 -0300 perf machine: Guard against NULL strlist in machines__findnew() [ Upstream commit e27b96d0a34e1dc87affecf221a99fee8f6c5afc ] The static 'seen' strlist caches guestmount paths that have already been reported as inaccessible, to avoid repeating the error message. If strlist__new() fails (OOM), 'seen' stays NULL and the next call dereferences it via strlist__has_entry() and strlist__add(). Guard both calls so that on allocation failure the error message is still printed (just not deduplicated) instead of crashing. Fixes: c80c3c269011 ("perf kvm: Limit repetitive guestmount message to once per directory") Reported-by: sashiko-bot Cc: David Ahern Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2cebc00340a585adeffe321bc41f1937eb79a4dc Author: Joy Zou Date: Fri Jul 31 18:21:43 2026 +0800 regulator: core: use system_freezable_wq for init complete work [ Upstream commit 03eab318cedd6ae34ecd34533cd986edf5237164 ] schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race. Fixes: 55576cf18537 ("regulator: Defer init completion for a while after late_initcall") Signed-off-by: Joy Zou Reviewed-by: Frank Li Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-1-a406c8737fdb@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 35cb3086b426b3468cfc32d0d8d9883409705ea9 Author: Jeff Johnson Date: Mon Jul 27 16:39:41 2026 -0700 wifi: ath11k: fix leak in ath11k_service_ready_ext_event() [ Upstream commit 0293be2212d319d59589082461abf2a9b626cd1c ] Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only. Fixes: 5b90fc760db5 ("ath11k: fix wmi service ready ext tlv parsing") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727-ath11k_service_ready_ext_event-memleak-v1-1-e8373d27bdd1@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit bc1df05cccdb4f08aa42e736b54d265c6c11a45b Author: Konrad Dybcio Date: Tue Jul 28 15:20:47 2026 +0200 drm/msm/dsi: Drop dev_pm_opp_set_rate(0) [ Upstream commit 06b7ba206561619bb34116f49e0ef26b867ce3aa ] dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Fixes: 32d3e0feccfe ("drm/msm: dsi: Use OPP API to set clk/perf state") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/742783/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-3-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4534c34e87a671a758cc340d40736ea5e8b9705e Author: Leo Yan Date: Thu Jul 2 18:05:21 2026 +0100 perf: arm_spe: Make wakeup range check overflow safe [ Upstream commit fcc5eaea2d234162dfb8258372dd897bc2a1b862 ] The current code checks whether the wakeup point is in the current writable range by comparing it with handle->head + handle->size. The perf AUX head is a monotonically increasing index, so that addition can overflow when head is close to ULONG_MAX. In that case, a wakeup point which is still inside the free space range can be missed. Use unsigned subtraction to compare the distance from head to wakeup against the handle->size. This can dismiss the issue when addition overflow. This is unlikely to happen in practice, but the change makes the watermark check logically correct. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 042c87e1989264c7d50268219d7704321cb2e102 Author: Felix Fietkau Date: Fri Jul 24 12:47:56 2026 +0000 wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields [ Upstream commit 04280d0a56be4264720e7b205daaa332c715e5ec ] train_up_high_thres, train_up_rule_rssi and low_traffic_thres were declared as host-native short in a firmware-facing TLV and assigned host-order constants, so on a big-endian host the firmware received byte-swapped rate-adaptation thresholds. Declare them __le16 and convert with cpu_to_le16(). Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Link: https://patch.msgid.link/20260724124813.3961474-12-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2801477c36a19be4f549fe60e54995f03b0ea7b9 Author: Felix Fietkau Date: Wed Jul 22 08:26:01 2026 +0000 wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss [ Upstream commit 4a2f4be532e3ea4e2b536e411793a05aaa51af25 ] If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0. Fixes: 89029a85482c ("mt76: mt7915: add Tx beamformer support") Link: https://patch.msgid.link/20260722082610.2699628-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 61b1f6d92249bc34580ff19de7c69c805f82adca Author: Devin Wittmayer Date: Fri Jun 12 17:25:43 2026 -0700 wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length [ Upstream commit 81497634d9f872fd3e8b03aada55574afff6f174 ] The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARN_ONs in tx status and rx path") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel. Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e") Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260613002544.27750-2-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 270749c2ae1b34b0423b4de44429223bc964b6c2 Author: Yichong Chen Date: Fri Jul 31 10:18:27 2026 +0800 fanotify: report full event length for FIONREAD [ Upstream commit 68615158c12de36220446dfea5cfdf9ba6c19690 ] fanotify_ioctl(FIONREAD) reports the number of bytes available to read from the event queue. It currently accounts only FAN_EVENT_METADATA_LEN for each queued event. That underestimates events that carry additional information records, such as FAN_REPORT_DFID_NAME events. A userspace program that uses FIONREAD to size its read buffer can receive a length that is smaller than the next event. Reading with that buffer then fails with -EINVAL, while a larger buffer succeeds and reports a larger metadata.event_len. Use fanotify_event_len() when summing queued events so FIONREAD includes all info records. Fixes: 5e469c830fdb ("fanotify: copy event fid info to user") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260731021827.602479-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit fc888a283f3e9d80305b888af31627f5b2a2453e Author: Abdun Nihaal Date: Wed Jul 22 15:42:13 2026 +0530 misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe() [ Upstream commit 210854a96ef18b09b45a2a59ff14ca06dfe5ad4d ] The memory allocated for struct vmci_subscription (sub) is not freed in the error path when have_new_id is false. Fix that by adding a kfree() call, and moving the read of sub->id to a point before freeing. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Signed-off-by: Abdun Nihaal Acked-by: Vishnu Dasa Link: https://patch.msgid.link/20260722101215.76680-1-nihaal@cse.iitm.ac.in Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f6093ff67ea6e347574819ed23e96e0f82a25ffc Author: Naveen Kumar Chaudhary Date: Thu Jun 11 23:08:17 2026 +0530 locking/lockdep: Fix NULL pointer dereference in __lock_set_class() [ Upstream commit 7577e00b9ab506202b9f1a33de3cc8cc6413a4db ] register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site. Fixes: 64aa348edc61 ("lockdep: lock_set_subclass - reset a held lock's subclass") Signed-off-by: Naveen Kumar Chaudhary Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Waiman Long Reviewed-by: Dmitry Ilvokhin Link: https://patch.msgid.link/h2kfw43n4527x6mgi2lwpz2rieqnfzgictpv4wr5nyfjkc47co@2r5vz4uz44db Signed-off-by: Sasha Levin commit 5bf498623f8397d45f85f14cd631c5e5a565c2fb Author: Adrian Hunter Date: Thu Jul 2 21:36:44 2026 +0300 i3c: master: Fix device_register() error path [ Upstream commit 74be657d98a8d684c0475f3cbd450ef2a30ffc73 ] When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260701203053.8F3971F000E9@smtp.kernel.org/ Fixes: cab63f6488761 ("i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260702183644.60827-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 5650b013e6bfc14c8b30be727f4a715b01860a08 Author: Jakub Kicinski Date: Tue Jun 30 10:29:04 2026 -0700 i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices [ Upstream commit 038cf48b3170af26a70bf2dee4f8c3ac910f5176 ] On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Jakub Kicinski Reviewed-by: Frank Li Link: https://patch.msgid.link/20260630172904.2662160-1-kuba@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ac9cd0a669b8be5d178dbd471b0d68039dac58b5 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:21 2026 +0530 iommu/dma: Check atomic pool allocation result directly [ Upstream commit af95a0ebc0a0db0762be75f51eadf770bad01aaa ] The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping. Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings") Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-4-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 5118ac0852e3127be9186cfd9781ac5dec5079dd Author: Vladimir Zapolskiy Date: Mon Jun 29 19:21:27 2026 +0300 clk: qcom: Return expected ENOMEM error on dynamic allocation failure [ Upstream commit 22d9257f08913b6eec3e8ece4d13d9c41f14428b ] If a dynamic memory allocation fails, the returned error code in clock controller driver probe functions on a few legacy platforms should be set to -ENOMEM instead of -EINVAL. Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629162127.3910603-1-vz@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 50606ced303782f8715e2d0b98ca374ea498fa29 Author: Stanislav Kinsburskii Date: Wed Jul 1 15:02:20 2026 -0700 lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone [ Upstream commit 6a8024511ddf4877435c34fb3d6028aa8e590649 ] dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable. Link: https://lore.kernel.org/178294308408.327222.3319445682023999403.stgit@skinsburskii Fixes: b2ef9f5a5cb37 ("mm/hmm/test: add selftest driver for HMM") Signed-off-by: Stanislav Kinsburskii Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Ralph Campbell Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d462b5481d77ce7df8a5ff89a699386f00c9214d Author: Pu Lehui Date: Tue Jul 28 02:32:59 2026 +0000 bpf: Fix potential UAF in bpf_netns_link_update_prog [ Upstream commit 5c5997836381010fc5907b36bc17d3b19407e933 ] In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping. Fixes: 7f045a49fee0 ("bpf: Add link-based BPF program attachment to network namespace") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Amery Hung Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728023259.2813482-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit bb74a5ab30963022981381ea6aee176fd0c7957c Author: Hongyan Xu Date: Wed Jul 29 18:46:59 2026 +0800 power: supply: sc2731_charger: cancel work on remove [ Upstream commit dfc859bb8d332c525872f1a44028137724fa1998 ] The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool. Fixes: 8ac1091ed18b ("power: supply: sc2731_charger: Add one work to charge/discharge") Reviewed-by: Baolin Wang Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/5d48b827687168cb1b1bfe85f17945566b42829d.1785321763.git.getshell@seu.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c4efc591b3c4b7f8810b7d4b51ffc23f99fc6acd Author: Uwe Kleine-König Date: Mon Sep 18 15:36:52 2023 +0200 power: supply: sc2731_charger: Convert to platform remove callback returning void [ Upstream commit 0569d4cfa800ba303647dbf8170d1e89bdee3ed9 ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230918133700.1254499-25-u.kleine-koenig@pengutronix.de Signed-off-by: Sebastian Reichel Stable-dep-of: dfc859bb8d33 ("power: supply: sc2731_charger: cancel work on remove") Signed-off-by: Sasha Levin commit b0fa49bcb25b905b49dbb681c8a94f00d1a7f94d Author: Hongyan Xu Date: Tue Jul 28 20:33:39 2026 +0800 power: supply: isp1704_charger: cancel work on remove [ Upstream commit 60c5b8a9ef4dbc5d69bbc1a960fe55826cb3b643 ] The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool. Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/20260728123423.781-5-getshell@seu.edu.cn Fixes: ec46475f3e31 ("power_supply: Add isp1704 charger detection driver") Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit df0c5b823db59c8a5ff782ef7575f0ee7cedeb5f Author: Cheng-Han Wu Date: Sun Jun 7 17:57:32 2026 +0800 selftests/zram: fix kernel_gte() for POSIX sh [ Upstream commit 649ba27dfac784427a01f9c95c09ecbcb88900d8 ] Commit fc4eb486a59d ("selftests/zram: Skip max_comp_streams interface on newer kernel") added kernel_gte() to zram_lib.sh. The function uses the bash-specific [[ ... ]] conditional, but zram selftests source this file while running under /bin/sh. On systems where /bin/sh is dash, such as Debian, the following test fails: dash -c ' kernel_major=6; kernel_minor=1; major=6; minor=0 if [ $kernel_major -gt $major ]; then echo ok elif [[ $kernel_major -eq $major && $kernel_minor -ge $minor ]]; then echo ok fi' with: dash: 5: [[: not found Use separate POSIX test expressions joined by && instead. Fixes: fc4eb486a59d ("selftests/zram: Skip max_comp_streams interface on newer kernel") Signed-off-by: Cheng-Han Wu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit cf01f9413565e86673baf927291a088b6975692b Author: Sajal Gupta Date: Mon Jun 22 19:36:03 2026 +0530 md/raid5-ppl: fix use-after-free in ppl_do_flush() [ Upstream commit 371f7a1b392edc8b7cf449cc7713179b588f2d0e ] The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed. Fixes: 1532d9e87e8b ("raid5-ppl: PPL support for disks with write-back cache enabled") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/ajJF2wKYWRk4GGCK@stanley.mountain/ Signed-off-by: Sajal Gupta Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260622142146.56637-1-sajal2005gupta@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 2634998247d24be34ba16a7666f31815ef1da00b Author: Abdun Nihaal Date: Thu Jul 23 17:31:15 2026 +0530 wifi: rtlwifi: pci: fix error path in rtl_pci_probe() [ Upstream commit 3c2999d13eeb222ae56631aeb7ca248090f2b210 ] In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Abdun Nihaal Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260723120118.145383-1-nihaal@cse.iitm.ac.in Signed-off-by: Sasha Levin commit c0892cfb60a75e2c86ba8e2127b133f6549c12b3 Author: Guixin Liu Date: Wed Jul 29 18:58:46 2026 +0800 nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request [ Upstream commit f49d0c3a8d56a7cda1628ae17341a4a42063563c ] __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset(). Fixes: e399441de911 ("nvme-fabrics: Add host support for FC transport") Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b1f3313e7b3e396e4985fea5c709477387e0a065 Author: Yehyeong Lee Date: Mon Jul 27 01:39:31 2026 +0900 IB/isert: reject login PDUs declaring more data than was received [ Upstream commit 2488b5b4827e5415768afc8daf097e8eb83c98df ] isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), payload_length = ntoh24(login_req->dlength); tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Suggested-by: Leon Romanovsky Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260726163931.971063-3-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b4706722ed3ea72882b3c986a19b4a1ba66384c4 Author: Yehyeong Lee Date: Mon Jul 27 01:39:30 2026 +0900 IB/isert: reject PDUs declaring more data than was received [ Upstream commit 957f92ea4022fb6af4618271615a2a21a7b5bef9 ] isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d ("IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything further, and cannot cause a false reject: a PDU carrying an AHS is longer, not shorter. This is a memory-safety fix that verifies the bytes that were actually received; it does not touch RFC 7145 length negotiation and is not the MaxXmitDataSegmentLength negotiation redesign raised in the 2017 "[Query] iSER-Target: QP errors observed on increasing MaxXmitDataSegmentLength" discussion. That redesign is explicitly out of scope here. The patched kernel rejects the malformed DataOut PDU and both immediate-data variants with "PDU declares ... bytes were received" and continues to pass normal traffic with no regression. Reproduced with soft-RoCE (rdma_rxe) and a raw rdma_cm/ibv initiator; no kernel-side test hooks were needed. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260726163931.971063-2-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5fe4731bfbd8d83c4a14b4af3a27329969ce8a99 Author: Leon Romanovsky Date: Sun Jul 26 15:21:44 2026 +0300 RDMA/cxgb4: free STAG index when TPT entry write fails [ Upstream commit fdfb5cea4bf070cdb31d997efd87bb684df041fd ] write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free. Fixes: ec3eead21718 ("RDMA/cxgb4: Remove kfifo usage") Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 344b591849eadf5bb252a2148b695910c82558dc Author: Leon Romanovsky Date: Sun Jul 26 12:22:11 2026 +0300 RDMA/mlx5: Send cong param changes to the resolved port mdev [ Upstream commit 033a79e308e4fe832b0924347eda8c4364055174 ] mlx5_ib_set_cc_params() resolves the port-specific mlx5_core_dev via mlx5_ib_get_native_port_mdev() but issued MLX5_CMD_OP_MODIFY_CONG_PARAMS through dev->mdev. On an affiliated secondary RoCE port those pointers refer to different devices, so a write to the secondary port's cc_params debugfs file either altered the master port or failed with a master-side command error, while the read path already used the resolved mdev and returned the unchanged secondary value. Issue the command to the resolved mdev, the same device whose capabilities were checked when its debugfs directory was created. It is already referenced by the get/put pair, so its lifetime is safe. Fixes: 31578defe4eb ("RDMA/mlx5: Update mlx5_ib to use new cmd interface") Link: https://patch.msgid.link/20260726-mlx5-ib-set-cc-params-applies-conges-v1-1-a253edafe1f3@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1c5b4f76cd73372c5a8a4c91c95d5a31f141e091 Author: Leon Romanovsky Date: Sun Jul 26 12:13:55 2026 +0300 RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs [ Upstream commit 03826bc1fa6c90405bf05831f2b501a8368dcd27 ] get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored. Fixes: 4a2da0b8c0782 ("IB/mlx5: Add debug control parameters for congestion control") Link: https://patch.msgid.link/20260726-get-param-leaks-kernel-stack-memory-v1-1-d61a4d39662d@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 16df2520502867a4f34e202b89d01243d59bb8b5 Author: David Lee Date: Sat Jul 18 01:56:21 2026 +0900 nilfs2: prevent out-of-bounds read in super root block parsing [ Upstream commit 7cb2f76a6a2ba2130b577cb8ac13e1e46c4fc689 ] super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title] Fixes: 8a9d2191e9f4 ("nilfs2: operations for the_nilfs core object") Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit e3e9367dae1a6392cbb14ab0b2ab5edbf39735c3 Author: Joshua Crofts Date: Fri Jul 17 10:58:54 2026 +0000 nilfs2: fix infinite loop in nilfs_clean_segments() [ Upstream commit ce5a5ad1a8330a2fcfdd9ec2ab341be739e89a18 ] syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS. Reported-by: syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cae54346a70bbceeff2c Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Assisted-by: gemini:gemini-3.1-pro Signed-off-by: Joshua Crofts Acked-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit c7f1f581c26b07a5e5f583e53fca8b23d3dc6f6f Author: longlong yan Date: Tue Jul 14 14:51:32 2026 +0800 clk/x86: pmc_atom: add kasprintf return value check [ Upstream commit 18e9d14cbac33db1c1fb933c26a736eef53dd538 ] The kasprintf() function returns NULL on memory allocation failure, but the code in plt_clk_register() was not checking this return value. If kasprintf fails, init.name would be NULL and could cause NULL pointer dereference when clkdev_hw_create() uses it. Add proper error checking for the kasprintf() return value and return ERR_PTR(-ENOMEM) on failure. Fixes: 1141d9d08184 ("clk: x86: Add Atom PMC platform clocks") Signed-off-by: longlong yan Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 7523e47047fc52e84fe443a557df7bc0296639e9 Author: Myeonghun Pak Date: Sat Jul 11 23:17:42 2026 +0900 clk: palmas: Manage external-control prepare with devm [ Upstream commit ccda84fcbf3a972973f772384935928f41817b3a ] palmas_clks_init_configure() prepares the clock when an external control pin is configured. The current driver only drops that prepare reference when external control configuration fails. If provider registration fails after that point, or if the driver is later removed, the prepare reference remains held. Register a device-managed action after clk_prepare() succeeds. This balances the prepare reference on subsequent probe failure and driver removal. Fixes: 942d1d674931 ("clk: Add driver for Palmas clk32kg and clk32kgaudio clocks") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 46226841ffb6123e9d00de54dd10a6c555baba3a Author: Guangshuo Li Date: Wed Jul 8 19:20:58 2026 +0800 clk: tegra: tegra124-emc: put EMC node on register failure [ Upstream commit f726279f5eab813f9a8b6f38ddf2a4b062d038ff ] tegra124_clk_register_emc() stores a device node reference returned by of_parse_phandle() in tegra->emc_node. If clk_register() fails, the function returns an error before that reference can be consumed and released by the normal runtime path. The tegra_clk_emc object is freed on this failure path, but freeing the object does not drop the OF node reference stored in it. Drop the EMC node reference before freeing the tegra_clk_emc object. of_node_put() is safe for a NULL node, so this also covers the case where the phandle is absent. Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Signed-off-by: Guangshuo Li Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 5e5029745bac488f3bfc92f0484f55e05ede3147 Author: Ondrej Jirman Date: Sat Jul 25 13:19:07 2026 +0200 arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix [ Upstream commit dfc735fd93e4814e65894916ec5f807f25a391d1 ] The current mount matrix for mpu6050 is wrong. The mount matrix is a simple transform from the sensor coordinate space to the device coordinate space described in DT, where, looking at the screen, X points to the right, Y to the top, and Z towards the user. The mpu6050 is mounted like this (looking at the screen from the front; the sensor is on the near side of the PCB, so its Z axis points towards the user; o marks the pin 1 corner): +Xs ^ | +------+ +Ys <--| | | o | +------+ so this gives: Xd = -Ys [0, -1, 0] Yd = Xs [1, 0, 0] Zd = Zs [0, 0, 1] Fixes: 2496b2aaacf1 ("arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer") Signed-off-by: Ondrej Jirman Link: https://patch.msgid.link/20260725111909.2244868-1-megi@xff.cz Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 665cd418b8561a099c3854443f8ad8ae751b72a0 Author: Yonatan Nachum Date: Mon Jul 27 09:02:55 2026 +0000 RDMA/efa: Fix PBL chunk length computation [ Upstream commit 229b42d7450c1cf96f45ec39ebb69211b06bc036 ] On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Reviewed-by: Firas Jahjah Reviewed-by: Michael Margolin Signed-off-by: Yonatan Nachum Link: https://patch.msgid.link/20260727090255.1175120-1-ynachum@amazon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b6bf3ab9661ec40f797dc111b37797b4f50fffaf Author: Ivy Lopez Date: Fri Jul 17 16:01:35 2026 -0600 staging: rtl8723bs: use kfree_sensitive() for key material [ Upstream commit d205dfa8cb825f1954ca1cfa474fc50bf06ee4aa ] The set_stakey_parm struct contains a 16-byte encryption key. Use kfree_sensitive() instead of kfree() to ensure the key material is zeroed before the memory is freed, preventing potential information leaks. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Ivy Lopez Link: https://patch.msgid.link/20260717220135.17836-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 50f232c26298923d39a48dc8e03d1732e5a5dcf1 Author: Bjorn Andersson Date: Thu Jul 23 03:52:28 2026 +0000 remoteproc: Prevent crash handling to race with rproc_del() [ Upstream commit 74ee3b2f5767447c57959994341e5b95f1079977 ] There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a "deleting" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that "start" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the "state" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case. Assisted-by: OpenCode:GPT-5.5 Fixes: 8afd519c3470 ("remoteproc: add rproc_report_crash function to notify rproc crashes") Signed-off-by: Bjorn Andersson Reviewed-by: Pradnya Dahiwale Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-2-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 48f8f9ae2bec3459dbad3b418a9db5048ea8be0d Author: Jingyi Wang Date: Tue Jun 23 02:05:34 2026 -0700 remoteproc: core: Attach rproc asynchronously in rproc_add() path via schedule_work() [ Upstream commit 026a3fada43261e403c6c4d9bda9501547e3f108 ] Unlike the remoteproc firmware load path where rproc_add() call rproc_auto_boot_callback() asynchronously and ignores the return value of rproc_boot(), the attach path calls rproc_boot() synchronously and propagates its return value back to rproc_add(). This means a failure during rproc_attach() causes rproc_add() to fail and triggers resource release, removing the remoteproc from sysfs and making it unavailable for recovery or further boot attempts. Align the remoteproc attach path with the firmware load path by introducing attach_work and scheduling rproc_boot() asynchronously via schedule_work(). This keeps the remoteproc registered and available in sysfs even if the initial attach attempt fails, and avoids blocking rproc_add() on the attach result. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-1-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit ebc9eb896e9b9528d6cf23ca0af09204e4795881 Author: Mukesh Ojha Date: Tue Apr 19 16:55:54 2022 +0530 remoteproc: Use unbounded workqueue for recovery work [ Upstream commit cab8300b5621a54aa25306ff800c27fa5a4632d7 ] There could be a scenario when there is too much load on a core (n number of tasks which is affined) or in a case when multiple rproc subsystem is going for recovery, they queue their recovery work to one core so even though subsystem are independent their recovery will be delayed if one of the subsystem recovery work is taking more time in completing. If we make this queue unbounded, the recovery work could be picked on any cpu. This patch is trying to address this. Signed-off-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1650367554-15510-1-git-send-email-quic_mojha@quicinc.com Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit a51424c19bbed6d60afc57f95f8c32e45d02ab27 Author: Alex Elder Date: Wed May 19 18:44:18 2021 -0500 remoteproc: use freezable workqueue for crash notifications [ Upstream commit 3ad51c1743ebd23ec3b5ebc6195dafe867eaebb1 ] When a remoteproc has crashed, rproc_report_crash() is called to handle whatever recovery is desired. This can happen at almost any time, often triggered by an interrupt, though it can also be initiated by a write to debugfs file remoteproc/remoteproc*/crash. When a crash is reported, the crash handler worker is scheduled to run (rproc_crash_handler_work()). One thing that worker does is call rproc_trigger_recovery(), which calls rproc_stop(). That calls the ->stop method for any remoteproc subdevices before making the remote processor go offline. The Q6V5 modem remoteproc driver implements an SSR subdevice that notifies registered drivers when the modem changes operational state (prepare, started, stop/crash, unprepared). The IPA driver registers to receive these notifications. With that as context, I'll now describe the problem. There was a situation in which buggy modem firmware led to a modem crash very soon after system (AP) resume had begun. The crash caused a remoteproc SSR crash notification to be sent to the IPA driver. The problem was that, although system resume had begun, it had not yet completed, and the IPA driver was still in a suspended state. This scenario could happen to any driver that registers for these SSR notifications, because they are delivered without knowledge of the (suspend) state of registered recipient drivers. This patch offers a simple fix for this, by having the crash handling worker function run on the system freezable workqueue. This workqueue does not operate if user space is frozen (for suspend). As a result, the SSR subdevice only delivers its crash notification when the system is fully operational (i.e., neither suspended nor in suspend/resume transition). Tested-by: Siddharth Gupta Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20210519234418.1196387-2-elder@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit 77d276d987f9552111198670f0499558b4ebeb55 Author: Mathieu Poirier Date: Fri Mar 12 09:24:39 2021 -0700 remoteproc: Add new RPROC_ATTACHED state [ Upstream commit 4196d18903f94090f0a223d65de25e3bf50a3d13 ] Add a new RPROC_ATTACHED state to take into account scenarios where the remoteproc core needs to attach to a remote processor that is booted by another entity. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-4-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit 2e4e0798300c5dac2c61e23a1fef904e8875891f Author: Mathieu Poirier Date: Fri Mar 12 09:24:37 2021 -0700 remoteproc: Remove useless check in rproc_del() [ Upstream commit 16324fc8def1c08a92261089aaf503aca3381aa6 ] Whether started at probe() time or thereafter from the command line, a remote processor needs to be shut down before the final cleanup phases can happen. Otherwise the system may be left in an unpredictable state where the remote processor is expecting the remoteproc core to be providing services when in fact it no longer exist. Invariably calling rproc_shutdown() is fine since it will return immediately if the remote processor has already been switched off. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-2-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit fb897b8b9f869c1875edeb02375e78604d8555d6 Author: Babanpreet Singh Date: Tue Jul 14 04:10:10 2026 +0000 w1: ds2482: Fix signedness bug in ds2482_w1_triplet() [ Upstream commit 4d3721b204f961e905714954ff95633337b768e3 ] ds2482_wait_1wire_idle() returns the status register value (0..255) on success, or a negative value on I2C failure: -1 when selecting the status register fails, or a negative errno from i2c_smbus_read_byte(). ds2482_w1_triplet() feeds that result into "return (status >> 5);" without checking for errors, and the function returns u8. For a negative status the arithmetic shift keeps the sign and the u8 truncation fabricates a triplet result whose meaning depends on the errno value: -1 and -EIO happen to become 0xff, whose set low bits make w1_search() abort, but -ETIMEDOUT (-110 >> 5 = -4) becomes 0xfc - "devices responded on both branches, wrote 1" - and -EOPNOTSUPP (-95 >> 5 = -3) becomes 0xfd - "only the zero branch responded". w1_search() then continues the ROM search with a fabricated direction bit instead of aborting, and the corrupted id is either rejected by the ROM CRC (existing device missed) or registers a phantom slave. The function already defines an in-band error value: status is initialized to (3 << 5), which decodes to 3 (both branch bits set, "no device responded") and makes w1_search() terminate the search when sending the triplet command fails. Decode a negative status to the same value. Found by smatch: drivers/w1/masters/ds2482.c:314 ds2482_w1_triplet() warn: signedness bug returning '(-67108864)' Fixes: baf12ae29ab4 ("[PATCH] W1: Add the DS2482 I2C-to-w1 bridge driver.") Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260714041011.7-1-bbnpreetsingh@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit dbcc7d1b818162aeab2e97fd217d86546d9fde15 Author: Yichong Chen Date: Tue Jul 21 17:11:52 2026 +0800 isofs: release zisofs block pointer buffer head [ Upstream commit 2f7dd9b86fe4076059e6a4a2a2c5d565afd76b9e ] zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success. Fixes: 59bc055211b8 ("zisofs: Implement reading of compressed files when PAGE_CACHE_SIZE > compress block size") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260721091152.1450622-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit ccce6b7ef1d7efc59ccba3421e1339c6e63a3d20 Author: Maher Sanalla Date: Thu Jul 23 18:23:49 2026 +0300 RDMA/mlx5: Fix integer overflow of user QP buffer size [ Upstream commit dec47e4b0fe34afdf38caa72b4408ba95502e5de ] set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Maher Sanalla Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260723-fix-qp-buf-size-overflow-v1-1-ccb05ee43a7b@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2a8c9f7d70cac83cfa96c56ab8c0d0781af2b223 Author: Babanpreet Singh Date: Sun Jul 26 07:22:05 2026 +0000 power: supply: sbs-battery: Use a per-device serial number buffer [ Upstream commit 6027892925b8d19d2245c2d077e2ae35b49cc2b1 ] sbs_get_battery_serial_number() formats the battery serial number into sbs_serial[], a single file-scope buffer shared by every sbs-battery instance, and points val->strval at it. Nothing restricts this driver to one instance. It binds per I2C client, and sbs-manager registers one muxed I2C channel per supported battery specifically so that the smart battery driver can be bound to each of them, so several sbs-battery instances on one system is a supported configuration. The power supply core reads strval after the driver's get_property() callback has returned: power_supply_show_property() fills a local union power_supply_propval, then formats it with sysfs_emit(). Two concurrent POWER_SUPPLY_PROP_SERIAL_NUMBER reads on different batteries therefore race for the shared buffer - battery B's sprintf() can land between battery A filling the buffer and the core reading it, and battery A then reports battery B's serial number. Move the buffer into struct sbs_info so that each battery formats into its own storage. It is deliberately not added to the chip->strings[] array: those entries hold the cached constant strings that sbs_invalidate_cached_props() clears on presence changes, whereas the serial number is re-read from its word register on every access. Fixes: d3ab61ecbab2 ("bq20z75: Add support for more power supply properties") Assisted-by: Claude:claude-opus-5 Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260726072206.7-2-bbnpreetsingh@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ff015335457be1e7ac3b7726533b401da3adcbfc Author: Ikjoon Jang Date: Wed May 26 19:16:04 2021 +0800 power: supply: sbs-battery: cache constant string properties [ Upstream commit b49a81d0fd021a1f0c8660fa40ad9984d9d1f5b7 ] Currently sbs-battery supports three string properties - manufacturer, model_name, and chemistry. Buffers for those properties are currently defined as global variables. This patch moves those global variables into struct sbs_info and cache/reuse them as they are all constant values. Signed-off-by: Ikjoon Jang Tested-by: Hsin-Yi Wang Signed-off-by: Sebastian Reichel Stable-dep-of: 6027892925b8 ("power: supply: sbs-battery: Use a per-device serial number buffer") Signed-off-by: Sasha Levin commit 28ebe062adc9967c42edcb2142d6f9c20195c1a3 Author: Karl Mehltretter Date: Mon Jul 13 21:25:06 2026 +0200 ARM: lpc32xx: only run SoC init on LPC32xx hardware [ Upstream commit 717ea4000867e6dffee5e1ed92150a9704ae9f68 ] lpc32xx_check_uid() and lpc32xx_pm_init() are arch_initcalls that poke LPC32xx-only registers. Since the multiplatform conversion they also run on other ARCH_MULTI_V5 boards where access faults e.g. on versatile: Unable to handle kernel paging request at virtual address f4004130 PC is at lpc32xx_check_uid+0x2c/0x9c Drop the arch_initcall() registrations and call both functions directly from lpc3250_machine_init(), the machine's .init_machine hook. The calls are placed in link order (common.c, pm.c, phy3250.c) to keep their previous relative ordering. Fixes: 75bf1bd7d2f9 ("ARM: lpc32xx: allow multiplatform build") Suggested-by: Arnd Bergmann Signed-off-by: Karl Mehltretter Reviewed-by: Vladimir Zapolskiy Reviewed-by: Arnd Bergmann Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit d7fd799a087d4cf0d48ad41128d20e5eef9fddba Author: Fabio Estevam Date: Tue Jul 21 10:34:45 2026 -0300 arm64: dts: rockchip: Fix Gru WLAN sideband interrupt [ Upstream commit a761818d9ee11183df0aefd16bf9fe46cc1c4c6d ] The Marvell WLAN host wake interrupt is wired to GPIO0 8 and is not one of the PCI INTx interrupts. The PCI device schema therefore interprets the two-cell GPIO interrupt specifier as an invalid PCI interrupt and reports dtbs_check warnings: pcie@0,0: wifi@0,0:interrupts:0:0: 8 is not one of [1, 2, 3, 4] pcie@0,0: wifi@0,0:interrupts:0: [8, 8] is too long Describe the sideband interrupt with interrupts-extended, which explicitly carries the interrupt controller and removes the ambiguity. Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260721133445.44283-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 43d5bcde21ddd7bde8780aaf314f7dd3eae5aa32 Author: Rob Herring Date: Thu Nov 30 13:18:29 2023 -0600 arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru [ Upstream commit c13c823a78b77ea0e5f1f73112d910e259911101 ] The rk3399-gru PCI node addresses are wrong. In rk3399-gru-scarlet, the bus number in the address should be 0. This is because bus number assignment is dynamic and not known up front. For FDT, the bus number is simply ignored. In rk3399-gru-chromebook, the addresses are simply invalid. The first "reg" entry must be the configuration space for the device. The entry should be all 0s except for device/slot and function numbers. The existing 64-bit memory space (0x83000000) entries are not valid because they must have the BAR address in the lower byte of the first cell. Warnings for these are enabled by adding the missing 'device_type = "pci"' for the root port node. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh@kernel.org Signed-off-by: Heiko Stuebner Stable-dep-of: a761818d9ee1 ("arm64: dts: rockchip: Fix Gru WLAN sideband interrupt") Signed-off-by: Sasha Levin commit 0c94767335c0046b36745c048088571d12e84de6 Author: Chen-Yu Tsai Date: Thu Aug 12 17:47:53 2021 +0800 arm64: dts: rockchip: Add gru-scarlet-dumo board [ Upstream commit 5707e34166f546bf1fcdfd3da600e8187d04d937 ] Dumo is another variant of Scarlet, also known as the ASUS Chromebook Tablet CT100. This is almost the same as Scarlet-Innolux, but uses a board-specific calibration variant for the WiFi module. Add a new device tree for it. Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210812094753.2359087-3-wenst@chromium.org Signed-off-by: Heiko Stuebner Stable-dep-of: a761818d9ee1 ("arm64: dts: rockchip: Fix Gru WLAN sideband interrupt") Signed-off-by: Sasha Levin commit 6828aca3d82717c2fda92af81c0dda642bc2b465 Author: Florian Westphal Date: Mon Jul 6 14:30:55 2026 +0200 netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet [ Upstream commit 16aecbe3036f6097c26b51b12e4c1cf207769690 ] sashiko says: If map_addr() changes the packet length, such as when the public NAT IP string is shorter or longer than the internal IP, coff will still point to the offset relative to the pre-mangled packet. If the packet shrinks, coff could overshoot the correct position, potentially causing the next ct_sip_parse_header_uri() call to silently skip bytes and miss subsequent Contact headers. Could this lead to a failure to NAT those subsequent headers and leak internal network details? Fixes: c978cd3a9371 ("[NETFILTER]: nf_nat_sip: translate all Contact headers") Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3b787c73a92d69aaf441fed29f79199140931302 Author: Can Peng Date: Wed Jul 15 10:41:30 2026 +0800 drm/tve200: add OF module alias for autoloading [ Upstream commit b6c3585f2058e0fbfa8cb403458f5cc6cf5c5e06 ] The TVE200 DRM driver can be built as a module and uses tve200_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Can Peng Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn Signed-off-by: Sasha Levin commit 2ec59564313b7c68e7afb688aecdd544dcad3b46 Author: Cosmo Chou Date: Wed Jul 15 16:07:47 2026 +0800 leds: pca9532: Fix phantom device registration on missing hardware [ Upstream commit 8d6b6c05b8e33d11e3fb3203309385e1a9cceecd ] The initial PWM and PSC register writes in pca9532_configure() do not check the return values of i2c_smbus_write_byte_data(). If the I2C device is physically absent from the bus, the write fails with -ENXIO. However, the driver ignores this error and allows probe() to complete successfully. This results in the registration of phantom LED class devices and gpiochips backed by non-existent hardware. Subsequent GPIO reads from these phantom chips return bogus values (due to -ENXIO being truncated to an unsigned char in pca9532_gpio_get_value()), silently corrupting hardware state tracking in userspace. Propagate the I2C write failures back to probe() so the driver core can gracefully abort binding and release devres-managed resources. Fixes: e14fa82439d3 ("leds: Add pca9532 led driver") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260715080747.1638097-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 23893444447675e4e0701e24eb31163c8540438d Author: Leo Yan Date: Mon Jul 20 11:01:21 2026 +0100 perf cs-etm: Avoid truncating AUX buffer sizes to int [ Upstream commit ec99be8a31db999a4f866be74ea7db61dbb19f24 ] cs_etm__get_trace() returns an int, but it used to return etmq->buf_len on success. That value comes from auxtrace_buffer::size, which is a size_t. For a large AUX trace block, returning the byte count through an int can overflow and make a valid buffer look like a negative error. The callers do not need the actual byte count from cs_etm__get_trace(). The buffer length is already stored in the etmq->buf_len. The callers only need to distinguish three states: < 0: error = 0: no more AUX buffers > 0: data is available Make cs_etm__get_trace() return 0 for all non-error cases and use etmq->buf_len to indicate whether a new buffer was found. Then make cs_etm__get_data_block() return 1 whenever data is available, instead of returning the buffer length. Also refactor cs_etm__get_data_block() to make its return value semantics clearer. Reported-by: Suyash Mahar Fixes: 8224531cf5a1 ("perf cs-etm: Modularize auxtrace_buffer fetch function") Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e7e168699270235880344e3a0c9b8ce5c947ff3a Author: Leo Yan Date: Thu Jul 2 20:51:41 2026 +0100 perf cs-etm: Flush thread stacks after decoder reset [ Upstream commit ea5075e3776846d4941dddf1549426ebd3feb81f ] Perf resets the CoreSight decoder when moving to a new AUX trace buffer, this causes trace discontinunity globally. For callchain synthesis, keeping thread-stack state after decoder reset can leave stale call/return history attached to threads that are decoded later, producing incorrect synthesized callchains. Flush all host thread stacks after a decoder reset. When virtualization is present, flush the guest thread stacks as well. Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Stable-dep-of: ec99be8a31db ("perf cs-etm: Avoid truncating AUX buffer sizes to int") Signed-off-by: Sasha Levin commit 045eb7d43c0ca108aa9b812c0e551c9e65c425be Author: Andre Przywara Date: Mon Jul 20 23:51:28 2026 +0200 ARM: dts: allwinner: a10: Fix PMU interrupt [ Upstream commit eb7051f756460d7b951e94d9656e31ebb631ba28 ] The Performance Monitoring Unit of the Cortex-A8 cores in the Allwinner A10 SoC is connected to interrupt line 66, not 3. This is shown in the manual (where interrupt 3 is assigned to UART2, also in our .dtsi), but has also been confirmed by triggering an PMU overflow interrupt and inspecting the IRQ controller status registers (from U-Boot). Please note that "perf stat" does not use interrupts, this might explain why this evaded the initial testing. Fixes: 7e345d25c796 ("ARM: dts: sun4i-a10: Add PMU node") Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20260720215128.5761-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 20166fd9a4ad15d7eccc63c9dc99680aea6558ef Author: Jeff Johnson Date: Thu Jul 16 13:01:31 2026 -0700 wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() [ Upstream commit 9ef9dd30058cc9223c72f711dca1a28a5947d0c5 ] Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260716-ath11k_wmi_tlv_op_rx-overread-v1-1-0b972b3f1368@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0c17389297f2ac6274be27a6beacee1b833057a8 Author: Venkateswara Naralasetty Date: Tue Nov 9 12:05:55 2021 +0530 ath11k: add trace log support [ Upstream commit fb12305aff12e735e599c79514dde5dac40f5a59 ] This change is to add trace log support for, * WMI events * WMI commands * ath11k_dbg messages * ath11k_dbg_dump messages * ath11k_log_info messages * ath11k_log_warn messages * ath11k_log_err messages Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00652-QCAHKSWPL_SILICONZ-1 Signed-off-by: Venkateswara Naralasetty Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1636439755-30419-1-git-send-email-quic_vnaralas@quicinc.com Stable-dep-of: 9ef9dd30058c ("wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()") Signed-off-by: Sasha Levin commit bf9126c2f77b2d5bdcecc34850fae690df303dd3 Author: Jeff Johnson Date: Mon Jul 13 09:15:50 2026 -0700 wifi: ath11k: Correctly copy the hint BSSID in WMI scan request [ Upstream commit 6fe2dddf59bbb2a96be0fcf23a205807b25ac173 ] Currently, in ath11k_wmi_send_scan_start_cmd(), the logic to populate the hint_bssid copies the BSSID in the wrong direction, from the firmware message to the argument buffer. Swap the parameters so that the BSSID is correctly populated in the firmware message from the argument buffer. This issue was reported on ath12k, but exists in ath11k as well. Compile tested only. Reported-by: Baochen Qiang Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/ Fixes: 74601ecfef6e ("ath11k: Add support for 6g scan hint") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-2-4ffc4a472992@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 144fe0b0fa8f311ebe29ef16c8239bf6a24addc0 Author: Jeff Johnson Date: Sat Jul 11 11:04:43 2026 -0700 wifi: ath6kl: avoid buffer overreads in WMI event handlers [ Upstream commit f57314aade9d74d30f3360ec5ef85a83654748be ] The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260711-ath6kl_wmi_scan_complete_rx-v2-1-22dc0f7f45e7@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit fd7e0dab20837b9ea1eeef7c26f78ace8ac8258c Author: Baokun Li Date: Mon Jun 29 19:38:23 2026 +0800 ext4: drain in-flight DIO before buffered write fallback [ Upstream commit 15cdefd0c0522f9d5e12d947fa04f4c11649b699 ] generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race. Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Suggested-by: Zhang Yi Link: https://patch.msgid.link/d1adcf7c-c276-458d-9cac-68a4410f7626@gmail.com Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Baokun Li Link: https://patch.msgid.link/20260629113827.4074335-3-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 5798c714fccf1b4939a98a812b9073da365172c8 Author: Pengpeng Hou Date: Tue Jun 23 09:51:40 2026 +0800 thermal: intel: int3400: clean up ODVP on probe failures [ Upstream commit d83dc9ce57a746a6dca28439bcc0575d26fa6986 ] evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues. Fixes: 006f006f1e5c ("thermal/int340x_thermal: Export OEM vendor variables") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015140.19300-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 65c1d69718d72279cdf7d96eb780e4e7ce664fe7 Author: Rafael J. Wysocki Date: Tue Aug 30 20:33:37 2022 +0200 thermal: int340x_thermal: Consolidate priv->data_vault checks [ Upstream commit e9a7c526c29b0ae60c888b335bd6cf6e2ee80154 ] It is sufficient to check priv->data_vault once in the error code path of int3400_thermal_probe(), so do that. Signed-off-by: Rafael J. Wysocki Stable-dep-of: d83dc9ce57a7 ("thermal: intel: int3400: clean up ODVP on probe failures") Signed-off-by: Sasha Levin commit 5b0df5684b5fe1a154f2ecf798d95962cf919f2e Author: Mukesh Ojha Date: Fri Jul 17 20:16:03 2026 +0530 iommu/qcom: Fix inverted fault report check in qcom_iommu_fault() [ Upstream commit 1f33b8208a1978b0c0d6ad60a47fe4bb7a235e58 ] report_iommu_fault() returns 0 when a fault handler successfully handles the fault, and -ENOSYS when no handler is installed. The condition '!report_iommu_fault()' evaluates to true (printing "Unhandled context fault") precisely when the fault *was* handled, and stays silent when no handler is present — the opposite of what is intended. Remove the '!' so the driver logs unhandled faults correctly. Fixes: 049541e178d5 ("iommu: qcom: wire up fault handler") Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 674acf84798ca6fd24f54db33c7025c4b76848bc Author: Haoxiang Li Date: Tue Jun 23 15:12:45 2026 +0800 iommu/qcom: Remove sysfs device on probe failure path [ Upstream commit c579f18e79599c16168925cb149e1db3f29eea5f ] In qcom_iommu_device_probe(), if iommu_device_register() fails, the sysfs device created by iommu_device_sysfs_add() is not released. Add a goto label to do the cleanup. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: Haoxiang Li Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a364c9e90765aca9e070d751a82070fbee76909f Author: Miaoqian Lin Date: Wed Jan 5 10:16:19 2022 +0000 iommu/arm-smmu: Add missing pm_runtime_disable() in qcom_iommu_device_probe [ Upstream commit 93665e0275a2e2badfcfca5ada3b78b22df4a01a ] If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Add missing pm_runtime_disable() for error handling. Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220105101619.29108-1-linmq006@gmail.com Signed-off-by: Will Deacon Stable-dep-of: c579f18e7959 ("iommu/qcom: Remove sysfs device on probe failure path") Signed-off-by: Sasha Levin commit bb1e228ab16619b1fb78505c713cce7557711818 Author: Kalesh AP Date: Thu Nov 13 16:24:57 2025 +0530 RDMA/restrack: Fix typos in the comments [ Upstream commit d43358cda7c4696e08880aaa58a7df82e471fa7c ] Fix couple of occurrences of the misspelled word "reource" in the comments with the correct spelling "resource". Signed-off-by: Kalesh AP Link: https://patch.msgid.link/20251113105457.879903-1-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky Stable-dep-of: 3481bec4dfc4 ("RDMA/core: Fix potential use after free in ib_destroy_cq_user()") Signed-off-by: Sasha Levin commit 24a92555d8eb0123fe2d3110dc70d094fb1cd91a Author: Leon Romanovsky Date: Tue Jul 21 12:10:56 2026 +0300 RDMA/srpt: Pass the mapped task attribute to target_init_cmd() [ Upstream commit ef63cc441703412628a517dda354f3e51fe2dc92 ] srpt_handle_cmd() maps the initiator-supplied srp_cmd->task_attr into cmd->sam_task_attr, but then hands a hardcoded TCM_SIMPLE_TAG to target_init_cmd(). Pass the already mapped cmd->sam_task_attr instead, so target core sees the attribute the initiator requested. Fixes: 9474b043132f ("ib_srpt: Convert I/O path to target_submit_cmd + drop legacy ioctx->kref") Link: https://patch.msgid.link/20260721-b4-scsi-ordering-violation-due-to-hardc-v1-1-07205aab71bb@nvidia.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 02adbba88261d6225b8326179da7cf1810ba6e1d Author: Mike Christie Date: Sat Feb 27 10:59:46 2021 -0600 scsi: target: srpt: Convert to new submission API [ Upstream commit 50ab9c47f51dbe3419e414ac6880273f58ac2849 ] target_submit_cmd_map_sgls() is being removed, so convert srpt to the new submission API. srpt uses target_stop_session() to sync session shutdown with LIO core, so we use target_init_cmd()/target_submit_prep()/target_submit(), because target_init_cmd() will detect the target_stop_session() call and return an error. Link: https://lore.kernel.org/r/20210227170006.5077-6-michael.christie@oracle.com Cc: Bart Van Assche Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 1a5b177529dfff020f4e8a75a7897f294cae46e4 Author: Mike Christie Date: Sat Feb 27 10:59:45 2021 -0600 scsi: target: core: Break up target_submit_cmd_map_sgls() [ Upstream commit 750a1d93f90583a270eb62f36e6d32ebbb6af779 ] This breaks up target_submit_cmd_map_sgls() into 3 helpers: - target_init_cmd(): Do the basic general setup and get a refcount to the session to make sure the caller can execute the cmd. - target_submit_prep(): Do the mapping, cdb processing and get a ref to the LUN. - target_submit(): Pass the cmd to LIO core for execution. The above functions must be used by drivers that either: 1. Rely on LIO for session shutdown synchronization by calling target_stop_session(). 2. Need to map sgls. When the next patches are applied then simple drivers that do not need the extra functionality above can use target_submit_cmd() and not worry about failures being returned and how to handle them, since many drivers were getting this wrong and would have hit refcount bugs. Also, by breaking target_submit_cmd_map_sgls() up into these 3 helper functions, we can allow the later patches to do the init/prep from interrupt context and then do the submission from a workqueue. Link: https://lore.kernel.org/r/20210227170006.5077-5-michael.christie@oracle.com Cc: Bart Van Assche Cc: Juergen Gross Cc: Hannes Reinecke Cc: Nilesh Javali Cc: Michael Cyr Cc: Chris Boot Cc: Felipe Balbi Cc: "Michael S. Tsirkin" Cc: Stefan Hajnoczi Tested-by: Laurence Oberman Reviewed-by: Christoph Hellwig Reviewed-by: Himanshu Madhani Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 39aea695793eef0cbc5c956fb7f56718f85a4013 Author: Mike Christie Date: Sat Feb 27 10:59:44 2021 -0600 scsi: target: core: Rename transport_init_se_cmd() [ Upstream commit a78b713618c02752310b2be7da465a34fb660ed9 ] Rename transport_init_se_cmd() to __target_init_cmd() to reflect that it is more of an internal function that drivers should normally not use and because we are going to add a new init function in the next patches. Link: https://lore.kernel.org/r/20210227170006.5077-4-michael.christie@oracle.com Reviewed-by: Christoph Hellwig Reviewed-by: Himanshu Madhani Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit f1581c71f5ae4c6b3c2c42a5e633c7803d3ec7c8 Author: Sebastian Andrzej Siewior Date: Sun Dec 20 21:36:37 2020 +0100 scsi: target: core: Replace in_interrupt() usage in target_submit_cmd_map_sgls() [ Upstream commit 513e29946ab22f66cd14670024f6c98b5b913462 ] target_submit_cmd_map_sgls() uses in_interrupt() to crash if it returns true. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. The usage of in_interrupt() is clearly for debugging. might_sleep() is better at this because it also detects other contexts in which it is not allowed to sleep, like preempt-disabled section. Replace BUG_ON(in_interrupt) with might_sleep(). Link: https://lore.kernel.org/r/20201220203638.43615-6-bigeasy@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 7b9893fa53513e1e305b2459b02edd44a4965dd7 Author: Mike Christie Date: Sun Nov 1 12:59:31 2020 -0600 scsi: qla2xxx: Move sess cmd list/lock to driver [ Upstream commit 605e74025f953b995a3a241ead43bde71c1c99b5 ] Except for debug output in the shutdown path, tcm_qla2xxx is the only driver using the se_session sess_cmd_list. Move the list to that driver to facilitate removing the sess_cmd_lock from the main I/O path for the rest of the drivers. Link: https://lore.kernel.org/r/1604257174-4524-6-git-send-email-michael.christie@oracle.com Cc: Nilesh Javali Reviewed-by: Himanshu Madhani Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 5f4caa421e05749f0ced22aee7a3a863fd93d7bf Author: Mike Christie Date: Sun Nov 1 12:59:30 2020 -0600 scsi: target: Remove TARGET_SCF_LOOKUP_LUN_FROM_TAG [ Upstream commit 27b0efd15d5247ada0c2ed9cbc77fd3fb3b1f26d ] TARGET_SCF_LOOKUP_LUN_FROM_TAG is no longer used so remove it. Link: https://lore.kernel.org/r/1604257174-4524-5-git-send-email-michael.christie@oracle.com Reviewed-by: Himanshu Madhani Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 1c5bf7c529d95755f32b8ef449d10df2d50aaf5a Author: Mike Christie Date: Sun Nov 1 12:59:29 2020 -0600 scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG [ Upstream commit 8f394da36a361cbe0e1e8b1d4213e5598c8095ac ] Only the __qlt_24xx_handle_abts() code path does not know the LUN for an abort and it uses the TARGET_SCF_LOOKUP_LUN_FROM_TAG flag to have LIO core look it up. LIO uses target_lookup_lun_from_tag to go from cmd tag to LUN for the driver. However, qla2xxx has a tcm_qla2xxx_find_cmd_by_tag() which does almost the same thing as the LIO helper (it finds the cmd but does not return the LUN). This patch has qla2xxx use its internal helper. Link: https://lore.kernel.org/r/1604257174-4524-4-git-send-email-michael.christie@oracle.com Cc: Nilesh Javali Reviewed-by: Himanshu Madhani Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: ef63cc441703 ("RDMA/srpt: Pass the mapped task attribute to target_init_cmd()") Signed-off-by: Sasha Levin commit 41897f1bcf4ace5f1f28d0be784b6f4f0e929641 Author: Yun Zhou Date: Tue Jun 23 14:19:02 2026 +0800 ext4: skip extra isize expansion during mount to prevent deadlock [ Upstream commit 7461c60b9c6a839b13ad4c3490681a0cf5aa0637 ] ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed. Reported-by: syzbot+5d19358d7eb30ffb0cc5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5d19358d7eb30ffb0cc5 Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260623061903.2148767-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 321bb0eb1486a0d575f02e24e3f4170e408c2f51 Author: Chen Pei Date: Wed Jul 15 21:50:48 2026 +0800 ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root [ Upstream commit 8a742141f7ab84975aa758b775567ef4740ef0cf ] acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed. Fixes: db89b4f0dbab ("ACPI: catch calls of acpi_driver_data on pointer of wrong type") Reported-by: Sashiko AI review Link: https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com Link: https://sashiko.dev/#/patchset/20260707121258.11640-1-cp0613@linux.alibaba.com Signed-off-by: Chen Pei Link: https://patch.msgid.link/20260715135048.3278-1-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5601bd81bc290a724ed47797d22c16cba4d7ed9f Author: Pengpeng Hou Date: Wed Jul 15 16:32:53 2026 +0800 ACPI: processor: validate MADT IOAPIC entry bounds [ Upstream commit 2c50ffdc73f3a70d745d249f509fc290754121e6 ] The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths. Fixes: ecf5636dcd59 ("ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715083253.22831-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 82bccf7f9a12bf0eec9774968f6a853020ea26d3 Author: Kemeng Shi Date: Tue Jul 21 14:32:40 2026 +0800 irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() [ Upstream commit 325ff3e78c64cd619d52b99f7c8b09a3f31e1495 ] When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260721063241.52549-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit af00051dbc9f467d4840ec709680660a3f8990fa Author: TanZheng Date: Wed Jul 15 18:15:50 2026 +0800 RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters [ Upstream commit b38f98e176050850f41bb6415f3a71400056623e ] When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error. Fixes: b99f8e4d7bcd ("IB/srpt: convert to the generic RDMA READ/WRITE API") Signed-off-by: TanZheng Link: https://patch.msgid.link/20260715101550.45345-1-kensanya@163.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cb73c2fe6e9cf563c99f22b7c8bca0d5f70d603e Author: Danila Chernetsov Date: Wed Jul 8 16:22:52 2026 +0000 RDMA/hfi1: Propagate sdma_txinit_ahg() errors [ Upstream commit 091c6162c022cbdfb64219708a71728cfd1d4600 ] set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e3304b7cc4f1 ("IB/hfi1: Optimize cachelines for user SDMA request structure") Signed-off-by: Danila Chernetsov Link: https://patch.msgid.link/20260708162252.936634-1-listdansp@mail.ru Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit de33afc57f24538186bccf4c4f6c65dd38634fd8 Author: Linmao Li Date: Fri Jul 17 09:24:33 2026 +0800 ASoC: meson: Keep link pointers valid on realloc failure [ Upstream commit 2aaa41cf974f83a6fb105422bac4e2f107150774 ] meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Signed-off-by: Linmao Li Reviewed-by: Jerome Brunet Link: https://patch.msgid.link/20260717012433.1432285-1-lilinmao@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 91cb09421807340d86fdf4aa07e8f02587946888 Author: Koichiro Den Date: Sat Jul 18 03:06:36 2026 +0900 dmaengine: dw-edma: Clear stale requests on termination [ Upstream commit c0d9c6275adcca7c0ca5f4270bf88026f9864bd1 ] terminate_all() can finish immediately when the channel is unconfigured, paused, idle, or already stopped in hardware. A pending PAUSE request can survive these paths and block issue_pending() even after termination. Clear the request whenever termination leaves the channel idle. A running channel keeps its STOP request until the interrupt handler consumes it. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-7-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit be0072af8ce6e9458cc586e0e8b41a251e7d4316 Author: Koichiro Den Date: Sat Jul 18 03:06:35 2026 +0900 dmaengine: dw-edma: Serialize channel state checks [ Upstream commit f7d1619f3e10c619b62c6cd6d95371b5c526c85a ] pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-6-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4a72f81b8681b2ad7705cf039974c443dcc8ff00 Author: Koichiro Den Date: Sat Jul 18 03:06:33 2026 +0900 dmaengine: dw-edma: Serialize abort state updates [ Upstream commit dd80e259f65d932634e26d366570d71669ef6654 ] dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-4-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 497c075172e2067c7b63ea65cef8f8cbcb416c56 Author: Yuho Choi Date: Mon Jun 15 14:07:46 2026 -0400 driver core: soc: Unregister bus on early device registration failure [ Upstream commit 45dfa004893dfeae182ec27eddbd153c6d4ddbf9 ] soc_bus_register() registers the SoC bus before registering a deferred early SoC device. If soc_device_register() fails in that path, the function returns the error directly and leaves the bus registered. Store the returned SoC device pointer explicitly so the success and error cases are handled separately. On failure, clear soc_bus_registered and unregister the bus before returning the error. Fixes: 6e12db376b60 ("base: soc: Allow early registration of a single SoC device") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260615180746.713540-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 243dc1c303e0b8e0c0713a27edf966edc9b91135 Author: Greg Kroah-Hartman Date: Mon Jan 30 18:10:59 2023 +0100 driver core: soc: remove layering violation for the soc_bus [ Upstream commit 90be1f15c39858a4f0f4346c39fa150697d231c1 ] The soc_bus code pokes around in the internal bus structures assuming that it "knows" if a field is not set that it has not been registered yet. That isn't a safe assumption, so just remove the layering violation entirely and keep track if the bus has been registered or not ourselves. Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20230130171059.1784057-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 45dfa004893d ("driver core: soc: Unregister bus on early device registration failure") Signed-off-by: Sasha Levin commit 6cde06887487b4febd14658c9a246616abcc0097 Author: Alban Bedel Date: Thu Jun 11 18:40:05 2026 +0200 software node: Fix software_node_get_reference_args() with index -1 [ Upstream commit ba3dedcf3bd47017307595a7e54924198f018246 ] The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case. Fixes: 31e4e12e0e960 ("software node: Correct a OOB check in software_node_get_reference_args()") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-devicetree/20260611103904.7CB131F00893@smtp.kernel.org/ Signed-off-by: Alban Bedel Link: https://patch.msgid.link/20260611164005.2930205-1-alban.bedel@lht.dlh.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1edd064eb2357143163dd4a55c79fed26200a160 Author: Ian Rogers Date: Thu Jul 16 00:23:43 2026 -0700 perf ui hists: Fix uninitialized stack memory free on pstack allocation failure [ Upstream commit d5fdde1c426922efabe86a515f0782b3eba40577 ] Fixes heap corruption by initializing the options and actions arrays before the pstack allocation check, preventing an uninitialized stack pointer from being passed to free_popup_options() if the allocation fails. Reported-by: sashiko-bot Closes: https://lore.kernel.org/linux-perf-users/20260709035230.6DBEE1F000E9@smtp.kernel.org/ Fixes: f2b487db45f2 ("perf hists browser: Fix possible memory leak") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Link: https://lore.kernel.org/linux-perf-users/20260709035230.6DBEE1F000E9@smtp.kernel.org/ Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 701c3ae7273e1adc20db5d97c42e0139b479f16b Author: zhouminqiang Date: Thu Jul 16 21:14:32 2026 +0800 mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() [ Upstream commit b759d5bb6265419344ee9729fd0dc07ad85719d8 ] mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && !(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the "out of reach" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK. Fixes: 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") Signed-off-by: zhouminqiang Reviewed-by: Zhihao Cheng Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit ecadb9137aeaa0615183f8d23eabea2b45c862f1 Author: Ruoyu Wang Date: Wed Jul 8 22:33:55 2026 +0800 mtd: mtdswap: Avoid freeing registered blktrans device twice [ Upstream commit 779aa4c66a96bf43d2d62982ea1a9096a9128d87 ] In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Signed-off-by: Ruoyu Wang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit eb84cd81040e58dd05ac190f561f2115e3367249 Author: Xiang Mei Date: Sat Jul 4 18:40:10 2026 -0700 vfio/pci: clear vdev->msi_perm after freeing it on init failure [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit e79d6dab5988f1436cae476fd348f1c57636d365 Author: Myeonghun Pak Date: Tue Jun 23 17:55:55 2026 +0900 char: xilinx_hwicap: unregister class on init errors [ Upstream commit e7e12b4cc0f0c3a2782aea084d4215e23f5512b3 ] hwicap_module_init() registers icap_class before reserving the character-device region and registering the platform driver. If either of those later steps fails, the init path must undo the successful class registration before returning an error. Route the chrdev registration failure through a class unwind label, and let the platform-driver registration failure fall through the existing chrdev unwind before unregistering the class. The normal module exit path is unchanged. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: ef141a0bb0dc ("[POWERPC] Xilinx: hwicap driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260623085604.89284-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 112add1ac5623ee78ebe7e3e5dd85dd8d3308958 Author: Linmao Li Date: Thu Jul 16 09:39:23 2026 +0800 ppdev: prevent overflow when setting port timeout [ Upstream commit 3c0cf801ea2fa40daa5e7d1e6d32adca5ff75ad9 ] PPSETTIME64 supplies the timeval fields as s64 values, but pp_set_timeout() narrows tv_usec to int and calculates tv_sec * HZ in a signed long. Large positive values can therefore be truncated or overflow and install an unintended timeout. Keep both fields as s64, reject a non-canonical microsecond value, and use timespec64_to_jiffies() to cap excessively large timeouts at MAX_JIFFY_OFFSET. This is a behavior change because both PPSETTIME ioctls could previously accept values with tv_usec >= USEC_PER_SEC. The validation follows the precedent set by sock_set_timeout(). Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe") Signed-off-by: Linmao Li Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260716013923.19494-1-lilinmao@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1d43cef1d4ff258dee3020cc29f29fd6becfd8b9 Author: Pengpeng Hou Date: Tue Jun 23 09:56:43 2026 +0800 misc: ad525x_dpot: use driver core groups for sysfs files [ Upstream commit e3a8557e88eb26278eda60bf64f2ef33ce7de8bf ] ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data. Fixes: 4eb174bee6f8 ("ad525x_dpot: new driver for AD525x digital potentiometers") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015643.36508-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 25ba60b606c782645cd51af19746bf7574c1cf88 Author: Uwe Kleine-König Date: Tue Oct 12 17:39:36 2021 +0200 misc: ad525x_dpot: Make ad_dpot_remove() return void [ Upstream commit 85385a51ceadfe79ae3b1eb5848fab6c3b917ea8 ] Up to now ad_dpot_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20211012153945.2651412-12-u.kleine-koenig@pengutronix.de Acked-by: Michael Hennerich Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e3a8557e88eb ("misc: ad525x_dpot: use driver core groups for sysfs files") Signed-off-by: Sasha Levin commit 157e96a961903752ff16029def0f36d8e656bb2a Author: Gleb Markov Date: Mon Jun 29 16:09:18 2026 +0300 misc: rtsx: add missing write register handling [ Upstream commit 655faba1ccf195e22a7a83146ef6015e3271233c ] If an error occurs at the stage of working with registers in conjunction with MCU_Block, it will not be processed. The occurrence of errors at this stage may signal an impact on writes to the device's PCI registers and is a more global problem than a driver-level security problem, but adding a handler would be a good practice. Add a missing error handling. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261") Signed-off-by: Gleb Markov Link: https://patch.msgid.link/20260629130920.1260-1-markov.gi@npc-ksb.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fd339b9ef0accb2c24a5285df842552ebf5eb146 Author: Pavel Zhigulin Date: Mon Jun 1 01:07:58 2026 +0200 speakup: keyhelp: guard letter_offsets possible out-of-range indexing [ Upstream commit 6a19ad4d68c95185308cd9e5d169b10a2cf236c8 ] help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo "0 _bad" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound. Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Signed-off-by: Pavel Zhigulin Signed-off-by: Samuel Thibault Link: https://patch.msgid.link/20260531230804.254962-10-samuel.thibault@ens-lyon.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3e955a6a5af59bc4ee2fb0739d8debbbecc49cf2 Author: Christophe JAILLET Date: Mon Jun 1 01:07:53 2026 +0200 accessibility: speakup: Fix incorrect string length computation in report_char_chartab_status() [ Upstream commit bce0e640623372520d9d90c42f33ddbfb576ce69 ] snprintf() returns the "number of characters which *would* be generated for the given input", not the size *really* generated. In order to avoid too large values for 'len' (and potential negative values for "sizeof(buf) - (len - 1)") use scnprintf() instead of snprintf(). Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Signed-off-by: Christophe JAILLET Signed-off-by: Samuel Thibault Reviewed-by: Samuel Thibault Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260531230804.254962-5-samuel.thibault@ens-lyon.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 63eaa7663335d482a8825c231213e312cacea567 Author: Yuho Choi Date: Tue Jun 30 15:27:14 2026 -0400 uio: Fix stale info pointer in failed registration path [ Upstream commit 67b6fc084b034a91c3ec7907a3fed89a2450f30b ] After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uio_unregister_device(). Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260630192714.1867170-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9f49c8b55debf1512f912077b6c759cc8b6d2e0 Author: David Lee Date: Fri Jul 17 10:47:21 2026 +0000 UDF symlink pathComponent header OOB read [ Upstream commit d23eb7380d1594cda31a5dc8487dd2a5c8def8c7 ] udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Link: https://patch.msgid.link/20260717104722.41446-1-david.lee@trailofbits.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit b6c2a7d78d4984206b005fb12c8c0991b757c819 Author: Karl Mehltretter Date: Fri Jul 17 09:16:16 2026 +0200 tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64 [ Upstream commit 782f4dbd1794b4f30dc116a7ca42c5962c409be8 ] hvc_dcc drives the JTAG DCC via the ARMv6/v7 CP14 debug registers (mrc/mcr p14, 0, rX, c0, c1/c5, 0 in asm/dcc.h). That encoding is undefined on older ARM cores, and also on ARMv7-M, but HVC_DCC only depends on ARM, so it can be enabled on e.g. ARM926 (ARCH_MULTI_V5), where hvc_dcc_console_init() runs __dcc_putchar() at boot and takes an undefined-instruction trap before the console is up: Internal error: Oops - undefined instruction: 0 [#1] ARM PC is at hvc_dcc_check+0x50/0x8c hvc_dcc_check from hvc_dcc_console_init+0x18/0x48 hvc_dcc_console_init from console_init+0x58/0x170 Kernel panic - not syncing: Fatal exception Restrict HVC_DCC to the CPUs where that encoding is valid: the CPU_V6 || CPU_V6K || CPU_V7 set that arch/arm/include/debug/icedcc.S guards it with, plus ARM64. Fixes: 16c63f8ea49c ("drivers: char: hvc: add arm JTAG DCC console support") Signed-off-by: Karl Mehltretter Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260717071616.91423-1-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 745adfe6c337f3d5d7737d57529d14a208151b45 Author: Xu Yang Date: Mon Jul 13 14:08:45 2026 +0800 usb: gadget: f_uac1_legacy: remove broken string configfs attributes [ Upstream commit 590d74ec8f488e06b9f1c0f8f0941f45531f3a55 ] The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected. Fixes: 0854611a19ae ("usb: gadget: f_uac1: add configfs support") Link: https://lore.kernel.org/linux-usb/20260625113154.1954813-1-xu.yang_2@oss.nxp.com/ Suggested-by: Greg Kroah-Hartman Assisted-by: Claude:claude-sonnet-4.6 Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260713060845.3759673-1-xu.yang_2@oss.nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a9e882cc8ba0dc63ef1a0497c16ebddb0d23b9e7 Author: Rafael J. Wysocki Date: Thu Jul 9 14:30:35 2026 +0200 ACPI: processor: idle: Expand _LPI package sanity checks [ Upstream commit d5c13047a132162d2649be876906ead691d12948 ] The _LPI package sanity checks in acpi_processor_evaluate_lpi() miss a couple of things, so expand them by adding a buffer size check before retrieving a struct acpi_power_register from it (and skip the given state if the buffer is not large enough to hold a register structure) and making the function avoid copying the state description from the ACPI table if there are too few elements in the package supposed to hold it. While at it, relocate and rephrase a comment about skipping _LPI state package elements [7-8]. Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states") Signed-off-by: Rafael J. Wysocki Reviewed-by: Sudeep Holla Acked-by: Huisong Li Link: https://patch.msgid.link/5084143.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit c6a85daeb6329a5e853bff59135b01f5f153e8ea Author: Wolfram Sang Date: Thu Aug 18 22:59:55 2022 +0200 ACPI: move from strlcpy() with unused retval to strscpy() [ Upstream commit b75d2cd06b33956b7ec35c6316e717c25a196ee5 ] Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang Signed-off-by: Rafael J. Wysocki Stable-dep-of: d5c13047a132 ("ACPI: processor: idle: Expand _LPI package sanity checks") Signed-off-by: Sasha Levin commit 92b4d16d4605a56032c1d100dda73492c8fad55e Author: Daniel Scally Date: Thu Jan 7 14:28:36 2021 +0100 media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro [ Upstream commit bf263f64e804a74ace9bd37f49341d68a653e5e6 ] To ensure we handle situations in which multiple sensors of the same model (and therefore _HID) are present in a system, we need to be able to iterate over devices matching a known _HID but unknown _UID and _HRV - add acpi_dev_get_next_match_dev() to accommodate that possibility and change acpi_dev_get_first_match_dev() to simply call the new function with a NULL starting point. Add an iterator macro for convenience. Reviewed-by: Andy Shevchenko Suggested-by: Andy Shevchenko Signed-off-by: Daniel Scally Acked-by: Rafael J. Wysocki Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Stable-dep-of: d5c13047a132 ("ACPI: processor: idle: Expand _LPI package sanity checks") Signed-off-by: Sasha Levin commit d7a560dc912756fd8b39b28b10818d931e863d2d Author: Mikko Perttunen Date: Tue Jun 9 17:09:20 2026 +0900 gpu: host1x: Avoid stack over-read in debug output helpers [ Upstream commit bc17ac285fb708f22a8fa2c0ed32eceb1d37e6d6 ] host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written. Fixes: 6236451d83a7 ("gpu: host1x: Add debug support") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-4-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit e3fc2f23c57a48842ae5564eb1864f914298b6d8 Author: Mikko Perttunen Date: Tue Jun 9 17:09:19 2026 +0900 gpu: host1x: Fix offset calculation in trace_write_gather [ Upstream commit eb896850964d3dfce291b4fdff9c2d42d85e564b ] When a gather longer than 2*TRACE_MAX_LENGTH (256) words is traced through host1x_cdma_push_gather, the reported BO offset drifts from the third iteration onward. Fix the calculation by properly calculating the value on each loop rather than accumulating. In reality, gathers tend to be pretty short so this is unlikely to ever have been observed. Fixes: b40d02bf96e0 ("gpu: host1x: Use struct host1x_bo pointers in traces") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-3-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit ebf00c51c9ac9188e2806a2b842418805ee879be Author: Maoyi Xie Date: Wed Jul 1 14:44:40 2026 +0800 drm/bridge: tc358767: clamp the reported AUX read size to the request [ Upstream commit ec6444a00c49e6c2b5e9a507272a28126677f9ee ] tc_aux_transfer() clamps an AUX read to the payload limit: size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: if (size) size = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer"). Fixes: 12dfe7c4d9c5 ("drm/bridge: tc358767: Use reported AUX transfer size") Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260701064440.1541418-1-maoyixie.tju@gmail.com Signed-off-by: Sasha Levin commit 8cfd4ed944188db83268b938832f57e1c40ff364 Author: Uday Khare Date: Thu Jun 18 18:50:54 2026 +0530 remoteproc: qcom: Fix glink->node reference leak in qcom_add_glink_subdev [ Upstream commit 44f4911ab8e6f4d69afad5f2571bbd2da421c918 ] In qcom_add_glink_subdev(), the device node reference acquired via of_get_child_by_name() is stored in glink->node. If the subsequent kstrdup_const() allocation for glink->ssr_name fails, the function returns early without calling of_node_put() on glink->node, leaking the reference count. Fix this by adding of_node_put(glink->node) on the error path before returning. Fixes: cd9fc8f1b35b ("remoteproc: qcom: Pass ssr_name to glink subdevice") Signed-off-by: Uday Khare Link: https://lore.kernel.org/r/20260618132054.11010-1-udaykhare77@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c58b77711b0391c73a9d1954e1759f9086ac0732 Author: Zhongqiu Han Date: Fri Jul 3 17:24:33 2026 +0800 cpufreq: schedutil: Fix self-contradictory comment in sugov_iowait_apply() [ Upstream commit db6a017c91b774c15b1b890db45981eacfff540e ] The kerneldoc of sugov_iowait_apply() says the IO boost value is increased in sugov_iowait_apply() and, in the same sentence, that it is decreased by the same function. That is self-contradictory, and the first part is wrong: sugov_iowait_apply() only decreases the boost. The boost is actually increased in sugov_iowait_boost(). Fix the comment to name sugov_iowait_boost() as the place where the boost is increased, so it matches the code. No functional change. Fixes: fd7d5287fd65 ("cpufreq: schedutil: Cleanup and document iowait boost") Signed-off-by: Zhongqiu Han Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260703092433.4080165-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c96fda8c8acbe80fc71ef29702a4953248675555 Author: Rafael J. Wysocki Date: Mon Dec 14 21:04:11 2020 +0100 cpufreq: schedutil: Add util to struct sg_cpu [ Upstream commit ca6827de4b67367e73fdf43d2ea0a0064423edfb ] Instead of passing util and max between functions while computing the utilization and capacity, store the former in struct sg_cpu (along with the latter and bw_dl). This will allow the current utilization value to be compared with the one obtained previously (which is requisite for some code changes to follow this one), but also it causes the code to look slightly more consistent and cleaner. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Stable-dep-of: db53c573d31d ("cpufreq: intel_pstate: Fix setting minimum P-state at init time") Signed-off-by: Sasha Levin commit d7c1d9406512681b17fcfc32cfd396988f6af5dc Author: Rafael J. Wysocki Date: Thu Nov 12 20:25:15 2020 +0100 cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate() [ Upstream commit 2554c32f0b84df1f506546125c9d15c8044a2ec2 ] Avoid doing the same assignment in both branches of a conditional, do it after the whole conditional instead. Signed-off-by: Rafael J. Wysocki Stable-dep-of: db53c573d31d ("cpufreq: intel_pstate: Fix setting minimum P-state at init time") Signed-off-by: Sasha Levin commit 3d954e10e65b641416b274a832d998aecd8cdc42 Author: Herve Codina Date: Fri Jun 14 19:32:08 2024 +0200 irqdomain: Handle additional domain flags in irq_domain_instantiate() [ Upstream commit 757398541c30a5e898169763b43f08dab71ea3bd ] In order to use irq_domain_instantiate() from several places such as irq_domain_create_hierarchy(), irq_domain_instantiate() needs to handle additional domain flags. Add the required infrastructure. Suggested-by: Thomas Gleixner Signed-off-by: Herve Codina Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240614173232.1184015-8-herve.codina@bootlin.com Stable-dep-of: 616dd89d81ad ("irqchip/renesas-irqc: Fix generic interrupt chip leak on remove") Signed-off-by: Sasha Levin commit cdbd4aea9cc4b63c5cc3daff012ae1d7db7cc98a Author: Herve Codina Date: Fri Jun 14 19:32:03 2024 +0200 irqdomain: Introduce irq_domain_instantiate() [ Upstream commit 299d623f5c9ab48e53255cf6b510627f1ef26dfe ] The existing irq_domain_add_*() functions used to instantiate an IRQ domain are wrappers built on top of __irq_domain_add() and describe the domain properties using a bunch of parameters. Adding more parameters and wrappers to hide new parameters in the existing code lead to more and more code without any relevant value and without any flexibility. Introduce irq_domain_instantiate() where the interrupt domain properties are given using a irq_domain_info structure instead of the bunch of parameters to allow flexibility and easy evolution. irq_domain_instantiate() performs the same operation as the one done by __irq_domain_add(). For compatibility reason with existing code, keep __irq_domain_add() but convert it to irq_domain_instantiate(). [ tglx: Fixed up struct initializer coding style ] Suggested-by: Thomas Gleixner Signed-off-by: Herve Codina Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240614173232.1184015-3-herve.codina@bootlin.com Stable-dep-of: 616dd89d81ad ("irqchip/renesas-irqc: Fix generic interrupt chip leak on remove") Signed-off-by: Sasha Levin commit dae27792b8f31220ca9d6111d10f68333cae32c0 Author: Dan Carpenter Date: Tue Jul 14 18:46:22 2026 +0300 cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate() [ Upstream commit 6a9e0e0f7592313ace66303cf5eca68e04c10f30 ] The clk_get_parent() function doesn't return error pointers, it returns NULL on error. Update the error checking to match. Fixes: 420993221175 ("cpufreq: SPEAr: Add CPUFreq driver") Signed-off-by: Dan Carpenter Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 7652f7d2f2fea7f64e167370ca0c06f6cdbd3a7a Author: Bryam Vargas Date: Wed Jun 24 01:03:46 2026 -0500 libnvdimm/labels: Bound the on-media label size before the shift [ Upstream commit 18f9124248ed7a9da1c31973b629dceef76a9b0c ] For a v1.2+ index, __nd_label_validate() computes the label size as 1 << (7 + nsindex[i]->labelsize), where labelsize is a u8 read from the label storage medium. A value of 25 or more makes the shift count reach or exceed the width of int -- undefined behavior -- and 24 already shifts into the sign bit. Only 0 (128-byte) and 1 (256-byte) are valid. Reject a labelsize above 1 before the shift. The result was rejected by the following size comparison anyway, so this only removes the undefined shift on a crafted or corrupted medium; conforming labels are unaffected. Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-2-cdb6cab28b41@proton.me Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 6ad04c3e2ec54bf5ec72c81afdd66318a116c539 Author: Baochen Qiang Date: Wed Jul 1 09:49:13 2026 +0800 wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate [ Upstream commit 12b09e478aa7459b7893a695ef77682202f2da83 ] ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260701-ath11k-invalid-he-mcs-v1-1-7d963080c079@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 33cda0036bc683fc888c20b04a5fc030e3e8413b Author: Kyle Zeng Date: Wed Jul 8 18:02:03 2026 -0700 hfsplus: validate thread record before delete key rebuild [ Upstream commit e2ea5cac61acfc11dad22f1d2d4bc71d56c52a20 ] hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.6 Signed-off-by: Kyle Zeng Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260709010203.49664-1-kylebot@openai.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 73092c2292aa65515671e54abbcda2166d3827ed Author: Vishnu Santhosh Date: Thu Jun 4 14:12:53 2026 +0530 rpmsg: glink: fix deadlock in endpoint destroy during driver detach [ Upstream commit 5a5a48e788e02fd8a8eb7188ce440572d6c12418 ] During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock. Co-developed-by: Deepak Kumar Singh Signed-off-by: Deepak Kumar Singh Signed-off-by: Vishnu Santhosh Tested-by: Bjorn Andersson Fixes: a53e356df548 ("rpmsg: glink: fix rpmsg device leak") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260604-rpmsg-glink-fix-deadlock-destroy-ept-v1-1-b8a54ad1e4fd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 01cdfbec55d6dacd3add900fb2f9789813eda027 Author: Srinivas Kandagatla Date: Fri Aug 22 11:00:43 2025 +0100 rpmsg: glink: remove duplicate code for rpmsg device remove [ Upstream commit 112766cdf2e5ea0a0f72b0304d57a6f74c066670 ] rpmsg device remove code is duplicated in at-least 2-3 places, add a helper function to remove this duplicated code. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250822100043.2604794-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 5a5a48e788e0 ("rpmsg: glink: fix deadlock in endpoint destroy during driver detach") Signed-off-by: Sasha Levin commit 90dd5744fc9a566927de1f9975f84cbc28df7e2d Author: Arun Kumar Neelakantam Date: Thu Jul 30 10:48:14 2020 +0530 rpmsg: glink: Remove the rpmsg dev in close_ack [ Upstream commit c7c182d4447e172f87e37d6c04879b94b8635b37 ] Un-register and register of rpmsg driver is sending invalid open_ack on closed channel. To avoid sending invalid open_ack case unregister the rpmsg device after receiving the local_close_ack from remote side. Signed-off-by: Deepak Kumar Singh Signed-off-by: Arun Kumar Neelakantam [bjorn: s/strlcpy/strscpy/] Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1596086296-28529-5-git-send-email-deesin@codeaurora.org Stable-dep-of: 5a5a48e788e0 ("rpmsg: glink: fix deadlock in endpoint destroy during driver detach") Signed-off-by: Sasha Levin commit 5ae07f9768b7c810c9b48fdf9caea28fdced6f5c Author: Ira Weiny Date: Tue May 4 18:40:03 2021 -0700 iov_iter: lift memzero_page() to highmem.h [ Upstream commit 28961998f858114e51d2ae862065b858afcfa2b2 ] Patch series "btrfs: Convert kmap/memset/kunmap to memzero_user()". Lifting memzero_user(), convert it to kmap_local_page() and then use it in btrfs. This patch (of 3): memzero_page() can replace the kmap/memset/kunmap pattern in other places in the code. While zero_user() has the same interface it is not the same call and its use should be limited and some of those calls may be better converted from zero_user() to memzero_page().[1] But that is not addressed in this series. Lift memzero_page() to highmem. [1] https://lore.kernel.org/lkml/CAHk-=wijdojzo56FzYqE5TOYw2Vws7ik3LEMGj9SPQaJJ+Z73Q@mail.gmail.com/ Link: https://lkml.kernel.org/r/20210309212137.2610186-1-ira.weiny@intel.com Link: https://lkml.kernel.org/r/20210309212137.2610186-2-ira.weiny@intel.com Signed-off-by: Ira Weiny Cc: Alexander Viro Cc: David Sterba Cc: Chris Mason Cc: Josef Bacik Cc: Chaitanya Kulkarni Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Stable-dep-of: 68d4d3e78150 ("isofs: fix out-of-bounds page array access on empty zisofs block") Signed-off-by: Sasha Levin commit c1824fac30fa27daf9bdc9d47197122320d220ee Author: Thomas Gleixner Date: Tue Nov 3 10:27:18 2020 +0100 highmem: Provide generic variant of kmap_atomic* [ Upstream commit 298fa1ad5571f59cb3ca5497a9455f36867f065e ] The kmap_atomic* interfaces in all architectures are pretty much the same except for post map operations (flush) and pre- and post unmap operations. Provide a generic variant for that. Signed-off-by: Thomas Gleixner Cc: Linus Torvalds Cc: Christoph Hellwig Cc: Andrew Morton Link: https://lore.kernel.org/r/20201103095857.175939340@linutronix.de Stable-dep-of: 68d4d3e78150 ("isofs: fix out-of-bounds page array access on empty zisofs block") Signed-off-by: Sasha Levin commit d990dcbb8234e189d38089beb88b7ecedc87cb70 Author: Leon Romanovsky Date: Mon Jul 13 07:41:25 2026 -0400 RDMA/hfi1: Initialize debugfs after probe completes [ Upstream commit bb18740b302f6f222ce3d5a7e5c45a52a90df805 ] Commit ed6f653fe430 ("staging/rdma/hfi1: Fix debugfs access race") moved debugfs creation after device initialization and IB registration so users cannot access the files before the driver is ready. However, init_one() still creates them before character device creation and SDMA startup finish. Move hfi1_dbg_ibdev_init() to the end of the successful probe path, matching hfi1_dbg_ibdev_exit() as the first action in remove_one(). Fixes: ed6f653fe430 ("staging/rdma/hfi1: Fix debugfs access race") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-12-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a4cd91817f4547afa5c6a98d086429140b862b12 Author: Leon Romanovsky Date: Mon Jul 13 07:41:25 2026 -0400 RDMA/hfi1: Stop flushing the global IB workqueue [ Upstream commit d43b1c17f9e1b9d34a0d742f569c00d84147ebc0 ] hfi1 does not queue work on ib_wq. QSFP and link work run on the per-port link_wq, while the remaining device work uses hfi1_wq or dedicated queues. The probe failure path destroys both per-port workqueues, and normal device removal flushes them in shutdown_device() before destroying them. Remove the flushes of the core-owned global workqueue. Waiting for unrelated core or other device work is not part of hfi1 teardown. Fixes: 71d47008ca1b ("IB/hfi1: Create workqueue for link events") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-10-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fc9de58a33046fcf380030f809ae4bd44ce8700c Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Create workqueues before device initialization [ Upstream commit 0d5618c1b2fc9dd4fc086f0226acd8a077ab6c1b ] create_workqueues() only needs fields set up by hfi1_alloc_devdata(). Call it before hfi1_init_dd() so a workqueue allocation failure happens before chip resources are initialized. To keep the reordered error paths safe, make init_one() own hfi1_devdata. hfi1_init_dd() unwinds its partial setup but leaves the allocation for the caller to free. If device initialization fails, destroy the workqueues before freeing the device data. Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-6-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 9f674ba674a0 ("RDMA/hfi1: Allocate device data after PCI initialization") Signed-off-by: Sasha Levin commit 9627cd368ab1fd929a86d984490087ab11c2ab9c Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Remove redundant PCI device ID validation [ Upstream commit af9117d02f50514c998714b23820de71d0aa5d24 ] The PCI core calls init_one() only after pci_match_device() has selected an ID. For normal probing, hfi1_pci_tbl already restricts matches to the two supported Intel device IDs. Dynamic IDs and driver_override are explicit requests to attempt binding, so the probe should not second-guess the PCI core's decision. Remove the redundant check. Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-3-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 9f674ba674a0 ("RDMA/hfi1: Allocate device data after PCI initialization") Signed-off-by: Sasha Levin commit 852637d3ee56aed8ea3ee8948eda21eca406c051 Author: Leon Romanovsky Date: Mon Jul 13 07:41:23 2026 -0400 RDMA/hfi1: Preserve unit 0 on allocation failure [ Upstream commit 2e3809ad8911f5d5581b3f046bd628417bface76 ] hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device. Fixes: 03b92789e5cf ("hfi1: Convert hfi1_unit_table to XArray") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-2-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c75bb25a9c8d10c5d3e83b0625f221e799ddda9b Author: Sean Rhodes Date: Mon Jul 6 16:40:43 2026 +0100 misc: rtsx_usb: avoid USB I/O in runtime autosuspend [ Upstream commit 483c948324a3823871c004560a92545759d3253c ] The runtime autosuspend callback currently queries card status and clears OCP by issuing USB register accesses. This can run from the USB runtime-PM path itself, which is the wrong place to start more device I/O. Keep a cached copy of the card-status bits from normal status reads instead. During runtime autosuspend, use that cached value only to preserve the existing Memory Stick autosuspend deferral. Do not treat raw SD_CD as an autosuspend blocker, because tray-based SD readers can assert SD_CD with an empty tray. A real SD card is protected by the SD/MMC child runtime-PM usage once powered. Also stop clearing OCP from the runtime autosuspend callback, so the callback does not issue USB commands. Fixes: bb400d2120bd ("mfd: rtsx_usb: Defer autosuspend while card exists") Signed-off-by: Sean Rhodes Acked-by: Greg Kroah-Hartman Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9e4858936225b584140bd58ab55790b3cd496608 Author: Pengpeng Hou Date: Tue Jun 23 21:59:37 2026 +0800 pmdomain: bcm: bcm2835: handle genpd provider registration errors [ Upstream commit a1d9d3b958d69a13783613304f524f489fecdd1f ] bcm2835_power_probe() initializes all power domains and then registers the onecell genpd provider, but ignores of_genpd_add_provider_onecell() failures. Probe can therefore return success even though no provider was published. Check the provider registration return value and jump to the existing cleanup path on failure. Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.") Signed-off-by: Pengpeng Hou Reviewed-by: Stefan Wahren Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 85563bf040d4b0a2e8d196486e144c7e548f0158 Author: Evgenii Burenchev Date: Wed Jul 8 17:11:44 2026 +0300 ALSA: hpi: Check transport errors during HPI6000 adapter initialization [ Upstream commit cc15c329663e3ef1aeed0b68e49a5d5ce4ae0d5c ] create_adapter_obj() retrieves adapter information by calling hpi6000_message_response_sequence(). This function reports transport-level errors through its return value and DSP-reported errors via hr0.error. The current code only checks hr0.error, causing transport-level errors to be ignored. As a result, adapter initialization may continue with an invalid response. Check the return value of hpi6000_message_response_sequence() before examining hr0.error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 719f82d3987a ("ALSA: Add support of AudioScience ASI boards") Signed-off-by: Evgenii Burenchev Link: https://patch.msgid.link/20260708141147.18253-1-evg28bur@yandex.ru Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 91fc387f63c00ddfb5221127a17bac97549a8343 Author: Xiang Mei Date: Sat Jul 4 14:03:32 2026 -0700 xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full [ Upstream commit 5d9e3bf34fec9a5d237e4b7cef4a707bc2e091bc ] The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use "sp->len >= XFRM_MAX_DEPTH", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]' Fixes: 9473e1f631de ("[XFRM] MIPv6: Fix to input RO state correctly.") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8d853cc7cf6dbffe1d8665ee1530124937dad521 Author: Yuho Choi Date: Thu Jul 2 19:39:21 2026 -0400 hwrng: ks-sa - Fix runtime PM cleanup on registration failure [ Upstream commit 1c17b601fafb09c9ec074fd097737d20eafe7d63 ] ks_sa_rng_probe() enables runtime PM and resumes the device before registering the hwrng. If devm_hwrng_register() fails, probe returns without dropping the runtime PM usage count or disabling runtime PM. Unwind the runtime PM state on the registration failure path, matching the cleanup done by remove(). Fixes: eb428ee0e3ca ("hwrng: ks-sa - add hw_random driver") Signed-off-by: Yuho Choi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5aff4386f370529114d6dfb189e6115d0a29aa78 Author: Martin Kaiser Date: Thu Aug 24 21:40:35 2023 +0200 hwrng: ks-sa - access private data via struct hwrng [ Upstream commit b8f836cbe12bccf2beeadd638e1696f4acaa39c3 ] This driver uses a struct ks_sa_rng for its private data. It contains a struct hwrng. Call container_of to get from hwrng to ks_sa_rng. Signed-off-by: Martin Kaiser Signed-off-by: Herbert Xu Stable-dep-of: 1c17b601fafb ("hwrng: ks-sa - Fix runtime PM cleanup on registration failure") Signed-off-by: Sasha Levin commit bb9c23733a0c50e136bd40c27cb60023cc58e22c Author: Leon Romanovsky Date: Sun Jul 12 04:37:36 2026 -0400 RDMA/ipoib: Drain RCU callbacks during module teardown [ Upstream commit 31b7c700670830a0e8a4cdcd451c88a13cc5dc48 ] IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown. Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path") Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/ Link: https://patch.msgid.link/20260709-unload-rcu-v1-3-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 82dfd1df456227279b1c8c648983a530f2612098 Author: Leon Romanovsky Date: Sun Jul 12 04:37:35 2026 -0400 RDMA/core: Wait for RCU callbacks before unloading ib_core [ Upstream commit 7d75592114d1664623c8cf191a12b38052c04483 ] put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped. Fixes: 943bd984b108 ("RDMA/core: Allow detaching gid attribute netdevice for RoCE") Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/ Link: https://patch.msgid.link/20260709-unload-rcu-v1-1-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f7ebc2baff40332f1f5feb6c8255e54044b97f4b Author: Tetsuo Handa Date: Wed Apr 20 07:18:57 2022 +0900 RDMA/core: Avoid flush_workqueue(system_unbound_wq) usage [ Upstream commit ff815a89398d8bbfdc14ced98252bdae92126225 ] Flushing system-wide workqueues is dangerous and will be forbidden. Replace system_unbound_wq with local ib_unreg_wq. Link: https://lore.kernel.org/r/252cefb0-a400-83f6-2032-333d69f52c1b@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Signed-off-by: Jason Gunthorpe Stable-dep-of: 7d75592114d1 ("RDMA/core: Wait for RCU callbacks before unloading ib_core") Signed-off-by: Sasha Levin commit 70fbc89095b4f7a59bba221760ee7ec60e052a54 Author: Mert Seftali Date: Fri Jul 10 10:36:23 2026 +0200 iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE [ Upstream commit aa58ecc73466d0cb8c418de98e2225490bf600e3 ] Reading the in_accel_scale attribute on the DMARD09 has always returned -EINVAL: the channels advertise scale via info_mask_shared_by_type so the IIO core exposes the attribute, but dmard09_read_raw() only handles IIO_CHAN_INFO_RAW, so a SCALE read falls through to 'default: return -EINVAL': $ cat .../iio:deviceX/in_accel_scale cat: in_accel_scale: Invalid argument leaving userspace with raw counts it cannot convert to m/s^2. The driver was written from a vendor source [1] without a datasheet, and the scale was declared but never implemented. The vendor source carries the sensitivity: its conversion is acc = raw * GRAVITY_EARTH_1000 / sensitivity (then / 1000 -> m/s^2) with sensitivity = 32 and GRAVITY_EARTH_1000 = 9807 ("about (9.80665)*1000"), i.e. 32 counts correspond to 1 g. That sensitivity applies to the value this driver already reports as raw: the vendor reduces each 16-bit sample to a signed 9-bit value, and the preparation in dmard09_read_raw() yields the same value. It is self-consistent: 256 counts / 32 = 8 g full scale, matching the +/-8g range. Implement the scale derived from that sensitivity using standard gravity: scale = 9.80665 / 32 = 0.3064578125 m/s^2 per LSB Link: https://github.com/minstrelsy/mediatek/blob/1f49d8c87b839651bc89afc870277e8e0f2e2d55/custom/common/kernel/accelerometer/dmard09/dmard09.c [1] Fixes: a4fa6509dda4 ("iio: accel: add support for the Domintech DMARD09 3-axis accelerometer") Signed-off-by: Mert Seftali Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9a7049ca0c3a78f2165bfe4b33c0c24100cb609b Author: Laxman Acharya Padhya Date: Sat Jul 4 12:51:48 2026 +0545 drm/panel: samsung-s6d16d0: Power off on prepare failure [ Upstream commit a9f950adfe2147318d75e7a6eab5e814851802ac ] If enabling tearing mode or exiting sleep mode fails after the regulator is enabled, s6d16d0_prepare() returns without asserting reset or disabling the supply. Since the DRM panel core leaves the panel unprepared, a later unprepare call skips the driver callback and the supply remains enabled. Assert reset and disable the supply before returning the DSI command error. Fixes: ac1d6d74884e ("drm/panel: Add driver for Samsung S6D16D0 panel") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260704070648.35249-1-acharyalaxman8848@gmail.com Signed-off-by: Sasha Levin commit 2a06c6f106671f057f0aa6cfb4e92f1d344f8143 Author: Biju Das Date: Thu Jul 2 08:38:29 2026 +0100 usb: renesas_usbhs: Fix power-off ordering on unbind [ Upstream commit 589b9e6f96be6bd8dd0d45fda8e948c31dc2fe94 ] Move the usbhsc_power_ctrl() call to before hardware_exit() and reset_control_assert() in usbhs_remove(), so the PHY is powered off while priv->phy is still valid, rather than after hardware_exit() has already cleared it. Fixes: eb9ac779830b ("usb: renesas_usbhs: Fix synchronous external abort on unbind") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260702073832.175047-1-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6eb2664a2edb935370d7cf3f81097244c756af44 Author: Uwe Kleine-König Date: Fri Dec 9 16:09:14 2022 +0100 platform: Provide a remove callback that returns no value [ Upstream commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c ] struct platform_driver::remove returning an integer made driver authors expect that returning an error code was proper error handling. However the driver core ignores the error and continues to remove the device because there is nothing the core could do anyhow and reentering the remove callback again is only calling for trouble. So this is an source for errors typically yielding resource leaks in the error path. As there are too many platform drivers to neatly convert them all to return void in a single go, do it in several steps after this patch: a) Convert all drivers to implement .remove_new() returning void instead of .remove() returning int; b) Change struct platform_driver::remove() to return void and so make it identical to .remove_new(); c) Change all drivers back to .remove() now with the better prototype; d) drop struct platform_driver::remove_new(). While this touches all drivers eventually twice, steps a) and c) can be done one driver after another and so reduces coordination efforts immensely and simplifies review. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20221209150914.3557650-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 589b9e6f96be ("usb: renesas_usbhs: Fix power-off ordering on unbind") Signed-off-by: Sasha Levin commit 08173d4707020c5deeef8d8700a9d6f632832af8 Author: Uwe Kleine-König Date: Sun Feb 7 22:15:37 2021 +0100 driver core: platform: Emit a warning if a remove callback returned non-zero [ Upstream commit e5e1c209788138f33ca6558bf9f572f6904f486d ] The driver core ignores the return value of a bus' remove callback. However a driver returning an error code is a hint that there is a problem, probably a driver author who expects that returning e.g. -EBUSY has any effect. The right thing to do would be to make struct platform_driver::remove() return void. With the immense number of platform drivers this is however a big quest and I hope to prevent at least a few new drivers that return an error code here. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210207211537.19992-1-uwe@kleine-koenig.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 589b9e6f96be ("usb: renesas_usbhs: Fix power-off ordering on unbind") Signed-off-by: Sasha Levin commit 2c3e0afdf6b850fb9c7109c73414db4a4d79c80d Author: Uwe Kleine-König Date: Thu Nov 19 13:46:11 2020 +0100 driver core: platform: use bus_type functions [ Upstream commit 9c30921fe7994907e0b3e0637b2c8c0fc4b5171f ] This works towards the goal mentioned in 2006 in commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown methods."). The functions are moved to where the other bus_type functions are defined and renamed to match the already established naming scheme. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20201119124611.2573057-3-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 589b9e6f96be ("usb: renesas_usbhs: Fix power-off ordering on unbind") Signed-off-by: Sasha Levin commit 95df1c7bed4b485d503b44a02c0e21b2205d094f Author: Uwe Kleine-König Date: Thu Nov 19 13:46:10 2020 +0100 driver core: platform: change logic implementing platform_driver_probe [ Upstream commit 16085668eacdc56c46652d0f3bfef81ecace57de ] Instead of overwriting the core driver's probe function handle probing devices for drivers loaded by platform_driver_probe() in the platform driver probe function. The intended goal is to not have to change the probe function to simplify converting the platform bus to use bus functions. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20201119124611.2573057-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 589b9e6f96be ("usb: renesas_usbhs: Fix power-off ordering on unbind") Signed-off-by: Sasha Levin commit a0b7930ed0a90635aada953ec7f41fdfd4dd7f8a Author: Uwe Kleine-König Date: Thu Nov 19 13:46:09 2020 +0100 driver core: platform: reorder functions [ Upstream commit e21d740a3fe5ad2db7b5f5c2331fe2b713b1edba ] This way all callbacks and structures used to initialize platform_bus_type are defined just before platform_bus_type and in the same order. Also move platform_drv_probe_fail just before it's only user. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20201119124611.2573057-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 589b9e6f96be ("usb: renesas_usbhs: Fix power-off ordering on unbind") Signed-off-by: Sasha Levin commit b895dbed8ac9e12a5ffa1a2165575a8469f8340d Author: Michael Bommarito Date: Wed Jun 17 20:50:43 2026 -0400 usb: gadget: configfs: fix out-of-bounds read of qw_sign [ Upstream commit f63edb54d8f738f9c21e2068c777ae1c097df6b7 ] os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions. Fixes: 76180d716f91 ("usb: gadget: configfs: make qw_sign attribute symmetric") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260618005043.1581707-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 061a930da628ca6cbc61670c41aa409e50980dec Author: Wolfram Sang Date: Tue May 12 10:48:23 2026 +0200 hwspinlock: propagate errno when registering single lock [ Upstream commit e088ffa9a00eaaaf90da74763e774ca160969c26 ] hwspin_lock_register_single() always returns 0 despite checking the result from radix_tree_insert(). Propagate the errno to make sanity checks in callers of this function actually meaningful. Fixes: 300bab9770e2 ("hwspinlock/core: register a bank of hwspinlocks in a single API call") Link: https://sashiko.dev/#/patchset/20260319105947.6237-1-wsa%2Brenesas%40sang-engineering.com # review of patch 14 Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20260512084856.30497-2-wsa+renesas@sang-engineering.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 19725961481330f853d4d5c6a8c86d85ac293259 Author: Cosmo Chou Date: Fri Jul 3 09:42:01 2026 +0800 leds: pca9532: Fix inverted GPIO output polarity [ Upstream commit 65a38a28a0b04af19a5e1fbf3869051412eeac96 ] The pca9532_gpio_set_value() function incorrectly mapped the requested value to PCA9532_ON and PCA9532_OFF, inverting the GPIO output polarity. A requested logical high (val=1) incorrectly enabled the LED output driver, which on this open-drain device pulls the pin low, while a requested logical low (val=0) released the pin. Correct the mapping so that val=1 yields PCA9532_OFF (pin released / high-impedance) and val=0 yields PCA9532_ON (pin driven low). pca9532_gpio_direction_input() is also updated to pass val=1 to pca9532_gpio_set_value() to align with the corrected polarity mapping, ensuring the pin remains not driven when configured as an input. Fixes: 3c1ab50d0a31 ("drivers/leds/leds-pca9532.c: add gpio capability") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260703014201.69829-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2a812700a5ca3aac6e32b1ccceb3c76155a199a9 Author: Wei Wang Date: Thu Jul 2 22:40:19 2026 +0800 iommu/amd: Fix false positive in SB IOAPIC IVRS validation [ Upstream commit 04fee302fac762a242ff1ad6810cff90c2a350ba ] The check_ioapic_information() function is designed to prevent boot hangs by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS table before enabling Interrupt Remapping. Currently, this check passes if *any* enumerated IOAPIC matches the expected SB IOAPIC device ID. If a buggy BIOS incorrectly assigns the SB IOAPIC's device ID to a secondary IOAPIC in the IVRS, while scrambling the true SB IOAPIC's mapping, the check hits a false positive and succeeds. This erroneously enables Interrupt Remapping. Consequently, the IOMMU blocks unmapped interrupts from the actual SB IOAPIC, dropping the system timer and leading to a silent kernel boot hang. Tighten the validation to verify the device ID specifically against the SB IOAPIC by matching their APIC IDs first. This prevents the validation check from being bypassed via device ID aliasing. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang Tested-by: Yongwei Xu Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6abd61a7c6a0604ce15dbcbdf4d559b2b8a693ea Author: Fu Hao Date: Tue Apr 7 16:25:40 2026 +0800 iommu/amd: Add support for Hygon family 18h model 4h IOAPIC [ Upstream commit 5beda8cadb1f072140e58b1edb7604444a42d955 ] The SB IOAPIC is on the device 0xb from Hygon family 18h model 4h. Signed-off-by: Fu Hao Tested-by: Tingyin Duan Signed-off-by: Joerg Roedel Stable-dep-of: 04fee302fac7 ("iommu/amd: Fix false positive in SB IOAPIC IVRS validation") Signed-off-by: Sasha Levin commit 09a7227601e3ba9d3002305ee9c353da9f69a051 Author: Wei Wang Date: Thu Jul 2 22:40:18 2026 +0800 iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors [ Upstream commit 854056480f9217568e3ab5edd81a9347a173ea79 ] The check_ioapic_information() function validates IOAPICs against the IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides a broken topology. Currently, the validation loop contains a bug: If an unmapped secondary IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB) IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to true. This bypasses the validation failure and leaves IR enabled. When devices attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops them due to the missing Requestor ID, leading to localized device hangs. Fix this by initializing 'ret' to true and only toggling it to false upon encountering a validation error, ensuring failures are never erased. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang Tested-by: Yongwei Xu Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 19b77aa8c83894f7019045d7d218fc0853810fb9 Author: Vladimir Zapolskiy Date: Thu Jul 2 01:24:11 2026 +0300 iommu/msm: Return -ENOMEM on memory allocation failure in probe [ Upstream commit b0d50c9016c4c2959dfa61bf9549cf98f9aa19cd ] If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 109bd48ea2e1 ("iommu/msm: Add DT adaptation") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f32a4a40bc635be25d6816da4bd91e9e58c31bf3 Author: Daniel Borkmann Date: Wed Jul 8 23:15:34 2026 +0200 bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux [ Upstream commit 92863e678070f57c17c868e4bfa2441a5c61ad2b ] bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals. Fixes: 8580ac9404f6 ("bpf: Process in-kernel BTF") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260708211537.371874-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e6461ef34f91ad7dbffdf912b3d661a7dd892931 Author: Aleksandr Nogikh Date: Tue Jun 23 12:30:52 2026 +0000 udf: Mark LVID buffer as uptodate before marking it dirty [ Upstream commit fb0601134c7e51728bd098abc6909315de1e5d86 ] When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 Fixes: 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+0306b38d9ed6ef71467d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0306b38d9ed6ef71467d Link: https://syzkaller.appspot.com/ai_job?id=05f8e20f-f080-4c7f-a206-08dbc15cb4a1 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/6ffb2ca8-e22f-4fd6-9f37-7202ec0878bd@mail.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit c9e93290ffe7db22a8131a5f5fd026335090fbbe Author: Hongyan Xu Date: Wed Jun 24 22:09:08 2026 +0800 usb: gadget: r8a66597: avoid double free of ep0_req in probe error path [ Upstream commit 41d541e3718db01668a4cd29815ee4b3b55f76d2 ] If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Fixes: 776976a67ae2 ("usb: gadget: r8a66597-udc: cleanup error path") Issue found using a prototype static analysis tool and confirmed by code review. Signed-off-by: Hongyan Xu Signed-off-by: Slavin Liu <220245772@seu.edu.cn> Link: https://patch.msgid.link/20260624140908.1282-1-getshell@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 418d2f0a32b2a9ceb656a88aa9139408a9b7b517 Author: Herman van Hazendonk Date: Tue Jun 2 16:09:34 2026 +0200 clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() [ Upstream commit 86b23609d5e17a770d03037e53c6a443e742a6e6 ] gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): void gdsc_unregister(struct gdsc_desc *desc) { struct device *dev = desc->dev; size_t num = desc->num; gdsc_pm_subdomain_remove(desc, num); of_genpd_del_provider(dev->of_node); } That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly. Signed-off-by: Herman van Hazendonk Fixes: 45dd0e55317c ("clk: qcom: Add support for GDSCs") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-4-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6d5f039c88ee2184cfd13a870e8dd99344f98e78 Author: Bryan O'Donoghue Date: Fri Jan 17 13:54:08 2025 +0000 clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code [ Upstream commit 65a733464553ea192797b889d1533a1a37216f32 ] Adding a new clause to this if/else I noticed the existing usage of pm_genpd_add_subdomain() wasn't capturing and returning the result code. pm_genpd_add_subdomain() returns an int and can fail. Capture that result code and throw it up the call stack if something goes wrong. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-2-13f2bb656dad@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 86b23609d5e1 ("clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()") Signed-off-by: Sasha Levin commit e8dca9c93c13deea84fc7f045bdc6dbbb433b73b Author: Bryan O'Donoghue Date: Fri Jan 17 13:54:07 2025 +0000 clk: qcom: gdsc: Release pm subdomains in reverse add order [ Upstream commit 0e6dfde439df0bb977cddd3cf7fff150a084a9bf ] gdsc_unregister() should release subdomains in the reverse order to the order in which those subdomains were added. I've made this patch a standalone patch because it facilitates a subsequent fix to stable. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-1-13f2bb656dad@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 86b23609d5e1 ("clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()") Signed-off-by: Sasha Levin commit 1c4b6fd120e78b77ce6d06291022f2f86f390b9f Author: Dmitry Baryshkov Date: Sun Aug 29 18:47:54 2021 +0300 clk: qcom: gdsc: enable optional power domain support [ Upstream commit 1b771839de054710e1e015b10e29a4d04c41f54b ] On sm8250 dispcc and videocc registers are powered up by the MMCX power domain. Currently we use a regulator to enable this domain on demand, however this has some consequences, as genpd code is not reentrant. Make gdsc code also use pm_runtime calls to ensure that registers are accessible during the gdsc_enable/gdsc_disable operations. Signed-off-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210829154757.784699-6-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd Stable-dep-of: 86b23609d5e1 ("clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()") Signed-off-by: Sasha Levin commit 15b6935ed2ee8450082aeb5cdc6be029507684e1 Author: Herman van Hazendonk Date: Tue Jun 2 16:09:33 2026 +0200 clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains [ Upstream commit eea55fc694e132aacbe2cf4be7f345115e3d1801 ] GENPD_FLAG_ALWAYS_ON requires the underlying domain to be on at genpd_init() time -- the framework will refuse to register the domain otherwise. When the cold readback in gdsc_init() finds an ALWAYS_ON GDSC powered down, the driver tries to bring it back up: } else if (sc->flags & ALWAYS_ON) { /* If ALWAYS_ON GDSCs are not ON, turn them ON */ gdsc_enable(&sc->pd); on = true; } but discards the return value: if gdsc_enable() fails (regmap write error, the long-form sequence's status poll times out, or the HW_CTRL hand-off errors) the code still sets on=true and falls through to pm_genpd_init(..., !on) -- which then registers the domain in the ON state and sets GENPD_FLAG_ALWAYS_ON, even though the silicon is actually off. Subsequent consumer probes will see genpd report "on" while accessing dead registers and hang or read garbage. Catch the failure and surface it: returning the error from gdsc_init() makes the provider probe fail with the underlying errno, which propagates to consumers as -EPROBE_DEFER (or fatal if the hardware really is broken) rather than silently lying about the rail state. Signed-off-by: Herman van Hazendonk Fixes: fb55bea1fe43 ("clk: qcom: gdsc: Add support for ALWAYS_ON gdscs") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-3-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ca83fe6098bd1d840ea44b522caaa0bdf29aa4a2 Author: Herman van Hazendonk Date: Tue Jun 2 16:09:32 2026 +0200 clk: qcom: gdsc: propagate gdsc_check_status() errors from gdsc_poll_status [ Upstream commit d69f0c2b8d292b4890c9f0fbe184dfc26c4de86c ] gdsc_check_status() returns negative errno when the underlying regmap_read() fails -- e.g. when a parent regmap dies during system suspend, a CSR is removed by an HW debug tool, or the bus controller goes into protection. gdsc_poll_status() treats the result as a plain boolean ("is the GDSC in the requested state?"), so any negative error return is truncated to "true" and the poll exits with success even though the rail's real state is unknown: do { if (gdsc_check_status(sc, status)) return 0; } while (ktime_us_delta(ktime_get(), start) < STATUS_POLL_TIMEOUT_US); if (gdsc_check_status(sc, status)) return 0; return -ETIMEDOUT; This silently misleads gdsc_toggle_logic() (which writes/un-writes SW_COLLAPSE on the strength of the poll succeeding) and the gdsc_init() sync path (which assumes the readback represents real silicon state). Latch the return value, propagate negative errno immediately, and only treat a strictly-positive value as "reached the target state". Make the same change in the post-timeout final check so a regmap that comes back after the deadline does not silently degrade to -ETIMEDOUT. Signed-off-by: Herman van Hazendonk Fixes: 77b1067a19b4 ("clk: qcom: gdsc: Add support for gdscs with gds hw controller") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-2-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa9072a67d143f4409b4c758f29fe5c4f6a94dc1 Author: David Woodhouse Date: Sun Jun 21 22:53:55 2026 +0100 timekeeping: Account for monotonicity adjustment in ntp_error [ Upstream commit b7befd6d91207cf3f4cecd68fea0c212093906cf ] timekeeping_apply_adjustment() modifies xtime_nsec to ensure monotonicity when mult changes: xtime_nsec -= offset This ensures that the time reported to userspace does not jump when the multiplier is adjusted from one tick to the next. However, the ntp_error accumulator which tracks the difference between intended and actual clock position was not being updated to reflect this additional discrepancy. An earlier attempt at this compensation existed as: ntp_error -= (interval - offset) << ntp_error_shift but was removed in commit c2cda2a5bda9 ("timekeeping/ntp: Don't align NTP frequency adjustments to ticks") because it was a major source of NTP error. That's because (interval - offset) was wrong: the subtraction of "interval" prematurely accounted for the changed xtime_interval of the next tick, which would be correctly accounted in the next accumulation anyway — a double subtraction. What is actually needed is just the "offset" part: ntp_error must be told that xtime_nsec moved by "offset" without a corresponding change in the intended position. For the normal ±1 mult dithering this is negligible (the adjustments cancel over time), but for larger mult changes — such as when an external reference clock sets a new frequency — the one-time uncompensated offset is significant. Fix by adjusting ntp_error by the correct amount: ntp_error += offset << ntp_error_shift This keeps ntp_error consistent with the actual xtime_nsec position after the adjustment, and ensures the discrepancy is correctly smoothed away over time and the clock returns to where it should have been. Fixes: c2cda2a5bda9 ("timekeeping/ntp: Don't align NTP frequency adjustments to ticks") Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Assisted-by: Kiro:claude-opus-4.6-1m Acked-by: John Stultz Link: https://patch.msgid.link/20260621220051.1030462-3-dwmw2@infradead.org Signed-off-by: Sasha Levin commit cd0d7c7deb5836504ba9a55cab70dc49048e26b4 Author: Thomas Weißschuh Date: Mon May 4 08:32:26 2026 +0200 y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32 [ Upstream commit 79ced850e549e8c86b772a79ea417a1425b5c04b ] 'struct __kernel_old_timespec' represents the 'native' time ABI of the kernel. On 32-bit systems it uses 32-bit fields and on 64-bit systems it uses 64-bit fields. However the x86 x32 ABI uses the 64-bit time ABI natively. This is correctly handled for the 'tv_sec' fields, through the typedefs of '__kernel_old_time_t' -> '__kernel_long_t' -> 'long long'. The same treatment was missed for 'tv_nsec'. In practice this might not make much of a difference as the value of 'tv_nsec' will always fit into 32 bits and the missing bits fall into the padding of the structure. When introspecting the structure however, a difference can be observed. Switch to 64-bit tv_nsec on x32. No other architectures or ABIs are affected. While this could be interpreted as violating the POSIX requirement of 'timespec::tv_nsec' being 'long': * __kernel_old_timespec is not actually the POSIX timespec type * the requirement is gone in newer versions of POSIX * this matches glibc Fixes: 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260504-timespec-x32-v2-1-0739c9047fc4@linutronix.de Signed-off-by: Sasha Levin commit 3c87735f10277f388b0491439abdf6b6a7a27468 Author: Yuho Choi Date: Thu Jul 2 17:57:33 2026 -0400 clocksource: Unregister subsystem on device registration failure [ Upstream commit 3dee6537e728bd8137fda6eaf859f26e685943f7 ] init_clocksource_sysfs() registers the clocksource subsystem before registering the clocksource device. If device_register() fails, the function returns the error while leaving the subsystem registered. Unregister the clocksource subsystem on that failure path so the successful subsystem registration is unwound before returning. Fixes: d369a5d8fc70 ("clocksource: convert sysdev_class to a regular subsystem") Signed-off-by: Yuho Choi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260702215733.84588-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 132cf48773c1478d672b3fb1b62cd70eee2f913b Author: Jiangshan Yi Date: Thu Jul 2 17:39:15 2026 +0800 selftests: timers: leap-a-day: Fix -w option and update usage comment [ Upstream commit b4b66151a71445f3a71574136ddc82968c7b175e ] Commit 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") replaced the -s option with -w and made "wait for the leap second" the non-default behaviour, but it only updated the switch/case handling. Two things were left inconsistent: - The getopt() option string still lists 's' instead of 'w', so passing -w is rejected as an invalid option and the new behaviour cannot be selected at all. - The file header comment still documents the removed -s option and an outdated default for -i. Fix the getopt() string to accept 'w' (matching the existing case 'w': handler) and update the header comment to describe -w, -t and the current -i default. Fixes: 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") Signed-off-by: Jiangshan Yi Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://patch.msgid.link/20260702093915.2652638-1-yijiangshan@kylinos.cn Signed-off-by: Sasha Levin commit c2316ec707101780447a470a65c984ebcd1d011d Author: Kemeng Shi Date: Thu Jul 2 11:30:45 2026 +0800 irqchip/gic-v3-its: Fix memleak in its_probe_one() [ Upstream commit 1efffab6fe336a5c4fd3c2886f255cd2f998e65f ] Fix collection leak when its_init_domain() failed in its_probe_one(). Fixes: 4c21f3c26ecc2 ("irqchip: GICv3: ITS: DT probing and initialization") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260702033050.1583-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 9303a6c3716282a48512244ec39a740613056f0d Author: Feng Yang Date: Tue Jul 7 16:14:34 2026 +0800 selftests/bpf: Fix memory leak in msg_alloc_iov [ Upstream commit 602701718649936eb287bf6c7ecf870ec54c6f71 ] In the msg_alloc_iov function, the iov pointer is only assigned to msg->msg_iov after all memory allocations complete successfully. Therefore, when a calloc failure triggers the unwind_iov cleanup branch, we should use the local variable iov instead of msg->msg_iov. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Feng Yang Reviewed-by: John Fastabend Link: https://lore.kernel.org/bpf/20260707081434.539327-1-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit d18b1248ad6bb1d1af749f43a11bbe506318d83e Author: Malaya Kumar Rout Date: Sat Jul 4 17:59:35 2026 +0530 selftests/bpf: Fix memory leak in msg_alloc_iov error path [ Upstream commit 0bebfaa39deadec21638f6fba553eae12627a26d ] In msg_alloc_iov(), when calloc() fails for an individual iov_base allocation, the error path frees all previously allocated iov_base entries but fails to free the iov array itself that was allocated with calloc() at the beginning of the function. This results in a memory leak of the iov array. Add free(iov) in the unwind_iov error path to ensure proper cleanup of all allocated memory. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Malaya Kumar Rout Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260704122936.102394-1-malayarout91@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c671fbba3dc46417016b8f01300f927af231d3cc Author: Evgenii Burenchev Date: Mon Jul 6 16:16:34 2026 +0300 ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer() [ Upstream commit cd3447e1b6425efd1704ed07f1f245c842927eb0 ] The condition if (count && size < count) can never evaluate to true. The VIA DMA count register is masked with 0x00ffffff before use, while the DMA buffer size is limited to 0x00fffffe bytes. As a result, 'count' can never exceed 'size', making the condition permanently false. This branch has therefore been unreachable since the driver was introduced. Remove the unreachable branch without changing runtime behavior. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Evgenii Burenchev Link: https://patch.msgid.link/20260706131638.15311-1-evg28bur@yandex.ru Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ff6d1ba247b5c62bdb678f1069abc86ad88a1402 Author: Dawei Feng Date: Mon May 25 17:18:36 2026 +0800 staging: rtl8723bs: fix mismatched free of HalData in rtw_sdio_if1_init() [ Upstream commit 264676418b726baca7be49171e306b6aa05cceb0 ] padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtw_sdio_if1_init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption. Use rtw_hal_data_deinit() to pair the free correctly and free HalData with vfree(). The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline. An x86_64 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260525091836.812565-1-dawei.feng@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f565fa3e520559523f32e283dfd421abff2754a Author: Ayush Mukkanwar Date: Mon May 11 20:39:29 2026 +0530 staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free functions [ Upstream commit be5e8d5f61b31105e0ed7f51cd591653aea5054f ] Add struct platform_device parameter to cvm_oct_free_hw_skbuff, cvm_oct_free_hw_memory and cvm_oct_mem_empty_fpa. Replace pr_warn calls with dev_warn, using &pdev->dev for device-aware logging. Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260511150931.93382-2-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c0a9a8586a63 ("staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown") Signed-off-by: Sasha Levin commit 5ccf479cb891fd11a9330039af4e2c6a1a230e90 Author: Yuvraj Singh Chauhan Date: Thu Feb 12 22:49:03 2026 +0530 staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown [ Upstream commit 41db5b76eeb4cc11a1097384caba7cfc659f7293 ] In cvm_oct_rx_initialize(), request_irq() is called with &oct_rx_group[i].napi as the dev_id: request_irq(oct_rx_group[i].irq, cvm_oct_do_interrupt, 0, "Ethernet", &oct_rx_group[i].napi); However, cvm_oct_rx_shutdown() passes cvm_oct_device (an array of struct net_device pointers) as the dev_id to free_irq(): free_irq(oct_rx_group[i].irq, cvm_oct_device); Since __free_irq() matches the action to remove by comparing dev_id pointers, the mismatched cookie means the IRQ handler is never found, triggering a WARN and leaving the IRQ line permanently allocated. This prevents proper driver cleanup on module removal. Fix the mismatch by passing &oct_rx_group[i].napi as the dev_id to free_irq(), matching what was used during request_irq(). Signed-off-by: Yuvraj Singh Chauhan Link: https://patch.msgid.link/20260212171903.1417804-1-ysinghcin@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c0a9a8586a63 ("staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown") Signed-off-by: Sasha Levin commit 32efcb6d5f4e3f030e7b0a3ba5c6c0684dd07486 Author: Ayush Mukkanwar Date: Mon Jun 15 22:57:33 2026 +0530 staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown [ Upstream commit b9af44b0d20b2247c4eb0ea5cfca907d643eea50 ] The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds. Fixes: 4898c560103f ("Staging: Octeon: Free transmit SKBs in a timely manner") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260511150931.93382-1-ayushmukkanwar%40gmail.com Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260615172734.42038-1-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1fa75e06bd31e105d9b748d1cd7794e4f363d239 Author: Dan Carpenter Date: Wed Jun 3 10:34:21 2026 +0300 staging: fbtft: Use sysfs_emit_at() to print to sysfs file [ Upstream commit 221192a784c25e28b489a7e75fabf59be4f63d57 ] This scnprintf() uses the wrong limit. It should be "PAGE_SIZE - len" instead of just PAGE_SIZE. We're not going to hit the limit in real life since we are printing at most FBTFT_GAMMA_MAX_VALUES_TOTAL (128) u32 values, however, it's still worth fixing. Use sysfs_emit_at() to fix this since this is a sysfs file. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Dan Carpenter Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/ah_Y_Y2RtqeGxchF@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba86de9f7b0d7903d2df5ea2373e34d8ca3fc43e Author: Bryam Vargas Date: Tue Jun 16 01:06:12 2026 -0500 greybus: audio: bound the topology section sizes against the fetched size [ Upstream commit 33d8c7b794d2a30637c9d3fcb478f1d3222bef1e ] gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed. Fixes: 184992e305f1 ("greybus: audio: Add Greybus Audio Device Class Protocol helper routines") Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260616-b4-disp-4352e8b0-v1-1-3e09f62e0ad5@proton.me Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57b1754a521146ab257c6b251b185b90eb22e258 Author: Ahmet Sezgin Duran Date: Thu May 21 20:44:25 2026 +0000 staging: sm750fb: gate dualview dataflow using g_dualview [ Upstream commit d352778979d2eed09e266ed0f3a5e3ccd3983940 ] In sm750fb_setup and sm750fb_set_drv functions, the dualview related code is guarded by `sm750_dev->fb_count > 1` condition. That value is updated only after each framebuffer is registered, while both guards are used before any increment. Current flow: lynxfb_pci_probe() sm750fb_setup() // fb_count is 0 for each fb: sm750fb_framebuffer_alloc() lynxfb_set_fbinfo() sm750fb_set_drv() // fb_count is 0 or 1 register_framebuffer() sm750_dev->fb_count++; // fb_count is incremented Thus even if `dualview=1` parameter is passed down to the driver, fb_count is never > 1 at either check, so dualview dataflows are not selected and crtc->vidmem_size is never halved. Use `g_dualview` global variable instead of fb_count > 1 to correctly enable dualview capabilities. Fixes: a3f92cc94c61 ("staging: sm750fb: replace dual member of sm750_dev with fb_count") Signed-off-by: Ahmet Sezgin Duran Link: https://patch.msgid.link/20260521204425.82627-1-ahmet@sezginduran.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 244a889ec9d03f55701cd57f3cab0e4ae6afa5fb Author: Alexander A. Klimov Date: Thu May 21 20:23:30 2026 +0200 staging: greybus: audio: correct sscanf() return value check [ Upstream commit f883fa1a0a0212f63acb18c50e5f900301f3bb1e ] manager_sysfs_add_store() passes 6 pointers to sscanf(), but required latter to return 7 which always failed the operation. I corrected it to 6. Fixes: 49b9137a6002 ("staging: greybus: audio: remove redundant slot field") Signed-off-by: Alexander A. Klimov Link: https://patch.msgid.link/20260521182331.22685-1-grandmaster@al2klimov.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dbab1533f65abe535c1eacd7e96ecd22e8ed5e52 Author: Jonathan Cameron Date: Sun Feb 25 14:27:11 2024 +0000 of: Add cleanup.h based auto release via __free(device_node) markings [ Upstream commit 9448e55d032d99af8e23487f51a542d51b2f1a48 ] The recent addition of scope based cleanup support to the kernel provides a convenient tool to reduce the chances of leaking reference counts where of_node_put() should have been called in an error path. This enables struct device_node *child __free(device_node) = NULL; for_each_child_of_node(np, child) { if (test) return test; } with no need for a manual call of of_node_put(). A following patch will reduce the scope of the child variable to the for loop, to avoid an issues with ordering of autocleanup, and make it obvious when this assigned a non NULL value. In this simple example the gains are small but there are some very complex error handling cases buried in these loops that will be greatly simplified by enabling early returns with out the need for this manual of_node_put() call. Note that there are coccinelle checks in scripts/coccinelle/iterators/for_each_child.cocci to detect a failure to call of_node_put(). This new approach does not cause false positives. Longer term we may want to add scripting to check this new approach is done correctly with no double of_node_put() calls being introduced due to the auto cleanup. It may also be useful to script finding places this new approach is useful. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20240225142714.286440-2-jic23@kernel.org Signed-off-by: Rob Herring Stable-dep-of: 64774dea5896 ("bus: qcom-ebi2: Fix clock leak on probe failure") Signed-off-by: Sasha Levin commit 86c61c3a6b1da63112e72738b805b29fdb8d08ed Author: Haowen Tu Date: Wed Jun 24 13:38:39 2026 +0800 PM: sleep: Fix off-by-one in wakelocks number limit check [ Upstream commit 6058646587dded0ce0ba91bd5a6afbf14fe42055 ] CONFIG_PM_WAKELOCKS_LIMIT is documented as the maximum number of user-space wakeup sources, but the limit check is performed before the counter is incremented and only rejects new wakeup sources when the current number is greater than the limit. This allows one extra wakeup source to be created. Reject new wakeup sources once the counter has reached the limit. Fixes: b86ff9820fd5 ("PM / Sleep: Add user space interface for manipulating wakeup sources, v3") Signed-off-by: Haowen Tu [ rjw: Subject edits ] Link: https://patch.msgid.link/20260624053839.2150567-1-tuhaowen@uniontech.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 168d4b436b6c9515c19b8e65cf3a40972b6eb432 Author: Yuho Choi Date: Mon Jun 15 16:05:40 2026 -0400 bus: ti-sysc: Fix /chosen node reference leak [ Upstream commit 6342de0aed216b6df460b492ddb532b3e0ed16f1 ] sysc_init_stdout_path() gets the /chosen node with of_find_node_by_path() to read stdout-path. The function then overwrites the local node pointer with the stdout-path lookup result, or exits on error, without dropping the /chosen reference. Keep the /chosen node in a separate variable and put it after the stdout-path value has been used for the lookup. The successful stdout node lookup remains referenced by the cached stdout_path pointer. Fixes: 3bb37c8e6e6a ("bus: ti-sysc: Handle stdout-path for debug console") Signed-off-by: Yuho Choi Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260615200540.770205-1-dbgh9129@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit 7d688605f42dbed5fd2ef46a08a0e4b59d3732bf Author: Shin'ichiro Kawasaki Date: Mon Jun 29 14:15:27 2026 +0900 nvmet-rdma: factor out response resource cleanup [ Upstream commit 90096175473f7c86e39c3f74f10343f965f5a05d ] Move the RDMA read/write context teardown and the request SGL freeing out of nvmet_rdma_release_rsp() into a new helper function nvmet_rdma_free_rsp_resources(). This is a refactoring with no functional change, in preparation for the following patch that uses nvmet_rdma_free_rsp_resources(). Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Stable-dep-of: 0114dd303b37 ("nvmet-rdma: fix response resource leak on queue teardown") Signed-off-by: Sasha Levin commit 304dcd26bfc3ce6771c2bd3b7c0299dcfd5f4e06 Author: Pengpeng Hou Date: Tue Jun 16 08:46:27 2026 +0800 crypto: sa2ul - stop probe if context pool creation fails [ Upstream commit d03f980a25853f6a380895119a572a3bb1194e8d ] sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit eb1e7dbf2acd1f49f79b51e05c6c5e8840201358 Author: Tang Bin Date: Thu Oct 21 10:16:23 2021 +0800 crypto: sa2ul - Use the defined variable to clean code [ Upstream commit 284340a368a034243d304bd64e5f6923780e3708 ] Use the defined variable "dev" to make the code cleaner. Signed-off-by: Tang Bin Signed-off-by: Herbert Xu Stable-dep-of: d03f980a2585 ("crypto: sa2ul - stop probe if context pool creation fails") Signed-off-by: Sasha Levin commit a430b5b6d2ddd2b266330f8507a655be1148347d Author: Lothar Rubusch Date: Sat Jun 13 20:20:37 2026 +0000 crypto: atmel-sha204a - fix heap info leak on I2C transfer failure [ Upstream commit 72bbf11ba14bd7d5fbf31a1ec42fff608b657f74 ] The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read. Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Signed-off-by: Lothar Rubusch Assisted-by: Gemini:1.5 Pro [google] Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5e33791dfcc6459e402a524669093cd953d5b2df Author: Thorsten Blum Date: Thu Jun 11 23:36:17 2026 +0200 crypto: atmel-ecc - reject hardware ECDH without a public key [ Upstream commit f240f9b588f4e2de89822adebf560a96b5d263ed ] The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c908ca6daced3ebd0bfeb5c4cbbbf5f75d898dd9 Author: Thorsten Blum Date: Tue Jun 9 12:05:54 2026 +0200 crypto: atmel-ecc - clean up and improve ECDH comments [ Upstream commit 3e84fb698abada239d3e35ed3d52a24dbfda5f6a ] Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale "unsupported curves" wording, since the device only supports a single curve (P-256), and move the set_secret() constraint to the description. In atmel_ecdh_set_secret(), clarify that the device generates the private key, and drop the redundant "only supports NIST P256" comment. In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the truncation comments. Also note that a P-256 public key consists of two 32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove the unnecessary fall-through comment and other redundant comments. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key") Signed-off-by: Sasha Levin commit 7fb744b7c5fd853ecd7b2d3b4fa8527d4cee186e Author: Thorsten Blum Date: Thu May 7 15:55:27 2026 +0200 crypto: atmel-ecc - replace min_t with min [ Upstream commit 5b085b2a038a1458f9398cb3b3b03cba6e38e1e0 ] Use the simpler min() macro since the values are all unsigned and compatible. Signed-off-by: Thorsten Blum Reviewed-by: David Laight Signed-off-by: Herbert Xu Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key") Signed-off-by: Sasha Levin commit 07397132fc58cd959e2f44965587166f00b09808 Author: Lee Jones Date: Thu Mar 18 12:44:18 2021 +0000 crypto: atmel-ecc - Struct headers need to start with keyword 'struct' [ Upstream commit 71057841feaa6c1b5a80959013e588b2cdf9aef1 ] Fixes the following W=1 kernel build warning(s): drivers/crypto/atmel-ecc.c:41: warning: cannot understand function prototype: 'struct atmel_ecdh_ctx ' Cc: Tudor Ambarus Cc: Herbert Xu Cc: "David S. Miller" Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: linux-crypto@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Lee Jones Reviewed-by: Tudor Ambarus Signed-off-by: Herbert Xu Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key") Signed-off-by: Sasha Levin commit 58fe1afee9d987c37de0afe75fbd976d55256639 Author: Meng Yu Date: Thu Mar 4 14:35:46 2021 +0800 crypto: ecdh - move curve_id of ECDH from the key to algorithm name [ Upstream commit 6763f5ea2d9ac9b5a34a374ee637b5e4f1f525dd ] 1. crypto and crypto/atmel-ecc: Move curve id of ECDH from the key into the algorithm name instead in crypto and atmel-ecc, so ECDH algorithm name change form 'ecdh' to 'ecdh-nist-pxxx', and we cannot use 'curve_id' in 'struct ecdh'; 2. crypto/testmgr and net/bluetooth: Modify 'testmgr.c', 'testmgr.h' and 'net/bluetooth' to adapt the modification. Signed-off-by: Meng Yu Reviewed-by: Zaibo Xu Reported-by: kernel test robot Signed-off-by: Herbert Xu Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key") Signed-off-by: Sasha Levin commit 98604cc8fd2578442f49cd113481e8fc83bc0ad3 Author: Tzung-Bi Shih Date: Thu Jul 2 08:27:45 2026 +0000 platform/chrome: sensorhub: Fix memory overread in ring handler [ Upstream commit d1ceb2b2324717fa30b44d56ef0c52813e239569 ] `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit b252c1794010078f37948aad18c8435d4ecd7b33 Author: Hisam Mehboob Date: Fri Jun 19 00:37:25 2026 +0500 selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check [ Upstream commit d7b2769f8dba3e5f40d2a8a11988812d51160b17 ] Building the rseq selftests against musl libc fails because musl's does not provide the glibc-specific __GNUC_PREREQ macro: error: missing binary operator before token '(' Replace __GNUC_PREREQ(11, 1) with an equivalent check using __GNUC__ and __GNUC_MINOR__ directly. This pattern is portable across all C library implementations and is already used elsewhere in the tools/ tree (e.g., tools/include/linux/string.h). This also allows removing the #include , which was only needed for __GNUC_PREREQ. Fixes: 886ddfba933f ("selftests/rseq: Introduce thread pointer getters") Signed-off-by: Hisam Mehboob Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260618193724.589113-2-hisamshar@gmail.com Signed-off-by: Sasha Levin commit e9ae8e86eed68bea5d2670eadf61938a43bd2263 Author: Hanlin Song Date: Fri May 22 11:18:24 2026 +0800 csky: Fix a4/a5 restoration in syscall trace path [ Upstream commit abb81e5ce7d995baa41556b8125fa59e28ba3be8 ] The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2 Fixes: e0bbb53843b5 ("csky: Fixup abiv2 syscall_trace break a4 & a5") Suggested-by: Guo Ren Signed-off-by: Hanlin Song Signed-off-by: Guo Ren (Alibaba DAMO Academy) Signed-off-by: Sasha Levin commit 1c53121ac861d4e87d6a641c553b0600231bd27e Author: Sanjay Chitroda Date: Mon Jun 22 10:59:57 2026 +0530 iio: orientation: hid-sensor-rotation: Avoid race between callback setup and device exposure [ Upstream commit 0e32649a7cf3cd784862f8dc0c68a5134731bfff ] The driver currently exposes the IIO device to userspace before completing sensor hub callback registration, and similarly removes callbacks while the device can still be accessed during teardown. This creates a timing window where userspace may enable the buffer before callbacks are available. In such cases: - samples can be dropped, - buffered reads may observe stale or no data. Reorder probe and remove paths to ensure callbacks are active before device exposure and are removed after device is no longer accessible. This avoids a race window leading to data loss. Signed-off-by: Sanjay Chitroda Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support") Reviewed-by: Andy Shevchenko Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5d8e39affbdbfed050390e3ec217aef7917cbe49 Author: Srinivas Kandagatla Date: Wed Jul 1 20:30:05 2026 +0100 soundwire: qcom: Fix port exhaustion check in stream_alloc_ports [ Upstream commit 6ccec91c3535b07310e12d32fe9c67ff8d31d965 ] find_first_zero_bit(mask, n) returns n (not n+1) when all bits are set, so the guard `pn > maxport` is never true on exhaustion. The driver would silently call set_bit(maxport, port_mask) and assign the out-of-range port instead of returning -EBUSY. Fix the comparison to `pn >= maxport`. Fixes: 02efb49aa805 ("soundwire: qcom: add support for SoundWire controller") Reported-by: sashiko-bot Assisted-by: Claude Sonnet 4.6 Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260701193006.4113-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b2e4a7f2392a72af4f06e5542cd8de09881954f3 Author: Srinivas Kandagatla Date: Mon Mar 15 16:56:48 2021 +0000 soundwire: qcom: add static port map support [ Upstream commit eb5a909441a896fe9e230086363284a09c23e5df ] SoundWire device ports are statically mapped to Controller ports during design. Add support to read these from SoundWire devices. This controller uses static port map info to setup bandwidth parameters for those ports. A generic port allocation is not possible in this cases! Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210315165650.13392-4-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Stable-dep-of: 6ccec91c3535 ("soundwire: qcom: Fix port exhaustion check in stream_alloc_ports") Signed-off-by: Sasha Levin commit 7859c8eae0bf7264223e3bed32d5d00ddd9843df Author: Srinivas Kandagatla Date: Mon Mar 15 16:56:47 2021 +0000 soundwire: qcom: update port map allocation bit mask [ Upstream commit 650dfdb894f0f2bc568a29ab91c704dca587458b ] currently the internal bitmask used for allocating ports starts with offset 0. This is bit confusing as data port numbers on Qualcomm controller are valid from 1 to 14. So adjust this bit mask accordingly, this will also help while adding static port map support. Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210315165650.13392-3-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Stable-dep-of: 6ccec91c3535 ("soundwire: qcom: Fix port exhaustion check in stream_alloc_ports") Signed-off-by: Sasha Levin commit fd89bceb20bac84450530f31f9ff2aa888ef89d3 Author: Srinivas Kandagatla Date: Mon Mar 15 16:56:46 2021 +0000 soundwire: add static port mapping support [ Upstream commit f4022062e5417ab7228e95aec1a8687059a19db7 ] Some of the SoundWire device ports are statically mapped to Controller ports during design, however there is no way to expose this information to the controller. Controllers like Qualcomm ones use this info to setup static bandwidth parameters for those ports. A generic port allocation is not possible in this cases! So this patch adds a new member m_port_map to struct sdw_slave to expose this static map. Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210315165650.13392-2-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Stable-dep-of: 6ccec91c3535 ("soundwire: qcom: Fix port exhaustion check in stream_alloc_ports") Signed-off-by: Sasha Levin commit 5803b11f12fc1286e379a1fcab34938870cc4a40 Author: Vladimir Zapolskiy Date: Tue Jun 30 17:42:14 2026 +0300 dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in probe [ Upstream commit cbabdd6ce1b313b5877c7fbb2f5e2f7936564d2f ] Out of memory situation on driver's probe is expected to be reported to the driver's framework with a proper -ENOMEM error code. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Frank Li Link: https://patch.msgid.link/20260630144214.4080302-1-vz@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7f4b989d7d87381927b98d64492f8dcf979f57ab Author: Suraj Gupta Date: Fri Jun 26 14:56:54 2026 +0530 dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers [ Upstream commit 0b6d055edb55ecadadf54e930c2b4fab76fa9a5a ] Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts. Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine") Tested-by: Folker Schwesinger Signed-off-by: Suraj Gupta Co-developed-by: Srinivas Neeli Signed-off-by: Srinivas Neeli Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260626092656.1563871-2-suraj.gupta2@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a9c277b82cdd356f5e23e7f6787809f7199dd7ac Author: Vladimir Zapolskiy Date: Wed Jul 1 23:07:03 2026 +0300 dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure [ Upstream commit 467265c750edd7ab43803deeafe7d3120a791d32 ] If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Frank Li Reviewed-by: Matthias Brugger Link: https://patch.msgid.link/20260701200703.117929-1-vz@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 206e478810d6af50b25d8da72e3af8d55a014365 Author: Asad Kamal Date: Tue Jun 23 00:00:00 2026 +0000 drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup [ Upstream commit 6fa33f594e46e775a94097f71b486d7b006b6917 ] vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range. Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d9ef085114d1e3c2c1f869c0bdb275a7b358ce8b Author: Asad Kamal Date: Tue Jun 23 00:00:00 2026 +0000 drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup [ Upstream commit 3a8a05477cda6c8293e2b629495b42981dcaba32 ] vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range. Fixes: c82baa281843 ("drm/amd/powerplay: add Tonga dpm support (v3)") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 436c5b04dc0be415a7e0b38ec6172ad56c1f8998 Author: Sean Young Date: Wed Jun 24 11:05:47 2026 +0100 media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define [ Upstream commit 6e5deb2923b0d1b73c77a1a77c30b0da43d9e022 ] Since commit af86ce79f020 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map"), the RC_MAP_HAUPPAUGE_NEW define is no longer used. Fixes: af86ce79f020 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map") Signed-off-by: Sean Young Acked-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7df6c18f51f173f0abbb099073b9e29e01e8415e Author: Sean Young Date: Wed Jun 24 10:55:51 2026 +0100 media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define [ Upstream commit 5370facb7b4461166a4610d456fefeb92ef50a82 ] Since commit 206241069ecf ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap"), the rc-rc5-tv keymap is no longer in the tree. Fixes: 206241069ecf ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap") Signed-off-by: Sean Young Acked-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d428863ca8baa4e9eaf781266ac219b017dcf277 Author: Daniel McCarthy Date: Thu Jun 18 01:04:51 2026 +0300 pinctrl: bcm2835: Don't remove an unregistered GPIO chip [ Upstream commit 32711f77db0641e57fd96fdc013bf1286b9f2514 ] If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Signed-off-by: Daniel McCarthy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9c16a9b8295757390fa5dc59310ed2b94c274ffe Author: Zide Chen Date: Thu Jun 11 09:00:29 2026 -0700 perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails [ Upstream commit 3012af7df3430788eddd30b3c6654d0a0a5f06c6 ] uncore_event_cpu_online() returns -ENOMEM early when both the MSR and MMIO box allocations fail. This also aborts PCI uncore setup, even though PCI PMUs are independent of the MSR/MMIO paths. Remove the early return so PCI uncore setup always runs regardless of whether MSR or MMIO box allocation succeeds. Fixes: 3da04b8a00dd ("perf/x86/intel/uncore: Support MMIO type uncore blocks") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ian Rogers Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260611160033.66760-5-zide.chen@intel.com Signed-off-by: Sasha Levin commit af1f276d50c9d7ebcd25770f358ca503a89d96d7 Author: Henrik Grimler Date: Mon Jun 1 14:03:59 2026 +0200 drm/lima: call drm_mm_init() with a valid allocation range [ Upstream commit 3b3bce4a692ac60d9f4a341e6b597dd1fd0a28f9 ] lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up. Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Henrik Grimler Signed-off-by: Qiang Yu Link: https://patch.msgid.link/20260601-lima-alloc-fix-v1-1-16d3f3b7b780@axis.com Signed-off-by: Sasha Levin commit 505fd99c28d0c739bc8a4ca8345b89a7acd17bc6 Author: Brian Masney Date: Tue May 5 20:48:57 2026 -0400 clk: imx: scu: drop redundant init.ops variable assignment [ Upstream commit 5f2db1ce201216e81333ecc2ab51494410b2fe0d ] The init.ops is assigned a default value, however right below it is an if, else if, and else where all of them also assign a value to init.ops. Drop the redundant init.ops assignment at the top. Fixes: 3b9ea606cda53 ("clk: imx: scu: add cpu frequency scaling support") Reviewed-by: Peng Fan Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 685cb692353c0220345cf27af1c7d1ae9822b1f6 Author: Anson Huang Date: Fri Jun 4 17:09:40 2021 +0800 clk: imx: scu: Add A72 frequency scaling support [ Upstream commit a43f6e8ae429f5ca594ae4463cc31c2a8ad4339c ] Add A72 clock to support cpufreq on A72 cluster. Signed-off-by: Anson Huang Signed-off-by: Dong Aisheng Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Stable-dep-of: 5f2db1ce2012 ("clk: imx: scu: drop redundant init.ops variable assignment") Signed-off-by: Sasha Levin commit 99a21baaf3bbdd5f799a2a3eeedcaf71e037dae6 Author: Anson Huang Date: Fri Jun 4 17:09:39 2021 +0800 clk: imx: scu: Add A53 frequency scaling support [ Upstream commit cd8bd2f3ca64cac701084a5b3fc21e721bb15278 ] Add i.MX8QM cpufreq support for A53 cluster. Signed-off-by: Anson Huang Signed-off-by: Dong Aisheng Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Stable-dep-of: 5f2db1ce2012 ("clk: imx: scu: drop redundant init.ops variable assignment") Signed-off-by: Sasha Levin commit 111c315f10d9fe99c43d39dd28c43efcb30ecb74 Author: Weigang He Date: Wed Jun 10 15:06:24 2026 +1000 ARM: imx: fix device_node refcount leak in imx_src_init() [ Upstream commit 936407c3563ac745cbbb9953c0cf2472128a22f4 ] imx_src_init() obtains a device_node reference via of_find_compatible_node() matching "fsl,imx51-src" and uses it only to call of_iomap(). It never releases that reference: on the success path the function returns at the end without of_node_put(np), leaking one device_node refcount on every boot of an i.MX5/6 platform. Release the reference right after of_iomap(). of_iomap() maps the node's registers but does not retain a reference to the device_node, so the node can be put once the mapping is done. The early return on a NULL np needs no put. Found by static analysis tool CodeQL. Fixes: bd3d924d71a4 ("ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 61507272bc6ddb132b3f4c8c0b7a78e8087e7e7e Author: Min zhang Date: Tue May 12 08:06:42 2026 +0800 clk: hisilicon: reset: Use devm_kzalloc to initialize hisi_reset_controller [ Upstream commit a8036f4591542de4b38ec81d3e2ba47bc0b2652b ] Using devm_kmalloc() does not zero-initialize the allocated structure. Uninitialized members in struct hisi_reset_controller may contain garbage data, which can cause reset_controller_register() to fail unexpectedly. Replace devm_kmalloc() with devm_kzalloc() to ensure all structure fields are properly zero-initialized. Fixes: 97b7129cd2afb ("reset: hisilicon: change the definition of hisi_reset_init") Reviewed-by: Brian Masney Signed-off-by: Min zhang Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 35f3ce0d2b8905fe4a7987fb01246086472ab3e2 Author: Alexander A. Klimov Date: Tue May 26 22:42:26 2026 +0200 clk: moxart: remove unused variables, fix refcount leak [ Upstream commit 9f275f2ee9ca60ea4c092bdc0195987945ad8ad8 ] Not only these error checks are redundand, those of_clk_get() return values weren't cleaned up via clk_put(). Fixes: c7bb4fc16ead ("clk: add MOXA ART SoCs clock driver") Signed-off-by: Alexander A. Klimov Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 6377b0744853f37adcf3729d6e111f3c2d6d8dfd Author: Gui-Dong Han Date: Fri Jun 26 16:08:06 2026 +0800 media: cec-pin: Fix event FIFO ordering [ Upstream commit a1d83d1b810665bd53ce8a7b7867e054d68676c7 ] cec_pin_update() fills work_pin_events[] and work_pin_ts[], then increments work_pin_num_events. cec_pin_thread_func() uses that counter to decide when to read the FIFO entries. Do not let the counter update be observed without the event update. Also do not let a freed slot be reused before the thread has finished reading it. Use release operations when publishing an entry and releasing a slot, and acquire operations when consuming those counter updates. Leave the other work_pin_num_events users as they do not participate in this FIFO publication path. Fixes: ea5c8ef29668 ("media: cec-pin: add low-level pin hardware support") Signed-off-by: Gui-Dong Han Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 69aba9184311c7c398d5b3858ca545af60b411aa Author: Weigang He Date: Wed Jun 10 00:38:52 2026 +1000 soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap() [ Upstream commit fa476d53edd24e8105faace04e881b9c4179738f ] exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node() and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With propname == NULL the callee uses np directly and does not drop a reference, so the reference taken by of_find_matching_node() is leaked on every call -- including on each -EPROBE_DEFER retry of the only in-tree caller, exynos_retention_init() in the Exynos pinctrl driver. Annotate np with the __free(device_node) cleanup attribute so the reference is released when the function returns. Found by static analysis tool CodeQL. Fixes: 76640b84bd7a ("soc: samsung: pmu: Provide global function to get PMU regmap") Signed-off-by: Weigang He Link: https://patch.msgid.link/20260609143852.1783558-1-geoffreyhe2@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 686e5c3bd378933b4e795fcc7d40c5aad358eaaa Author: Michael Bommarito Date: Wed Jun 17 23:00:35 2026 -0400 HID: roccat: bound device-supplied profile index [ Upstream commit 43fae42628a8c10fa8981773d7ec9f1a367821a7 ] kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds). Fixes: 14bf62cde7942 ("HID: add driver for Roccat Kone gaming mouse") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0744cb9520aade37e78f69134f3111086158f1d2 Author: Philipp Weber Date: Tue May 19 15:00:14 2026 +0200 HID: core: quiesce input in hid_hw_stop() to prevent use-after-free [ Upstream commit a4bc41504690b7d7064931909874f5b98cd148b6 ] A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit. Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Philipp Weber Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d174ffdf5efd87be905c3f5b501e9216fb7f1b7b Author: Konstantin Andreev Date: Mon May 25 01:37:49 2026 +0300 smack: restrict smackfs/{direct,mapped} values to 0-255 [ Upstream commit a7c44fd9f80e37763acf9cd3c87a58058d206427 ] Both smackfs/direct and smackfs/mapped incorrectly accept the full range of integer values. For example: # cd /sys/fs/smackfs/ # cat direct ; echo 250 # cat cipso2 @ 250/2 _ 250/2,4,5,6,7,8 * 250/3,5,7 ^ 250/2,4,5,6,7 ? 250/3,4,5,6,7,8 # echo -1234 >direct ; cat direct ; echo -1234 # cat cipso2 @ -1234/2 _ -1234/2,4,5,6,7,8 * -1234/3,5,7 ^ -1234/2,4,5,6,7 ? -1234/3,4,5,6,7,8 # I noticed two things regarding this: 1) sensitivity levels are truncated to 8 bits when labeling outgoing packets (0x2e = 46 for the -1234 example above) 2) the reverse process fails: incoming packets with sensitivity level 46 do not match these smackfs/cipso2 entries. Even observation (1) on its own warrants a fix. This patch restricts smackfs/direct and smackfs/mapped accepted values to the 0-255 range. Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 236c62d33d4a51558f09afa48a5d41e924678488 Author: Konstantin Andreev Date: Mon May 25 01:37:48 2026 +0300 smack: deduplicate smackfs/{direct,mapped} file_operations [ Upstream commit 577dc3b6a8cf200e6e27b2d9967cac14a1fed2f3 ] The file_operations for smackfs/direct and smackfs/mapped are identical up to a textual replacement of "direct" with "mapped" This patch combines two instances of file_operations into one, handling both files. Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit d32f08898189c32c2a548384c747ee03173c110a Author: Dmitry Antipov Date: Fri Mar 20 14:31:57 2026 +0300 smack: simplify write handlers of sysfs entries [ Upstream commit b78fede1c69a090d377bf80417ce1f7f7f314534 ] Use the convenient 'kstrto{u,s}32_from_user()' to simplify write handlers of /smack/{doi,direct,mapped,logging,ptrace} sysfs entries. Signed-off-by: Dmitry Antipov Signed-off-by: Casey Schaufler Stable-dep-of: 577dc3b6a8cf ("smack: deduplicate smackfs/{direct,mapped} file_operations") Signed-off-by: Sasha Levin commit 6fdf7944b5f5e2bc09f8c7a7a27fc8464726d0bc Author: Austin Kim Date: Tue Jun 29 14:41:44 2021 +0100 smack: mark 'smack_enabled' global variable as __initdata [ Upstream commit bfc3cac0c76126995737f1b858d2cdb476be5b1d ] Mark 'smack_enabled' as __initdata since it is only used during initialization code. Signed-off-by: Austin Kim Signed-off-by: Casey Schaufler Stable-dep-of: 577dc3b6a8cf ("smack: deduplicate smackfs/{direct,mapped} file_operations") Signed-off-by: Sasha Levin commit 4e49f997ef0c569e09b42aab6bd38c7c54ea095d Author: Konstantin Andreev Date: Mon May 11 03:17:16 2026 +0300 smack: fix incorrect task context in smack_msg_queue_msgrcv [ Upstream commit fba3d32825f4bbc8e20f0cdc3b14df57965b8fe5 ] The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in "bar"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 665f9113e0d21ab27c56d99180e45790fda6e15f Author: Casey Schaufler Date: Wed Oct 13 14:56:43 2021 -0700 Smack: fix W=1 build warnings [ Upstream commit b57d02091b8f5eae1fce5652bb2b53857cd3c720 ] A couple of functions had malformed comment blocks. Namespace parameters were added without updating the comment blocks. These are all repaired in the Smack code, so "% make W=1 security/smack" is warning free. Signed-off-by: Casey Schaufler Stable-dep-of: fba3d32825f4 ("smack: fix incorrect task context in smack_msg_queue_msgrcv") Signed-off-by: Sasha Levin commit 158e3926777f32d540e7c0cbae2f5bbc95101bd7 Author: Maxime Ripard Date: Fri Jun 19 14:24:07 2026 +0200 drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure [ Upstream commit 30ac1d403438a6c6039f0af5bb2df3d021f96036 ] The drm_bridge_funcs.atomic_reset documentation states that the hook must return either a valid drm_bridge_state object or an ERR_PTR(). The cdns_mhdp_bridge_atomic_reset() callback returns NULL when the allocation of its state fails, violating this contract. Return ERR_PTR(-ENOMEM) instead. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Reviewed-by: Thomas Zimmermann Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-2-ff399263111b@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit e53a59e7cee5c1605d1ed595933098c2b69108f9 Author: Daniel Borkmann Date: Tue Sep 8 16:28:48 2026 +0200 bpf: Enforce expected_attach_type for tailcall compatibility [ Upstream commit 4540aed51b12bc13364149bf95f6ecef013197c0 ] Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. [ Fixed conflict, applied the changes to bpf_prog_array_compatible instead of __bpf_prog_map_compatible. Dropped the guard testing for BPF_MAP_TYPE_PROG_ARRAY as bpf_prog_array_compatible is only called on maps whose map_type is already BPF_MAP_TYPE_PROG_ARRAY, so the check was always true ] Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reviewed-by: Dongliang Mu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20250926171201.188490-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Miguel Gazquez (Schneider Electric) Signed-off-by: Sasha Levin commit c86214e6178c38a0eff39110a4e92b824f5dd403 Author: Martin Blumenstingl Date: Thu Sep 10 09:28:14 2026 +0200 clk: meson: align gxbb_32k_clk_sel number of parents with actual count [ Upstream commit 628b6fee9fca292f12d07f0f1bcf1edefa949d81 ] The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future). Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") Reported-by: Christian Hewitt Cc: stable@vger.kernel.org Tested-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20260623201956.1324992-1-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 97df3139ce45e61efae44b6f4ee7f4f43a9709f8 Author: Mahesh Rao Date: Thu Sep 10 11:14:06 2026 +0800 firmware: stratix10-svc: Add mutex in stratix10 memory management [ Upstream commit 85f96cbbbc67b59652b2c1ec394b8ddc0ddf1b0b ] Add mutex lock to stratix10_svc_allocate_memory and stratix10_svc_free_memory for thread safety. This prevents race conditions and ensures proper synchronization during memory operations. This is required for parallel communication with the Stratix10 service channel. [ 5.10.y lacks , so the upstream guard(mutex) is open-coded as explicit mutex_lock()/mutex_unlock(). ] Fixes: 7ca5ce896524f ("firmware: add Intel Stratix10 service layer driver") Cc: # v5.10.y Signed-off-by: Mahesh Rao Signed-off-by: Dinh Nguyen Signed-off-by: Tze Yee Ng Signed-off-by: Sasha Levin commit 344e59fc4f2cba6dc04ce5e2a77388645d4ca834 Author: Arnaldo Carvalho de Melo Date: Wed Sep 9 21:04:59 2026 +0000 perf sched: Fix register_pid() overflow, strcpy, and BUG_ON commit 5949d339f5ec98752d56dcd4e36f619a59d513a5 upstream. register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result. Fixes: ec156764d424 ("perf sched: Import schedbench.c") Reported-by: sashiko-bot Cc: Ingo Molnar Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo [doebel: context adjustment for 5.10] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 3d4a9ae2c69c0fe4c3c69587288241243bb7a39b Author: Sven Eckelmann Date: Wed Sep 9 21:15:28 2026 +0200 batman-adv: bla: avoid CRC corruption due to parallel claim add commit 08645ab95768b88e2ff85a89211994651710465b upstream. batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the "new" claim code was running in parallel to the "change backbone" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the "new" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 800a6dfcf570c4a7e168a6fe515904de56e97148 Author: Jian Shen Date: Mon Jan 6 22:36:39 2025 +0800 net: hns3: don't auto enable misc vector [ Upstream commit 98b1e3b27734139c76295754b6c317aa4df6d32e ] Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq.. Fixes: 7be1b9f3e99f ("net: hns3: make hclge_service use delayed workqueue") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20250106143642.539698-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5cc36ab97caeeb40736c7803521af3e9a7a6ce47 Author: Pengpeng Hou Date: Mon Apr 6 21:52:34 2026 -0700 Input: aiptek - validate raw macro indices before updating state [ Upstream commit 95dffe32a66cbed07fbfa7afed39d56d5014e04f ] aiptek_irq() derives macro key indices directly from tablet reports and then uses them to index macroKeyEvents[]. Report types 4 and 5 also save the derived value in aiptek->lastMacro and later use that state to release the previous key. Validate the raw macro index once before it enters that state machine, so lastMacro only ever stores an in-range macro key. Keep direct bounds checks for report type 6, which reads the macro number from the packet body and uses it immediately. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260329001711.88076-1-pengpeng@iscas.ac.cn [dtor: fix macro fallback in report 5s to use -1] Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit db1200ec2c3ddf119d4d9ba67982063df06bbacb Author: Jiayuan Chen Date: Tue Apr 7 10:26:27 2026 +0800 bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops [ Upstream commit 10f86a2a5c91fc4c4d001960f1c21abe52545ef6 ] When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp. Fixes: fd09af010788 ("bpf: sock_ops ctx access may stomp registers in corner case") Fixes: 84f44df664e9 ("bpf: sock_ops sk access may stomp registers when dst_reg = src_reg") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Reviewed-by: Emil Tsalapatis Closes: https://lore.kernel.org/bpf/6fe1243e-149b-4d3b-99c7-fcc9e2f75787@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Acked-by: Martin KaFai Lau Link: https://patch.msgid.link/20260407022720.162151-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6df5f90175fe4c584e9960b6c00131a7bf2b5399 Author: Zhengchuan Liang Date: Sun Mar 22 11:46:08 2026 -0700 net: af_key: zero aligned sockaddr tail in PF_KEY exports [ Upstream commit 426c355742f02cf743b347d9d7dbdc1bfbfa31ef ] PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Xiao Liu Signed-off-by: Zhengchuan Liang Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 610073ffb77ffd2b5eca182d2ac264de4834a175 Author: Xiang Mei Date: Fri Mar 27 23:30:00 2026 -0700 bridge: mrp: reject zero test interval to avoid OOM panic [ Upstream commit fa6e24963342de4370e3a3c9af41e38277b74cf3 ] br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes. Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface") Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260328063000.1845376-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1da52878f7fb74ace304f74325bb89e3e5546b55 Author: Wang Liang Date: Fri Mar 21 17:03:53 2025 +0800 net: fix NULL pointer dereference in l3mdev_l3_rcv [ Upstream commit 0032c99e83b9ce6d5995d65900aa4b6ffb501cce ] When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan. Suggested-by: David Ahern Fixes: c675e06a98a4 ("ipvlan: decouple l3s mode dependencies from other modes") Signed-off-by: Wang Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250321090353.1170545-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad1754f86a87fe74912fb542b23ff24ada4e3307 Author: Andrei Matei Date: Wed Dec 6 23:11:50 2023 -0500 bpf: Guard stack limits against 32bit overflow [ Upstream commit 1d38a9ee81570c4bd61f557832dead4d6f816760 ] This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904 Reported-by: Andrii Nakryiko Signed-off-by: Andrei Matei Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20231207041150.229139-4-andreimatei1@gmail.com Signed-off-by: Sasha Levin commit 5d5389b2c37ca00da61d1407618ebe15abae0c8b Author: Sechang Lim Date: Wed Sep 9 10:56:45 2026 +0200 tcp: clear sock_ops cb flags before force-closing a child socket [ Upstream commit 990348e5bb457697c2f1f7f7b65154a3334d9d2b ] A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too. Suggested-by: Jiayuan Chen Fixes: d44874910a26 ("bpf: Add BPF_SOCK_OPS_STATE_CB") Signed-off-by: Sechang Lim Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260611092923.1895982-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin [ Moved inet_csk_prepare_for_destroy_sock() to inet_connection_sock.c due to header dependency, Added a guard arount the call to tcp_clear_sock_ops_cb_flags to avoid calling it for DDCP sockets.] Signed-off-by: Miguel Gazquez (Schneider Electric) commit c8124b28f12dbdd126118e63d0ebf8093a01fb81 Author: Arthur Gautier Date: Mon Aug 31 12:04:48 2026 +0300 xhci: fix lost bounce buffers on TDs spanning several ring segments commit ff44dfb03a293bf30e31f98772a1dd316a6071d1 upstream. When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio Signed-off-by: Arthur Gautier Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com [Michal: solved context conflict due to xhci_td_cleanup() type] Signed-off-by: Michal Pecio Signed-off-by: Greg Kroah-Hartman commit 6322b24c062de4705db2d3a25bbc9cd2c666d3c4 Author: Sunil Khatri Date: Thu Aug 27 20:33:35 2026 +0530 drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c upstream. For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c5517b71101f61a45144e3cf77a19626355272de Author: Thadeu Lima de Souza Cascardo Date: Mon Jul 27 17:45:49 2026 -0300 drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used commit 4d4be202165e832d74849b4a68e289a2a377039c upstream. Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com Signed-off-by: Greg Kroah-Hartman commit 2320626425f3af3a25b8afb6876f205b1c6d4e64 Author: Harry Wentland Date: Tue Aug 4 17:04:04 2026 -0400 drm/amd/display: avoid divide-by-zero in __is_lut_linear() commit 4f40873f8a4107df2b9c8e68c947c4fd0cd519d2 upstream. __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero. Fixes: 086247a4b2fb ("drm/amd/display: Use 4096 lut entries") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5310c7410173e9acc574e4f3a186241b657e59a5 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:40 2026 +0200 drm/hibmc: Fix list of formats on the primary plane commit 0e682e136c466ae37c62f18099f591c096260ee0 upstream. Remove all formats from the primary plane that are unsupported for various reasons. * Formats with alpha channel: planes should not announce alpha channels unless they support transparency. There's no transparency support in the primary plane's implementation. * Formats with BGR order. The common format is in RGB channel order. There's no BGR support in the primary plane's implementation. * RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the output is distorted. This can be tested by booting with video=1024x768-24. Removing all unsupported formats leaves XRGB8888 and RGB565. Both of which are supported and work correctly. Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Yongbang Shi Cc: Baihan Li Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 4b3d359eb6ca538a27573da0ec9b5e317a0aaa5a Author: Wentao Liang Date: Sun Jun 7 03:09:50 2026 +0000 drm/sun4i: fix refcount leak in sun4i_backend_init_sat() commit f7a56ff6240e6fd0cb36a3c0a911a1cd54789ce2 upstream. When sun4i_backend_init_sat() calls reset_control_deassert() it increments the deassert_count of the reset controller, and must pair that with a reset_control_assert() call to decrement it. In the error path where clk_prepare_enable() fails, the function returns immediately without calling reset_control_assert(), leaking the reference count. Other error paths, like the devm_clk_get() failure, correctly jump to the err_assert_reset label which performs the missing assert. Fix the leak by using the existing err_assert_reset label in the clk_prepare_enable error path instead of returning directly. Cc: stable@vger.kernel.org Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT") Signed-off-by: Wentao Liang Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260607030950.83636-1-vulab@iscas.ac.cn Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 26d9162213952927cd59c0d94b7e0e992b347bec Author: Danilo Krummrich Date: Sun Jun 28 16:53:36 2026 +0200 drm: fix race between partial drm_dev_register() failure and ioctl commit eb197f7d60f00d0f5b1b3505dfc86a7e36045a3e upstream. If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register(). Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620190648.2E9F61F000E9@smtp.kernel.org/ Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-17-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 95b763f7c52d64ae884ad8a1620e07cc66a63396 Author: Johan Hovold Date: Fri Jul 17 11:08:19 2026 +0200 drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure commit 09b195a7bb23df56269cd2a95d01ba3a5533af13 upstream. Make sure to drop the i2c adapter device and module references before returning when detecting a malformed devicetree during probe. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong Signed-off-by: Johan Hovold Reviewed-by: Luca Ceresoli Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260717090819.1630965-1-johan@kernel.org Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 46395de1d688cccbc85977d6b8dd12aa229fb84a Author: Zhan Xusheng Date: Tue Aug 18 22:55:35 2026 +0800 f2fs: fix i_size when pinned fallocate partially fails commit 0f448bb3767ef6119f5cdeabcae3f10d6e75aed6 upstream. From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 = block 511, so pg_start % sec_blks = 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit a7dbf943ccbfe4151603581f4d32dba8078d9be0 Author: Hao-Qun Huang Date: Wed Jul 8 14:54:39 2026 +0800 f2fs: reject overlapping move range after len expansion commit 28c1ef094e7c86977d9bf570dc0362fc54e36437 upstream. F2FS_IOC_MOVE_RANGE treats a zero length as a request to move data from pos_in to EOF. However, the same-file overlap check runs before that expansion, so a request with len == 0 bypasses the overlap rejection added for same-file moves. For example, with a four-block file, moving from block 0 to block 1 with len == 0 is accepted by the old check because pos_in + len is still pos_in at that point. The code then expands len to cover the rest of the file and calls __exchange_data_block() on overlapping source and destination ranges in the same inode, which is the data-corruption case the overlap check was meant to reject. Move the overlap check after the source range has been validated and len == 0 has been expanded, so it sees the effective length. This is a no-op for non-zero len (the value is unchanged there) and keeps the existing early return for identical positions. Fixes: d95fd91c1ac1 ("f2fs: exclude special cases for f2fs_move_file_range") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 87af7bebfe4ed2f4dc5d4b40ea01e2abf482776c Author: Wenjie Qi Date: Mon Aug 10 21:38:32 2026 +0800 f2fs: return symlink writeback errors commit a2c73a7a677afdaa8b16d775188f9ef5cfbfd8b2 upstream. F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1c820d0900e4aacd5020b989159f6b4b2f7d0d6a Author: Nilesh Javali Date: Thu Jul 30 21:28:34 2026 +0530 scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak commit b93d3bb3afe1b44489927de1eb4e66e8536a5935 upstream. Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-30-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 97484d3c6097ede5a915dd886f460887e5c81443 Author: Nilesh Javali Date: Thu Jul 30 21:28:33 2026 +0530 scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics commit 7c4f3f50d83af4545efaa99b3d0d46fb8d52031e upstream. qla26xx_dport_diagnostics() streaming-maps the caller's result buffer with dma_map_single(). The bsg path passes &dd->buf from the __packed struct qla_dport_diag, where buf lands at a 2-byte offset and shares cachelines with the surrounding options/unused fields. Mapping such a misaligned sub-buffer violates the DMA API requirement that streaming buffers be cacheline aligned and not share a cacheline with other data, and can corrupt data on non-DMA-coherent architectures. Allocate a dedicated DMA-coherent buffer inside qla26xx_dport_diagnostics() for the mailbox command and copy the result back into the caller's buffer. This removes the streaming map of the misaligned sub-buffer entirely; the caller's buffer is now only a plain CPU buffer, so its packing no longer matters. Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-29-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 928e733dfa8b1828f98e0ec7db9aeaeb6a49fb02 Author: Nilesh Javali Date: Thu Jul 30 21:28:27 2026 +0530 scsi: qla2xxx: Drop vport reference under lock in report ID acquisition commit 1154b16439ffc562f9461494c4508c63446eb684 upstream. qla24xx_report_id_acquisition() format-1 handling takes the vport reference under vport_slock but drops it outside the lock, after setting vp->vp_flags and vp->dpc_flags: set_bit(VP_IDX_ACQUIRED, &vp->vp_flags); set_bit(REGISTER_FC4_NEEDED, &vp->dpc_flags); set_bit(REGISTER_FDMI_NEEDED, &vp->dpc_flags); atomic_dec(&vp->vref_count); Neither set_bit() nor atomic_dec() imply a memory barrier, so on a weakly ordered architecture the decrement can become visible before the flag stores. qla24xx_deallocate_vp_id() polls vref_count under vport_slock and unlinks the vport once it reads zero, after which qla24xx_vport_delete() frees it via scsi_host_put(). The poller could therefore observe vref_count == 0 early and tear the vport down while the pending vp_flags/ dpc_flags stores land on freed memory. Drop the reference under vport_slock, as is done for the matching increment and by every other vref_count user. The unlock release pairs with the deallocate poller's lock acquire so the flag stores are ordered before vref_count == 0 can be observed. Fixes: 793cedee296f ("scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-23-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit c845f2597787ef70159a32566669e308b2807a56 Author: Nilesh Javali Date: Thu Jul 30 21:28:21 2026 +0530 scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() commit deb8abde83a799d2501f3977f6d6051000253f5e upstream. qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference. Fixes: a6fe35c052c4 ("[SCSI] qla2xxx: Avoid invalid request queue dereference for bad response packets.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-17-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 125b12861c726e58448bb95d55b04851fb131d1f Author: Nilesh Javali Date: Thu Jul 30 21:28:20 2026 +0530 scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read commit ca6d880d6c70cb7946e7b3e05d7285f271b6d99e upstream. In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: if (IS_FWI2_CAPABLE(ha)) { sense_data += rsp_info_len; par_sense_len -= rsp_info_len; } rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): if (sense_len > par_sense_len) sense_len = par_sense_len; memcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites. Fixes: 5544213be7b4 ("[SCSI] qla2xxx: Correct extended sense-data handling.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-16-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 71a7b6e3c7f121439f51a058e53d4a8e05b63dec Author: Nilesh Javali Date: Thu Jul 30 21:28:25 2026 +0530 scsi: qla2xxx: Avoid double completion in async IOCB timeout commit bb45bc4bd53c95a7bf6f782577b5ede94c0f8aa8 upstream. qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout(). Fixes: f6145e86d21f ("scsi: qla2xxx: Fix race between switch cmd completion and timeout") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-21-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 178d984e8875292582e4295cf559b2b11d3c9325 Author: Nilesh Javali Date: Thu Jul 30 21:28:12 2026 +0530 scsi: qla2xxx: Don't query firmware state while chip is down commit e0cebe20dcffbed9c078fe30e2d18cd5046d9eff upstream. qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy. Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-8-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit b0c08c08a08b6cca0e7e192bcbe0514e41fcc55f Author: Nilesh Javali Date: Thu Jul 30 21:28:14 2026 +0530 scsi: qla2xxx: Fix FCE trace enable parsing in debugfs commit b7368687e3d11f51392d3c4774ec0263d5fbf31f upstream. qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as "disable" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-10-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f8fc5cc6b3284506c6ab83c822c48133377668bb Author: Nilesh Javali Date: Thu Jul 30 21:28:13 2026 +0530 scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() commit 9efaa782845b4d5fb3e01242be0d06ebc7428d8f upstream. The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents. Fixes: 4d4df1932b6b ("[SCSI] qla2xxx: Add ISP84XX support.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-9-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 423487f03e325b8665d20a2a3171fe012b1a4fa9 Author: Nilesh Javali Date: Thu Jul 30 21:28:15 2026 +0530 scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump commit 53298efcbbb0f0438366d45cb7ed7e6d93dd5531 upstream. qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-11-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8c1ebcade6aac58137f2645b579894301febabf3 Author: Nilesh Javali Date: Thu Jul 30 21:28:11 2026 +0530 scsi: qla2xxx: Fix cs84xx use-after-free on host teardown commit 33d102102d925357c5fd172dd6672a27d74b3215 upstream. qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed. Fixes: fe1b806f4f71 ("[SCSI] qla2xxx: Refactor shutdown code so some functionality can be reused.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f1fc052f2a5890ea6dba80d50254dd6258b13386 Author: Nilesh Javali Date: Thu Jul 30 21:28:08 2026 +0530 scsi: qla2xxx: Serialize flash version read in reset handler commit f606ed93de0c4f1e7e3618779e9fad731455314a upstream. The "update cache versions without reset" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path. Fixes: 8c2cf7d4e387 ("[SCSI] qla2xxx: Add a new interface to update versions.") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-4-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit cf623d32761b00f221a9cfded3303d56e84b429d Author: Nilesh Javali Date: Thu Jul 30 21:28:06 2026 +0530 scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation commit ebfd35c64433821bd5619a6d07ccc2df8b5b1de3 upstream. ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as "ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->max_req_queues--" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following "ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs). Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-2-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit af733bbfcf667af1871a2735fba2835b0da71efb Author: Nilesh Javali Date: Thu Jul 23 10:34:12 2026 +0530 scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() commit de62cf265dbe309f34f144a6cdbca9240317727e upstream. qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-56-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e6e6ddc3e2973c0703e7cc5e6462fef019a1faa4 Author: Nilesh Javali Date: Thu Jul 23 10:34:06 2026 +0530 scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config() commit 9101c51649f5b6773a97bf5271785c948589ea1d upstream. The Modify VP Config completion handler labelled its first error branch "error status" but tested vpmod->comp_status instead of vpmod->entry_status. Because CS_COMPLETE is 0, the following "comp_status != CS_COMPLETE" branch duplicated that test and was dead code, and entry_status was never examined at all. When firmware rejects the IOCB early it sets entry_status while leaving comp_status zero. As the IOCB is allocated with dma_pool_zalloc(), both comp_status branches evaluate false and the handler falls through to the success path, calling fc_vport_set_state(FC_VPORT_INITIALIZING) for a configuration the firmware never accepted. This can leave the virtual port enabled on top of an invalid config and surface later as login timeouts or follow-on firmware errors. Test entry_status in the first branch, matching qla_ctrlvp_completed() and the login/logout/abort/reset IOCB handlers; the comp_status branch then becomes the live completion-status check. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-50-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit d09ef32af1e05d79f29b460521a20bc4e6fd2ecf Author: Nilesh Javali Date: Thu Jul 23 10:34:07 2026 +0530 scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() commit 793cedee296fd819bfadc2a7ec4d52faf9c09a0a upstream. In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-51-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2572adee2a37405bc6d844d21a30a5238949f9ce Author: Nilesh Javali Date: Thu Jul 23 10:34:04 2026 +0530 scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters commit eb137255fd7aa834c4d639ae7b5e9e8ecf3a4fb2 upstream. In the CS_PORT_LOGGED_OUT case of qla2x00_chk_ms_status(), the FWI2-capable branch compared ms_pkt->loop_id.extended against NPH_SNS to decide whether the Name Server had logged out. On FWI2 and later adapters the response is a ct_entry_24xx / ct_entry_24xx_ext, where loop_id.extended (via the legacy ms_iocb_entry_t view) aliases offset 8, which is comp_status, not nport_handle (offset 10). As this code runs under CS_PORT_LOGGED_OUT, the field read back 0x29 (CS_PORT_LOGGED_OUT) and the comparison against NPH_SNS (0x7fc) was always false. As a result the driver never recognized a Name Server logout on FWI2/ 29xx adapters: it returned the generic QLA_FUNCTION_FAILED instead of QLA_NOT_LOGGED_IN and skipped setting LOOP_RESYNC_NEEDED / LOCAL_LOOP_UPDATE, so the fabric rediscovery triggered by an SNS logout did not happen. Read nport_handle from the ct_entry_24xx layout (offset 10) instead. nport_handle is at the same offset in ct_entry_24xx and ct_entry_24xx_ext, so a single cast covers 24xx-class and 29xx. The non-FWI2 branch keeps using loop_id.extended, which is correct for the ms_iocb_entry_t response on those adapters. Fixes: b98ae0d748db ("scsi: qla2xxx: Fix name server relogin") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-48-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8f01f886cc5e7bbc16cbf1a9928fdebbc911e973 Author: Nilesh Javali Date: Thu Jul 30 21:28:37 2026 +0530 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers commit 0918ee2c0eeb4d7f45b82b3dc11e65c2d9b7ad59 upstream. struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers. Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-33-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a476377a66897549dd49bee319f4df66623417b7 Author: Nilesh Javali Date: Thu Jul 30 21:28:36 2026 +0530 scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers commit b47d4a1547d9ef21b2e9d1a739fe2204d4be05dc upstream. The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-32-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit ce04d1ab5563479f2982cf6ab949c0049f7b4e46 Author: Arash Golgol Date: Wed Jul 22 20:14:51 2026 +0330 media: vimc: fix pixel format lookup in enum_framesizes commit ad4c65fa30cfb00e2e06adae9a8eb407086eaa66 upstream. vimc_capture_enum_framesizes() looks up the requested format using vimc_pix_map_by_code(), which searches the pix map table by media bus code (MEDIA_BUS_FMT_*). However, v4l2_frmsizeenum::pixel_format holds a V4L2 pixel format (V4L2_PIX_FMT_*), not a media bus code, so valid pixel formats end up being rejected with -EINVAL. Fix this by using vimc_pix_map_by_pixelformat() instead, which performs the lookup by pixel format as the ioctl expects. Fixes: 09c41a23a2e2 ("media: Revert "media: vimc: propagate pixel format in the stream"") Cc: stable@vger.kernel.org Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit db0f4531aa55cfb0171684ebfffe3ff04b79d5a8 Author: Uday Khare Date: Mon Jul 6 20:58:33 2026 +0530 media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure commit 76e379754ba618989f6215be608d5c04774a611d upstream. kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path. Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver") Cc: stable@vger.kernel.org Signed-off-by: Uday Khare Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9a4a98e259f9050d647fa8dfd931148c6bc62e38 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:55 2026 +0100 media: venus: fix payload size calculation in parse_raw_formats() commit bd595b745eb770e80347c31ffc25351046935305 upstream. The consumed size is computed after the loop using the num_planes value from the last iteration for all entries. When entries have different plane counts, this produces an incorrect total. Accumulate the actual size during the loop instead. Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 54c003a72d339f2b7d31a58904592c2873a8e77b Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:54 2026 +0100 media: venus: fix payload size returned by parse_caps() and parse_alloc_mode() commit a51cea23e409278f6e2ea072280aba93cc1dd75e upstream. parse_caps() and parse_alloc_mode() return only the size of their fixed header fields, excluding the flexible array payload. hfi_parser() uses this return value to advance through the firmware response buffer, so underreporting causes parser desynchronization. Return the full consumed size (header + entries), matching the correct pattern used by parse_profile_level(). Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit c9b5238d173ee9b94dcaa2b34244ea89c8024feb Author: Biren Pandya Date: Fri Jun 19 13:41:30 2026 +0530 media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link commit a6e86efd7f85e519bf48417f41923f8bd51f1597 upstream. In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. Signed-off-by: Biren Pandya Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Cc: stable@vger.kernel.org [Sakari Ailus: Fix subject prefix and coding style a little.] Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit cf8e3b3d7d9a6a96f4df6246e2e14b32f58d889e Author: Ilya Krutskih Date: Sun Jul 19 13:08:35 2026 +0000 media: tda18250: fix possible integer overflow commit 6dd8e257f7cafda7fbf10d81b3c55c9bba4825f4 upstream. Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior. Fixes: 148abd3b5b14 ("media: tda18250: support for new silicon tuner") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6f6a5b0b0a84c2de0e152f2841e57bc226db924f Author: Lei Huang Date: Tue Jul 14 14:52:02 2026 +0800 media: s2255: check firmware size before reading trailing marker commit 330f2936ab768c7215322a476f033143e8891d28 upstream. s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing. Fixes: 14d962602c8b ("V4L/DVB (8752): s2255drv: firmware improvement patch") Cc: stable@vger.kernel.org Signed-off-by: Lei Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 32a595dd3e8634544e5cfbc47f906dff3d3c1ef8 Author: HyeongJun An Date: Wed Jul 1 20:45:36 2026 +0900 media: s2255: bound JPEG frame size before copying into the buffer commit e504cc888f42999dd76b6a43788c422610f2aad2 upstream. s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: payload = le32_to_cpu(pdword[3]); if (payload > vc->req_image_size) /* payload is checked ... */ return -EINVAL; vc->pkt_size = payload; vc->jpg_size = le32_to_cpu(pdword[4]); /* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it. Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f14a713a36a5c87568430e9770896f2a8f5bbbb7 Author: Valery Borovsky Date: Sat May 23 19:53:58 2026 +0300 media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure commit fe50cdaebf12cd32ff9a44d92bfd6fbc2300dbd4 upstream. rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 234c46b95a032232e31fa5987b84fb8f87a9693b Author: Valery Borovsky Date: Sat May 23 19:53:37 2026 +0300 media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak commit dabb047c62668f280998e29117c55e41aabac336 upstream. rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 276f28672bb6d5d5feca78db4219c7b5adf1be26 Author: Christian Hewitt Date: Wed Jun 24 06:58:08 2026 +0000 media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common commit 20aa934ace6917262ff579a73ec018d06a7bad1c upstream. When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9e4693436c7dcf8584002500ce4b434b79bbf9ed Author: Biren Pandya Date: Wed Jul 8 18:27:23 2026 +0530 media: i2c: ov7740: fix use-after-destroy in remove commit 5d1b3dea5a44124bab6c14a2d71b977dabed54e7 upstream. The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order. Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1c57d1a3396b2d767d58f10dff09bb397586c714 Author: Shuangpeng Bai Date: Mon Jul 6 16:50:15 2026 -0400 media: go7007: defer the ALSA v4l2 put until card release commit 1bd456afeb8a515137e567967069fce6f8fcd23e upstream. go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime. Closes: https://lore.kernel.org/r/178144969601.60470.6005237146425573205@gmail.com Fixes: d5d3a7cc127d ("[media] go7007: fix unregister/disconnect handling") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f61720346fdcc1a2deec59a2f6cbb0cc20d1dc18 Author: Jiangong.Han Date: Tue Jun 30 22:54:34 2026 +0800 media: em28xx: fix use-after-free of dev_next->devlist on disconnect commit 826915b6b65e2d3251e7248ea54289a22d748c84 upstream. When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed. Fixes: f410b4093fdd ("media: em28xx: split up em28xx_dvb_init to reduce stack size") Cc: stable@vger.kernel.org Reported-by: syzbot+99d6c66dbbc484f50e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=99d6c66dbbc484f50e1c Signed-off-by: Jiangong.Han Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0da1e627f4fc9d0e947fdae90913042120878923 Author: Diego Fernando Mancera Gomez Date: Thu Jul 23 12:22:42 2026 -0600 media: em28xx: defer audio-only extension registration commit 95f76f51937fdfb0fc1e14cae606b1ef574a56f3 upstream. The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next. Fixes: 4a089668ef22 ("media: em28xx-cards: rework the em28xx probing code") Cc: stable@vger.kernel.org Reported-by: syzbot+a11c46f37ee083a73deb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66ec3c83.050a0220.29194.002f.GAE@google.com/T/ Suggested-by: Fedor Pchelkin Signed-off-by: Diego Fernando Mancera Gomez Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit aaf76794b870b0f391eff339252a2e2e22f33a4a Author: Fan Wu Date: Mon Jul 20 13:17:08 2026 +0000 media: cx23885: cancel NetUP CI work before teardown commit 4e143d662ca94888b494b2427fc9e34494eb933a upstream. netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool. Fixes: c184dcd28233 ("V4L/DVB (10798): Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit aa3314506deb9703bcf0e889db08959440228fbf Author: Bryam Vargas Date: Mon Jun 15 18:40:48 2026 -0500 media: cx231xx: reject geometry changes while the VBI queue is busy commit 627a121c15fe05a541f44d86016294b80bada75d upstream. vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: offset = lines_completed * (dev->width << 1) + ...; if (dma_q->current_field == 2) offset += dev->width * 2 * dma_q->lines_per_field; memcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer. Fixes: 7c617138b825 ("media: cx231xx: convert to the vb2 framework") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 75bbf45e3a954e292ae26832d2df40ca2e3ee452 Author: Ruoyu Wang Date: Wed Jul 8 22:33:38 2026 +0800 media: cobalt: Avoid freeing ALSA private data twice commit 3a7d6b9c4cb5ac18cbd3f1c7f8c7b159c42ba0b1 upstream. snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85756a069c55 ("[media] cobalt: add new driver") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6fabacc3b79a528450aef4c32464da2ec681049e Author: Dawei Feng Date: Wed Jun 24 16:59:20 2026 +0800 media: cedrus: fix memory leak in cedrus_init_ctrls() commit 9df2fbe563194da1967a5db083442186c1323efe upstream. In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Acked-by: Jernej Skrabec Reviewed-by: Dan Carpenter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit efc829b4b937f98c4467bffe9243f756b7cfbf7f Author: Ruoyu Wang Date: Wed Jul 8 11:01:02 2026 +0800 media: cec: Serialize exclusive follower delivery commit 1924d0788caa6c66fd320dd4704fae99487fd2c7 upstream. cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release. Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bbd924b8e23c853d7be40e31f826e44b23d24124 Author: Yi Ding Date: Thu May 28 23:00:05 2026 -0700 media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid debugfs clash commit 172c5a7d81deb922ddedd1bc920751c7fed6c43c upstream. The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become ".cec" and ".cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Reviewed-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c9081e2655188d2d134a741aec837dc70439d505 Author: Valery Borovsky Date: Sat May 23 19:53:49 2026 +0300 media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref commit 2f378dc45e685fc825d2dd08e7864666d6fcc009 upstream. airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d2e6a5224de92db78c3c07b513403f861628dafc Author: Christian Borntraeger Date: Tue Aug 11 17:37:38 2026 +0200 KVM: s390: Restore sigset on error path commit c44d36d8e6501c4934412d9014e5e02da9efdb8f upstream. kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit d8d16b864b7a95f57b471ab6e2bf599d34cba0e4 Author: Christian Borntraeger Date: Wed Aug 5 13:04:50 2026 +0200 KVM: s390: Zero initialize irq in reinject_machine_check commit b239410c7653ff6781d4cf1d63cfc52a1bb71788 upstream. kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 053f2068cf9b0654b651fed5ad7649d3deb982bf Author: Christian Borntraeger Date: Wed Aug 5 13:04:54 2026 +0200 KVM: s390: Free guest debug data on vcpu destroy commit e7f698b09d4a7c36b299acf680fc50fe868e2bcd upstream. kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-8-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 124c81ee610e1fbdd93d4399f88d9e28ba97a941 Author: Christian Borntraeger Date: Wed Aug 5 13:04:52 2026 +0200 KVM: s390: Fix old_data leak in guest debug error path commit aa9c8e8baf1e765fa65b93212522c636f25d846f upstream. __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-6-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 39e7cebb889839b5762c9ad22e2d715b5883b288 Author: Christian Borntraeger Date: Wed Aug 5 13:04:51 2026 +0200 KVM: s390: Fix memory leak in guest debug handling commit 121ea1de927c8b9bfdf53c31cad27b86d5de0293 upstream. bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit a4665762388750e08df99baabe5fce2a21d1423e Author: Carlos López Date: Tue Jul 14 15:32:13 2026 +0200 KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock commit 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf upstream. Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d077 R09: 1ffffffff1f87a0e R10: dffffc0000000000 R11: fffffbfff1f87a0f R12: dffffc0000000000 R13: 0000000000000000 R14: ffff8880b8628240 R15: 1ffff92000814e64 hrtimer_start include/linux/hrtimer.h:259 [inline] stimer_start arch/x86/kvm/hyperv.c:682 [inline] kvm_hv_process_stimers+0xd0a/0x16a0 arch/x86/kvm/hyperv.c:893 vcpu_enter_guest arch/x86/kvm/x86.c:11193 [inline] vcpu_run+0x2240/0x76b0 arch/x86/kvm/x86.c:11639 kvm_arch_vcpu_ioctl_run+0x1148/0x1c90 arch/x86/kvm/x86.c:11984 kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4492 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f635278f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f635365c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f63529e5fa0 RCX: 00007f635278f749 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00007f6352813f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f63529e6038 R14: 00007f63529e5fa0 R15: 00007ffd5b219358 Fix this by clamping the deadline computation to KTIME_MAX, which preserves the intent of arming a timer very far in the future. ktime_add_safe() already does this type of clamping, so use it after checking that that multiplying by the 100ns time tick also does not overflow. Reviewed-by: Vitaly Kuznetsov Reported-by: syzbot+3d5461510f8dc4adfe30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d5461510f8dc4adfe30 Fixes: 1f4b34f825e8 ("kvm/x86: Hyper-V SynIC timers") Cc: stable@vger.kernel.org Signed-off-by: Carlos López Link: https://patch.msgid.link/20260714133212.3916611-3-clopez@suse.de [sean: tag for stable] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e798dd46f0c321c758f112899ec5d4f4ab9de0e5 Author: Sanjay Chitroda Date: Thu Jun 25 17:46:11 2026 +0530 iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register() commit 967d066f5334740f656577bc51c381a1bb707b61 upstream. Avoid using devm_iio_device_register(), as this driver requires explicit error handling and teardown ordering. With devm_iio_device_register(), IIO device remains registered until the devres cleanup phase. However, driver's remove() callback removes the sensor hub callback and trigger support. This can create a race window where IIO device is still visible and read_raw() requests are issued. These requests might call sensor_hub_input_attr_get_raw_value(), which waits up to 5 seconds for a response from the sensor hub callback that has already been removed. Add an explicit iio_device_unregister() call in the teardown path to ensure deterministic cleanup, so that userspace can no longer access the device once backend resources begin to be dismantled. Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support") Cc: stable@vger.kernel.org Reviewed-by: Maxwell Doose Reviewed-by: Andy Shevchenko Signed-off-by: Sanjay Chitroda Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a213bc00e04eb1576c34a62fd796b5430bae7444 Author: Cong Nguyen Date: Mon Jul 27 22:51:15 2026 +0700 iio: srf04: fix pm_runtime handling on probe error path commit a40b2e7a17f26e38ab054363c9c7cde149588357 upstream. When pm_runtime_set_active() fails during probe, the driver logs the error and unregisters the IIO device, but then falls through and still calls pm_runtime_enable() before returning the error. Since probe returns an error, srf04_remove() is never called, so runtime PM is left enabled without a matching pm_runtime_disable(). This leaks the enable and triggers an "Unbalanced pm_runtime_enable!" warning on a subsequent bind of the device. Return the error right after unregistering the IIO device so that runtime PM is not enabled on the failure path. Fixes: 2251157b335b ("iio: srf04: add power management feature") Cc: stable@vger.kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 001fbc4ea091a7879370d5e7c4892a056d92b0c1 Author: Laxman Acharya Padhya Date: Sat Jul 4 14:19:12 2026 +0545 iio: light: gp2ap002: Disable regulators on resume failure commit a41000ba3a230bed1e422f283486ff8f77fe0d30 upstream. If enabling VIO fails after VDD has been enabled, runtime resume returns without disabling VDD. Likewise, if device reinitialization fails, both supplies remain enabled. The runtime PM core keeps the device suspended when its resume callback fails, so the supplies must be restored to the suspended state. Disable the supplies enabled by the callback before returning an error. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Reviewed-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 265e91d184099be1668372fcea6ce7ef40a7678a Author: Giorgi Tchankvetadze Date: Fri Jul 31 17:20:48 2026 +0400 iio: light: cm32181: return zero after writing calibscale commit 8756acd30919a3e9f547ea4a1d4b7f7895f4d340 upstream. The write_raw callback is documented to return 0 on success or a negative error code. However, the IIO_CHAN_INFO_CALIBSCALE case returns 'val' (the user-supplied value) instead of 0. Fix it by returning 0 on success, matching the behavior of other calibscale implementations in the subsystem. Fixes: 971672c0b3cc ("iio: add Capella CM32181 ambient light sensor driver.") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1b66486e632c2e9a209d7e34c97f3a024b6b4e74 Author: Cong Nguyen Date: Sun Aug 2 13:55:40 2026 +0700 iio: gyro: mpu3050: fix sign of raw angular velocity readings commit 06fab97602fe400bea843176f485bbac07a668e2 upstream. The MPU-3050 gyroscope output registers hold 16-bit two's complement values; the angular velocity channels are declared with .sign = 's'. When mpu3050_read_raw() handles IIO_CHAN_INFO_RAW it reads the register via a big-endian regmap_bulk_read() and assigns it with: *val = be16_to_cpu(raw_val); be16_to_cpu() yields an unsigned 16-bit quantity, so negative rates (bit 15 set) are reported to userspace as large positive integers (e.g. -1 becomes 65535) instead of the correct negative value. Cast to s16 before the assignment, matching the temperature channel a few lines above which already handles the sign correctly. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Linus Walleij Reviewed-by: Joshua Crofts Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bac0ed8bee651aa841375edf72c6ab1d10ac80c6 Author: Erick Henrique Date: Fri Jul 3 17:52:36 2026 -0300 iio: dac: m62332: Fix regulator reference count imbalance commit a130404ce0b69ca1438126bd81c1985d3b4d2e6f upstream. m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails. Fixes: b87b0c0f81e8 ("iio: add m62332 DAC driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260418130322.106769-1-erick.henrique.rodrigues%40usp.br Cc: stable@vger.kernel.org Signed-off-by: Erick Henrique Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bffd0655a35402b2df8857699f8248e5a534d214 Author: Linmao Li Date: Wed Jul 22 15:48:37 2026 +0800 iio: chemical: sgp30: Handle IAQ thread creation failure commit 1135d6875d2dbda3f6ec718f3421a6ce4378bd63 upstream. kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead. Fixes: ce514124161a ("iio: chemical: sgp30: Support Sensirion SGP30/SGPC3 sensors") Signed-off-by: Linmao Li Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3945c5a89402ed7fcafbbd64554519bd87334fc0 Author: WenTao Liang Date: Sat Jun 27 11:52:51 2026 +0800 ASoC: samsung: aries_audio_probe: double of_node_put due to direct assignment without of_node_get commit fb5d1b1c5f8a920ee697545fa6dee16825085717 upstream. In aries_audio_probe(), aries_dai[0].platforms->of_node is assigned the same pointer as aries_dai[0].cpus->of_node (from of_parse_phandle) without calling of_node_get(). When the sound card is deregistered, the ASoC framework calls of_node_put() on both cpus->of_node and platforms->of_node, causing a double put on the same node and a refcount underflow. Add of_node_get(aries_dai[0].cpus->of_node) before the assignment. Cc: stable@vger.kernel.org Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260627035251.60172-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1c90fb59a73e705b81d9cd1df420db75084835fa Author: Haoxiang Li Date: Mon Jun 22 17:16:20 2026 +0800 AsoC: intel: sst: fix PCI device reference leak on probe failure commit 016f29997ebd29d6ab59c8162ce0e7f73bd1e517 upstream. intel_sst_probe() takes a reference to the PCI device with pci_dev_get(). If sst_platform_get_resources() fails afterwards, the probe error path cleans up the driver context but does not drop the PCI device reference. Add a pci_dev_put() error path for failures after pci_dev_get(). Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622091620.897478-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ea80ada9e71adfe1dc7fc42790e153b0edb6b912 Author: Haoxiang Li Date: Mon Jun 22 17:48:22 2026 +0800 ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure commit 3a89ddcf0c3d9a068631e8c24d5c9e81d1e6512a upstream. mpc5200_audio_dma_create() creates the DMA resources before registering the component. If snd_soc_register_component() fails, the function returns directly and leaves the DMA resources allocated. Call mpc5200_audio_dma_destroy() before returning from this error path. Fixes: f515b67381de ("ASoC: fsl: mpc5200 combine psc_dma platform data") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622094822.926166-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3be8380fb14d602cd833e5852e6d83c1e7eb1ceb Author: Runyu Xiao Date: Fri Jun 12 00:15:53 2026 +0800 ASoC: cs35l34: drain threaded IRQ before runtime suspend commit 4105a4c0678b2808fc8046b60321b4f1cc7dae75 upstream. cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-3-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d07799302721d381aef834fac8a11d196894eccb Author: Runyu Xiao Date: Fri Jun 12 00:15:52 2026 +0800 ASoC: cs35l33: drain threaded IRQ before runtime suspend commit e074c12c428c633e079154301207a6079a208583 upstream. cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-2-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a605890d6e92241fb686f86ec39c368278cb7802 Author: Linkai Gong Date: Thu Aug 13 17:56:17 2026 +0800 i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure commit 62edb8ca0aa44517cc23cfa26cd8a51f15ea92fe upstream. of_parse_phandle() takes a reference on the parent node. If a later devm_kstrdup() fails, err_rollback only releases nodes for indices 0..i-1, so the current node is leaked. of_node_put() the current parent before rolling back. Fixes: 7c0195fa9a9e ("i2c: mux: demux-pinctrl: check the return value of devm_kstrdup()") Signed-off-by: Linkai Gong Cc: # v6.6+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813095617.2246320-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 445a2199cd70668869b80dbaa2f3bb19e8a5b96c Author: Stephan Gerhold Date: Mon Jul 6 17:02:09 2026 +0200 clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk commit fc611445b021262b0d4ace6f716a360663816287 upstream. MSM8939 is similar to MSM8916, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-2-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 8e37e08732bd4ed8f53dac1fca271f200a1f688a Author: Stephan Gerhold Date: Mon Jul 6 17:02:08 2026 +0200 clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk commit c5339edc6abb601ea10df910ea0b1592fa1016f3 upstream. According to the APQ8016E TRM, the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-1-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit fa1c615942cc0e5dccbe830188635e7e7825f72f Author: Sven Eckelmann Date: Sun Jul 5 22:21:50 2026 +0200 batman-adv: bla: prevent CRC corruptions after claim flush commit 89f3502ff6878798be96461b2eebd64ba3c3874c upstream. When batadv_bla_del_backbone_claims() tried to remove all claims of a backbone, it sets the CRC to 0. It assumes that the it had the last reference of the claims because batadv_claim_release() (which runs after the last reference was released), is XORing the crc16 of the claim address with the backbone CRC. If there would be a parallel holder of any of these references, it could happen that the backbone CRC is (0 ^ crc16(delayed_released_claim)). Which is the wrong starting point for the new claims it may receive when the remote answers the claim request from batadv_bla_send_request(). This reinitializations can be completely dropped to avoid this problem. batadv_claim_release() will take care of fixing the backbone CRC. Cc: stable@vger.kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 844a95a734f178d56c7acce14c5cce2cecff7e1a Author: Sven Eckelmann Date: Wed Jul 22 12:08:09 2026 +0200 batman-adv: bla: fix freeing of claims on meshif deletion commit 8d128c932bced74e3b1625ba3d7c78ef122a88a7 upstream. When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b1bbc694ca51adb8dbed3f3235b4fcbdb44e0e20 Author: Sven Eckelmann Date: Mon Jul 6 19:46:37 2026 +0200 batman-adv: dat: avoid unaligned fault in IP extraction commit 0121afa52cdb88cfb4d5d7bd126a23a9100121d8 upstream. Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 5c3a0e553593 ("batman-adv: Distributed ARP Table - add ARP parsing functions") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 63d86250fa7cbe22451369bd1c0881dfc8190958 Author: Zhiling Zou Date: Fri Jul 31 11:18:49 2026 +0800 batman-adv: fix stale receive device on merged fragments commit ad46c907d7d9975a285c1e89a4adde652eaa93f5 upstream. Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 1bf148fabe6463422195b7cc43b3412533f1dc21 Author: Pengpeng Hou Date: Mon Jul 20 19:57:25 2026 +0800 mtd: rawnand: validate ONFI extended parameter page sections commit e5e415262330bd70f983e091d8919d9dcd99e475 upstream. nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section. Fixes: 6dcbe0cdd83f ("mtd: get the ECC info from the Extended Parameter Page") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 477d61d54e097e90f748aa18d013805abd56bcbd Author: Xu Rao Date: Mon Jul 13 13:22:03 2026 +0800 mtd: mtdoops: free page bitmap when the backing MTD is removed commit 956e7da12c114f13c63d126ab1d79c3b6a819060 upstream. mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event. Fixes: be95745f0167 ("mtd: mtdoops: keep track of used/unused pages in an array") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 1bec05a68414cf8d0cab6cb42445b8603f32ffc4 Author: Pengpeng Hou Date: Wed Jul 8 09:49:06 2026 +0800 mtd: afs: validate v2 image info bounds commit e9290031f736e99ad17c25c00311c92c266843b7 upstream. The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries. Fixes: b7cf5e2830bb ("mtd: afs: add v2 partition parsing") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Acked-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit e7cfa16c95f4c30b8333b01af3e8c3e6ad3996ff Author: Helge Deller Date: Sat Aug 15 11:59:20 2026 +0200 parisc: Fix alignment of asm statements in head.S commit 04cf68c9a76e3c6b67ad056a66a14923abf85925 upstream. All assembler statements need to be 4-byte aligned. Prevent a possible misalignment if someone changes the preceeding string and it's length is then suddenly not a multiple of 4 any longer. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 68659b627770f3c8d8f578e8ddee78a07d5f1d0e Author: Pei Xiao Date: Mon Aug 17 11:29:25 2026 +0800 parisc: eisa: Fix infinite loop when parsing invalid IRQ value commit 8b585431a16cfb9d8f2955a9fa0787ce3dceb3c2 upstream. When an invalid value is passed via the "eisa_irq_edge=" kernel command line parameter (e.g. "eisa_irq_edge=16,5"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally. Signed-off-by: Pei Xiao Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit eb491343d2d1784121ad9af91c25b338c28913c3 Author: Bryam Vargas Date: Sat Jun 20 16:41:31 2026 -0500 nvdimm/btt: reject an arena whose nfree is below the lane count commit 6a1f2e5ed9267ca19187038ac635393c165213ac upstream. The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant. Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Tested-by: Alison Schofield Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit 41f594ae654b369666a9e385609c557e654b4b9f Author: caina Date: Fri Aug 21 17:17:20 2026 +0800 Revert "irqchip/mbigen: Fix mbigen node address layout" commit e67091609cf85962f64391c1b0f93d4cbfcd4e22 upstream. This reverts commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20. Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 -> all in node 9 enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 <- node 9 enahisic2i1-rx5 pin 1215 count 1 <- node 9, last pin enahisic2i1-tx5 pin 1216 count 0 <- node 10, first pin enahisic2i1-rx6 pin 1218 count 0 <- node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 -- so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. Fixes: 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ("irqchip/mbigen: Fix mbigen node address layout") Suggested-by: Marc Zyngier Signed-off-by: caina Signed-off-by: Thomas Gleixner Acked-by: Yipeng Zou Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 02341ee424fb2eed16b5b8a9d247492e49335c21 Author: Shivam Kumar Date: Thu Aug 27 15:24:55 2026 -0400 nvmet-tcp: reject unsolicited H2CData PDUs commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit a3f0bcfbaf3312a5754d1ce020a07d394669eb25 Author: Shivam Kumar Date: Fri Aug 14 15:48:11 2026 -0400 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit df74950ba6008655d4a977d17df7faf4b6e52b74 Author: Yehyeong Lee Date: Tue Aug 18 20:04:05 2026 +0900 nvme-tcp: check the data direction of a C2HData PDU commit f83af377c148f6ad94b41c0e8313f12adf45e1c1 upstream. nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b1d12144557fceed5de6e22e2c2e30a40ed37702 Author: Takashi Iwai Date: Fri Aug 28 13:55:39 2026 +0200 ALSA: pcm: Fix race between non-atomic ops and trigger-start commit acac7b5e07349a9d10d78873afb4b93cd1dc721f upstream. We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4f42f70afd2447f3c82ca69d1e03466a75348ba9 Author: Ahmad Byagowi Date: Sun Aug 23 09:34:36 2026 -0700 i2c: mux: Fix channel node leak on adapter add failure commit 385c7af4e3b95d0769fd211831674e83b16a2ebf upstream. i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data. Fixes: bc45449b1444 ("i2c/of: Automatically populate i2c mux busses from device tree data.") Signed-off-by: Ahmad Byagowi Cc: # v3.5+ Acked-by: Peter Rosin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/b3e46bbee781b3cb4029aca9a71316cc5e36dc17.1787502619.git.ahmadexp@gmail.com Signed-off-by: Greg Kroah-Hartman commit f3705db4e6378cc1b91a38ce0fe2f879055e23ca Author: Dapeng Mi Date: Tue Jun 16 12:46:50 2026 +0800 perf/x86/intel: Fix kernel address leakages in LBR stack commit e2b0575900ff72aa82748af96e7bd564ade5157a upstream. Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: Ian Rogers Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-5-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 90a5455946892778f67cc1d000867bafd0f51780 Author: Hajo Noerenberg Date: Mon Aug 31 14:43:03 2026 +0200 ata: ahci: work around lost interrupts on Marvell 88SE61xx commit dc3565a4ae538e584e5e63b3b3cd1eaf502593c1 upstream. ahci_single_level_irq_intr() services the ports first and clears the global HOST_IRQ_STAT afterwards, as recommended by AHCI 1.1 section 10.6.2. The Marvell 88SE6111/6121/6145 family stops reporting interrupts for a port when HOST_IRQ_STAT is cleared while PxIS still holds bits: PxIS keeps its content, HOST_IRQ_STAT reads back as 0, the port is never looked at again, and the command in flight only ends in a timeout. Measured on a Seagate Blackarmor NAS440 (Marvell 88F6281 Kirkwood, 88SE6121 rev B2 behind PCIe) by polling the AHCI registers from userspace while an IDENTIFY was outstanding: t=303.046 irqs 127 PxIS 0x00000000 PxCI 0x00000001 IDENTIFY issued t=303.057 irqs 128 PxIS 0x00000020 PxCI 0x00000000 CI cleared, DPS set, one interrupt taken ... PxIS stays 0x00000020, HOST_IRQ_STAT stays 0 ... t~308.05 qc timeout after 5000 msecs The command had completed - PxCI was clear and PxIS had DPS set - so ahci_qc_complete() would have completed it. It never got the chance because the handler read HOST_IRQ_STAT as 0 and returned IRQ_NONE. Marvell's own driver for these chips clears the two registers in the opposite order and says so ("clear global before channel"), and ahci_xgene handles its broken edge latch the same way. Since the reordering costs at most one spurious interrupt per valid one on conforming controllers, do it in a private interrupt handler selected for board_ahci_mv instead of changing libahci for everyone. With this applied, SATA-2 and SATA-3 disks work at 3.0 Gbps on the 88SE6121 without the drive-side 1.5 Gbps jumper that was needed before. Time from link up to a successful IDENTIFY: WDC WD5000AADS-00S9B0 port 0 7 ms (never identified before) WDC WD3202ABYS-01B7A0 port 1 28 ms WDC WD30EFRX-68EUZN0 port 1 200 ms (3 TB, HPA detection ok) Only the 88SE6121 was tested; board_ahci_mv also covers the 88SE6145, which Marvell's driver treats identically. Fixes: cd70c26617f4 ("[libata] AHCI: Add support for Marvell AHCI-like chips (initially 6145)") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/db6b48b7-d69a-564b-24f0-75fbd6a9e543@noerenberg.de/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216094 Signed-off-by: Hajo Noerenberg Reviewed-by: Damien Le Moal Acked-by: Pali Rohar Link: https://lore.kernel.org/r/20260831124303.920391-1-hajo-linux-ide@noerenberg.de Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit e00b047332044ee4a6f8af9d107d4dd728ccc793 Author: Koichiro Den Date: Sat Jul 18 03:06:34 2026 +0900 dmaengine: dw-edma: Complete descriptors before pausing commit c154060016a9db2ac889bfdb0a3c1322f9be8ded upstream. If PAUSE is requested while the final burst of a descriptor is in flight, the DONE interrupt takes the PAUSE path without checking whether the descriptor has been depleted. The depleted descriptor remains on the issued list and the channel enters EDMA_ST_PAUSE. On resume, dw_edma_start_transfer() can select that depleted descriptor again even though no burst remains, leaving the channel in an invalid busy state. Check for descriptor completion before acknowledging PAUSE. If there is no work to start on resume, leave the channel idle. Also ignore DONE interrupts while the channel is paused so a stale or repeated interrupt cannot change its state or start queued work. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 9757367bcf1d5d2c50b94d005abca21f3eedd7c3 Author: Mikulas Patocka Date: Mon Jul 27 22:26:36 2026 +0200 dm: fix resume-vs-remove race commit 44b43ec132f1cf3275ecc182d0c82f50c3c4c3d5 upstream. If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d2844f3fcd058113acbe0aa110ab13ef28b98d9f Author: Ibrahim Hashimov Date: Mon Jul 13 11:34:14 2026 +0200 HID: wacom: validate report length in wacom_intuos_pro2_bt_irq commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d upstream. wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit fba600d824597b2a894ecae72fc422c2b8c08f8c Author: Wei Jie Law <98lawweijie@gmail.com> Date: Tue Aug 25 18:31:17 2026 +0800 HID: rmi: fix OOB access with undersized RMI reports commit 4956993bb3befdf791d71a4952d8d13bcfd44c7b upstream. The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles a reply carrying fewer bytes than requested, and a write longer than the output report was overrunning the buffer already. Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here. An emulated RMI4 device driven over /dev/uhid, and the same device again over dummy_hcd plus raw-gadget, give identical results: BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi] Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285 __asan_memcpy+0x23/0x60 rmi_hid_read_block+0x409/0x750 [hid_rmi] rmi_f01_probe+0x5dd/0x1dc0 [rmi_core] BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi] Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666 __asan_memcpy+0x3c/0x60 rmi_hid_write_block+0x1a9/0x350 [hid_rmi] rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core] rmi_driver_probe+0x636/0xbf0 [rmi_core] rmi_input_configured+0x184/0x2e0 [hid_rmi] rmi_probe+0x952/0xcf0 [hid_rmi] and, for the zero-length reply, a probe worker left in D state in rmi_hid_read_block() after 225 replies at 200 ms intervals. After this change the undersized descriptor is refused at probe with "rmi reports too small (out=2 in=2)", the oversized read and write are both rejected, the zero-length reply fails the read with -EIO while later reads on the same device keep working, and a device declaring reports large enough for a 21-byte register read still probes normally and reports its real product id. A device bound through new_id with RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an unallocated writeReport either. Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/ Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f39e3ca1f688d7c08954a0794e9bf1e279c83b15 Author: Runyu Xiao Date: Mon Aug 24 19:36:18 2026 +0800 scsi: pm8001: Use rollback index when freeing MSI-X vectors commit 3f92a64545165bdbb36dee8fa35626b295463313 upstream. pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop. Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Jack Wang Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5fac79f248c37774d1dd761406f83d25ca6ff8e4 Author: Sujal Tuladhar Date: Sat Aug 1 21:30:00 2026 +0545 scsi: target: iscsi: Reserve a terminator byte for the login payload commit f4825922d2fb371e2b969697d792077f1b62b62c upstream. iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Assisted-by: Claude Opus5 (custom harness) Cc: stable@vger.kernel.org Signed-off-by: Sujal Tuladhar Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit dbe26ee2df5d78434203203da55a47d6b7d64b23 Author: Can Peng Date: Wed Jul 22 15:56:25 2026 +0800 thermal/drivers/qoriq: Disable clock on resume failure commit fcbf9964b67a6d6704c50ed28daa24c3b164f01c upstream. qoriq_tmu_resume() enables the TMU clock before clearing the power-down bit and enabling monitoring. If either register update fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed resume. Disable the clock on those failure paths before returning the error. Fixes: 51904045d4aa ("thermal: qoriq: Add clock operations") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260722075625.452684-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 7fd8c8d15d083b145df0dc4e19f55e947347e61d Author: Can Peng Date: Wed Jul 22 16:49:09 2026 +0800 thermal/drivers/imx: Disable clock on runtime resume failure commit bcc6d886e5006a4656901d2d7fb6a215c96068a0 upstream. imx_thermal_runtime_resume() enables the thermal clock before powering up the sensor and enabling measurements. If either regmap_write() fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed runtime resume. Disable the clock on those failure paths before returning the error. Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Reviewed-by: Frank Li Link: https://patch.msgid.link/20260722084909.463437-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 15081ff835b29e456da29303b32efc436df04695 Author: Muhammad Bilal Date: Tue Jul 28 17:54:55 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() commit ff917923f4fb9c83717ba135ee47d7e4c1567bb7 upstream. rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0fc54a00954f9f4c3e3d4ffa64a530685d99a39b Author: Jeffin Philip Date: Sun Aug 16 11:47:12 2026 +0530 usb: gadget: fix null pointer dereference in usb_put_function_instance() commit 6e74ac5c596fd246e37eadfc354567179ccbe9aa upstream. usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null. Reported-by: syzbot+fd6ef980cf1c722be639@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd6ef980cf1c722be639 Fixes: 0062f6e56f70 ("usb: gadget: add a forward pointer from usb_function to its "instance"") Cc: stable Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260816061712.15547-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8be30959be31b4205e3bdd2e2a6221f3a2ee7ea1 Author: Lovekesh Solanki Date: Tue Aug 25 22:43:43 2026 +0530 USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() commit dd0eed9e165b1a6292f49e622e3dd0b7d99b106d upstream. gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently. Cc: stable Reported-by: Eulgyu Kim Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Signed-off-by: Lovekesh Solanki Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260825171343.459630-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8fde7e4a366184e9a6aa95541e52933a73c00a74 Author: Jameson Thies Date: Tue Aug 25 23:45:45 2026 +0000 usb: typec: ucsi: displayport: Fix OOB altmode array index commit 04cec690b1fd9d1c4c314b91a10d8c68a3acfe18 upstream. The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit b0bbdd83b865ff091fee1fe687f313bacb9bb12c Author: Andy Shevchenko Date: Mon Aug 17 18:11:30 2026 +0200 usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() commit 9f6f095beec82a80daa666a3b2186a5b95841e9a upstream. GCC (Debian 14.2.0-19) is not happy about the buffer size: drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=] Bump the size to get it enough for all possible values. Note, although cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize this and complains about the buffer size. Also note, the existing comment is wrong as size 8 for the whole buffer doesn't cover 100 mil numbers, hence drop it altogether. Fixes: b27c08c953e9 ("usb: gadget: f_mass_storage: create lun creation helpers for use in fsg_common_init") Cc: stable Acked-by: Alan Stern Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260817161239.1448582-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9cd335f4f41e84d1ab88d80150ffee8dee9650d7 Author: Liu Qi Date: Fri Aug 21 17:04:16 2026 +0800 usb-storage: ene_ub6250: fix race between scan work and probe commit 445fc368c6bc73eff0aeb3818cf5f355facfbb16 upstream. ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path. Reported-by: syzbot+22ea20ef3afb6785b122@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=22ea20ef3afb6785b122 Assisted-by: Qwen:Qwen3.6 Signed-off-by: Liu Qi Acked-by: Alan Stern Link: https://patch.msgid.link/20260821090416.1247127-1-liuqi@longcheer.com Signed-off-by: Greg Kroah-Hartman commit 97b5e8b22b98e287481a97a9a4cfebbb348738a5 Author: Shuangpeng Bai Date: Mon Jul 6 16:24:06 2026 -0400 media: usbtv: keep device alive while ALSA card exists commit fc530fe168bb2b745a93f553ad21fc25fd9cba3d upstream. The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card. Closes: https://lore.kernel.org/r/178144969601.60470.4852887710381872458@gmail.com Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5538daf2a5cc80ac3f3e913c0db045d92d995d40 Author: HyeongJun An Date: Tue Sep 1 18:04:09 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() commit e4637ce34607f1733a34a57294966d26b263e626 upstream. The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6c601410d1a9ae645f604fe2f61b9f4942c77dfb Author: Griffin Kroah-Hartman Date: Wed Aug 19 12:04:25 2026 +0200 usb: image: mdc800: change kmalloc() to kzalloc() commit 2430eb81e44111b30eeb5273bbcf8b24ca517ef9 upstream. Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify() Assisted-by: gkh_clanker_t1000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260819-usb_misc_random-v1-1-43a0dcee3a32@kroah.com Signed-off-by: Greg Kroah-Hartman commit e32bafd08ee35feacd47b05cc5bfe9cd9659cd25 Author: Sabrina Dubroca Date: Wed Apr 9 15:59:57 2025 +0200 espintcp: remove encap socket caching to avoid reference leak [ Upstream commit 028363685bd0b7a19b4a820f82dd905b1dc83999 ] The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 1aa6df61cef1f47f503c3ccf60d08c4dd931fdc1 Author: Petr Vaganov Date: Mon Sep 7 16:27:07 2026 +0700 scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() commit 626147717bea776b61ed3631d2c26283760c4cc4 upstream. During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 40b01b9bbdf5 ("block: update bio according to DMA alignment padding") Cc: stable@vger.kernel.org Signed-off-by: Petr Vaganov Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260628185229.37957-1-p.vaganov@ideco.ru Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Petr Vaganov Signed-off-by: Sasha Levin commit dc1b1a057b3bb901f83433700e604fe0ae67c5f2 Author: Masami Hiramatsu (Google) Date: Mon Sep 7 18:07:26 2026 +0300 tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions commit 12b80cdbc54cf615b4717a4e8180063408091ea2 upstream. mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map(). Link: https://patch.msgid.link/178524300062.56416.8362487250709962380.stgit@devnote2 Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit 24d5ee8a523a0e283a59bde093ad1a64e5cf80e6 Author: Steven Rostedt Date: Mon Sep 7 18:07:25 2026 +0300 tracing/mmiotrace: Remove reference to unused per CPU data pointer commit 6936298393d8d8bc3cec6b704f6a774162cf9bd3 upstream. The mmiotracer referenced the per CPU array_buffer->data descriptor but never actually used it. Remove the references to it. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://lore.kernel.org/20250505212234.696945463@goodmis.org Signed-off-by: Steven Rostedt (Google) Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit fe35c24b730d38b421da93ac5d493cb4495e8e54 Author: D. Wythe Date: Tue Sep 1 12:05:43 2026 +0300 net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link() commit e40b801b3603a8f90b46acbacdea3505c27f01c0 upstream. There is a certain chance to trigger the following panic: PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62 [exception RIP: ib_alloc_mr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc] The reason here is that when the server tries to create a second link, smc_llc_srv_add_link() has no protection and may add a new link to link group. This breaks the security environment protected by llc_conf_mutex. Fixes: 2d2209f20189 ("net/smc: first part of add link processing as SMC server") Signed-off-by: D. Wythe Reviewed-by: Larysa Zaremba Reviewed-by: Wenjia Zhang Signed-off-by: David S. Miller [Denis Arefev: adapted for 5.10: smc_llc_srv_add_link() has no req_qentry argument here, as SMC-Rv2 REQ_ADD_LINK support is not present in 5.10] Signed-off-by: Denis Arefev Signed-off-by: Sasha Levin commit 1715901e7052cf90fbf04c8303e563a47e021278 Author: Zack Rusin Date: Mon Sep 7 15:17:49 2026 +0300 drm/vmwgfx: drop dma_buf reference on foreign-fd prime import commit f739416dc555fa205a785e5135d73fa39b26f35d upstream. ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped. Fixes: 65981f7681ab ("drm/ttm: Add a minimal prime implementation for ttm base objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-6-zack.rusin@broadcom.com Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit 774a3bccd46c66f97a73f509e3d6778f7b1941e8 Author: Koichiro Den Date: Mon Sep 7 11:57:12 2026 +0900 net: ntb_netdev: Fix TX busy and drop handling commit 8aaa47351db0f93a5c5297fbafdfa8bc75e8ae49 upstream. Currently, ntb_netdev returns NETDEV_TX_BUSY for every enqueue error. It also increments the drop and error counters while leaving the skb owned by the qdisc, and may return BUSY with the subqueue still awake. Retrying a permanent error cannot succeed either. The unconditional BUSY return and premature accounting date back to the initial driver. The error-path queue stop was later removed without changing that return value. The current flow-control code includes a resource check, but ntb_netdev does not honor its result before enqueue. Honor the resource check before enqueue. For -EAGAIN and -EBUSY, stop the subqueue, arm the existing reaper timer, and return BUSY without touching the skb. For other errors, free the skb, increment tx_dropped, and return NETDEV_TX_OK. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Fixes: d723485cb4ca ("ntb_netdev: remove tx timeout") Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski [den: adapt to the single-queue implementation, as 5.10.y lacks commit: ee970634c777 ("net: ntb_netdev: Introduce per-queue context")] Stable-dep-of: 873ce713fef5 ("NTB: ntb_transport: Fail TX enqueue when the QP link is down") Stable-dep-of: a4f2387db6f1 ("NTB: ntb_transport: Reject oversized TX buffers") Signed-off-by: Koichiro Den Signed-off-by: Sasha Levin commit d2e7f7035d6f407119ba5467f7218cc4370844fc Author: Bryam Vargas Date: Mon Sep 7 17:39:55 2026 +0300 selinux: reject an unclaimed class value in security_get_classes() commit 22b05fec62c0fe9864cfceb52f7d0f3a34d9b1dd upstream. security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit 167beb9c2cec58f413bb7c9b2d1560dbdd647d71 Author: Christian Göttsche Date: Mon Sep 7 17:39:54 2026 +0300 selinux: avoid implicit conversions in services code commit c50e125d057152bc68dfd5669b73611343653eb7 upstream. Use u32 as the output parameter type in security_get_classes() and security_get_permissions(), based on the type of the symtab nprim member. Declare the read-only class string parameter of security_get_permissions() const. Avoid several implicit conversions by using the identical type for the destination. Use the type identical to the source for local variables. Signed-off-by: Christian Göttsche [PM: cleanup extra whitespace in subject] Signed-off-by: Paul Moore Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit aef4a9ae95d1bc4f7897065011e6261026719aeb Author: Eric Dumazet Date: Fri Sep 4 11:34:56 2026 -0700 tcp: fix potential race in tcp_v6_syn_recv_sock() [ Upstream commit 858d2a4f67ff69e645a43487ef7ea7f28f06deae ] Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context. [florian: - net/ipv6/tcp_ipv6.c: - Set `newnp->ipv6_fl_list = NULL` instead of `newinet->ipv6_fl_list = NULL`, as `ipv6_fl_list` is in `struct ipv6_pinfo`. - Guarded `af_specific` assignment with `#ifdef CONFIG_TCP_MD5SIG` instead of checking `CONFIG_TCP_AO`. - Used `if (tcp_inet6_sk(sk)->repflow)` instead of `inet6_test_bit(REPFLOW, sk)`. - net/smc/af_smc.c: - Dropped changes to net/smc/af_smc.c because SMC did not implement `smc_tcp_syn_recv_sock()` in 5.10.y (added in 5.14 via commit e94a869818ab). - net/dccp/: - Updated `syn_recv_sock` implementations and call sites for DCCP, which was removed in upstream kernels prior to this commit.] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+937b5bbb6a815b3e5d0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69949275.050a0220.2eeac1.0145.GAE@google.com/ Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260217161205.2079883-1-edumazet@google.com Signed-off-by: Jakub Kicinski Assisted-by: Cursor:gemini-3.7-flash Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 27d172b60eeca5c8fd51b246f9fb959067cf102b Author: Youngjae Kwon Date: Sat Sep 5 11:44:22 2026 +0900 fsnotify: Fix stale object mask after concurrent mark updates [ Upstream commit e422777fdd4746de1109575c51e65038d4c5c1be ] When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler. Link: https://lore.kernel.org/all/CACwKKmCZdiZDoFuYm6LZhQ=XvHPk0fNKH=X3LmoXMqakYqJaNw@mail.gmail.com/ Fixes: 63c882a05416 ("inotify: reimplement inotify using fsnotify") Fixes: 912ee3946c5e ("fanotify: do not call fanotify_update_object_mask in fanotify_add_mark") Cc: stable@vger.kernel.org # needs adjustments for <= 7.0 Suggested-by: Jan Kara Suggested-by: Amir Goldstein Signed-off-by: Youngjae Kwon Link: https://patch.msgid.link/20260802015801.2426818-1-yjkwon0026@snu.ac.kr Signed-off-by: Jan Kara (cherry picked from commit e422777fdd4746de1109575c51e65038d4c5c1be) [yjkwon0026: Resolve the inotify conflict by retaining the branch-native inode->i_fsnotify_marks argument to fsnotify_recalc_mask(). This tree lacks 35ceae44742e ("fsnotify: Avoid data race between fsnotify_recalc_mask() and fsnotify_object_watched()") and 4520b96b8136 ("fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()"). The differing READ_ONCE() line and connector call are in the conditional deleted by this patch, so neither commit is a prerequisite for this fix.] Signed-off-by: Youngjae Kwon Signed-off-by: Sasha Levin commit eca5ed4200f0be3e91f8a237b1f37582030a93a8 Author: Jinjie Ruan Date: Fri Sep 4 07:38:44 2026 +0200 entry: Fix seccomp bypass after ptrace with TSYNC commit 4a3591287fb7f808e209b4974ed337f609a2006b upstream. Sashiko review pointed out the following issue. If a thread is stopped in syscall_trace_enter() for ptrace, another thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC (e.g., via seccomp_attach_filter()). This will successfully set SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALL_WORK_SECCOMP misses the newly assigned flag, and the filter is silently bypassed. This race condition could allow an unprivileged process to execute a prohibited system call (e.g., execve) that the newly installed filter was intended to block, especially since the tracer might have modified the system call number during the ptrace stop. Fix this by re-reading the syscall_work flags after ptrace handling, so that any new SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check. Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com Signed-off-by: Sasha Levin commit c8db0e5ab0b6c540214c46c56aaac7cbcb0967fe Author: Tristan Madani Date: Thu Sep 3 20:08:51 2026 +0000 RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe [ Upstream commit 22b8fbded65b8c441b634a185f8da67657df6c50 ] get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260518215040.1598586-2-tristan@talencesecurity.com Signed-off-by: Tristan Madani Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe [doebel: cherry-picked from v6.1.178 (3cfa2a3adc51), accomodate for context changes] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 38fa5e862bea27c82f589cc0c05da2c1da65beb9 Author: Bob Pearson Date: Thu Sep 3 20:08:50 2026 +0000 RDMA/rxe: Use the correct size of wqe when processing SRQ [ Upstream commit e2a05339fa1188b6b37540f4611893ac4c534fa2 ] The memcpy() that copies a WQE from a SRQ the QP uses an incorrect size. The size should have been the size of the rxe_send_wqe struct not the size of a pointer to it. The result is that IO operations using a SRQ on the responder side will fail. Fixes: ec0fa2445c18 ("RDMA/rxe: Fix over copying in get_srq_wqe") Link: https://lore.kernel.org/r/20210729220039.18549-2-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe [doebel: Clean cherry-pick. Needed as a prerequisite for "RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe" ] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 40f1fb371f3122a9f28767307bfe39eaca51174f Author: Dan Carpenter Date: Thu Sep 3 20:08:49 2026 +0000 RDMA/rxe: Missing unlock on error in get_srq_wqe() [ Upstream commit 36941dfe0e8c3e2da7851b9648fd74bd3a3e78ce ] This error path needs to unlock before returning. Fixes: ec0fa2445c18 ("RDMA/rxe: Fix over copying in get_srq_wqe") Link: https://lore.kernel.org/r/YNXUCmnPsSkPyhkm@mwanda Signed-off-by: Dan Carpenter Reviewed-by: Majd Dibbiny Reviewed-by: Bob Pearson Signed-off-by: Jason Gunthorpe [doebel: Clean cherry-pick. Needed as a prerequisiste for "RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe" ] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 45b91b9f60ae5f3f56a53282fdb02eed0da51326 Author: Bob Pearson Date: Thu Sep 3 20:08:48 2026 +0000 RDMA/rxe: Fix over copying in get_srq_wqe [ Upstream commit ec0fa2445c18ec49a0b7ee0aaa82d1ec00968fc9 ] Currently get_srq_wqe() in rxe_resp.c copies the maximum possible number of bytes from the wqe into the QPs copy of the SRQ wqe. This is usually extra work and risks reading past the end of the SRQ circular buffer if the SRQ is configured with less than the maximum possible number of SGEs. Check the number of SGEs is not too large. Compute the actual number of bytes in the WR and copy only those. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210618045742.204195-5-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe [doebel: context adjustment from upstream patch to 5.10. needed as a prerequisite for "RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe" ] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 4b549d32d34ee765527e63726bb1af984876e776 Author: Pablo Neira Ayuso Date: Fri Sep 4 01:30:55 2026 +0000 netfilter: nf_tables: make nft_object rhltable per table commit f4f699790590bd0896c48a71e9232a65198f92f0 upstream. The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup(). Fixes: 4d44175aa5bb ("netfilter: nf_tables: handle nft_object lookups via rhltable") Suggested-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso [ 5.10: More extensive conflicts than 6.1 in nf_tables_api.c because 5.10 lacks several mainline refactors: 0be908750162 ("netfilter: nf_tables: pass nft_table to destroy function", v6.11), e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects", v6.11), f80a612dd77c ("netfilter: nf_tables: add support to destroy operation", v6.3), 797d49805ddc ("netfilter: nfnetlink: pass struct nfnl_info to rcu callbacks", v5.13) and 6001a930ce03 ("netfilter: nftables: introduce table ownership", v5.12). Resolved by: destroying the per-table objname_ht via ctx->table in nf_tables_table_destroy(); dropping only the const on the local table in nf_tables_getobj() (which still uses the pre-nfnl_info API); passing the owning table trans->ctx.table to nft_obj_del() in the commit and abort paths (struct nft_trans still embeds an nft_ctx and 5.10 has no NFT_MSG_DESTROYOBJ case); and removing the global nft_objname_ht rhltable_init/destroy from module init, keeping 5.10's numeric error labels. The header and all other hunks applied cleanly. ] Signed-off-by: Suraj Jitindar Singh Signed-off-by: Sasha Levin commit 239f26589a6926db28c436e14f28517581ef1385 Author: Yuqi Xu Date: Fri Sep 4 11:48:18 2026 +0200 openvswitch: Fix CT limit teardown use-after-free [ Upstream commit 403f96c32c9e24600093d7d0c61c17daeedca957 ] Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/all/cover.1784711445.git.xuyuqiabc@gmail.com Co-developed-by: Nan Li Signed-off-by: Nan Li Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/288fbd5459d92b9dd0dcc6faf625f04819161ff3.1787280296.git.xuyuqiabc@gmail.com Signed-off-by: Jakub Kicinski [ 7.0+ uses kmalloc_obj[s] while older versions use kmalloc[_array] 6.12+ doesn't have a 'family' argument in nf_conncount_init/destroy ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit b6d34d3657d2268f71365f8fbe3d0b349e0cc307 Author: Ilya Maximets Date: Fri Sep 4 11:48:17 2026 +0200 net: openvswitch: fix kernel-doc warnings in internal headers [ Upstream commit 6bb0dcb3d321c14be7ca33b71a149034d6a2cde8 ] Some field descriptions were missing, some were not very accurate. Not touching the uAPI header or .c files for now. Formatting of those comments isn't great in general, but at least they are not missing anything now. Before: $ ./scripts/kernel-doc -none -Wall net/openvswitch/*.h 2>&1 | wc -l 16 After: $ ./scripts/kernel-doc -none -Wall net/openvswitch/*.h 2>&1 | wc -l 0 Signed-off-by: Ilya Maximets Acked-by: Eelco Chaudron Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20250320224431.252489-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski [ struct vport_upcall_stats_percpu doesn't exist in 6.2 and earlier struct datapath doesn't have @upcall_portids in 5.14 and earlier ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit 849bdb83123760a865bcb2970127f4c0b9423ba3 Author: Norbert Szetei Date: Fri Sep 4 11:09:11 2026 +0200 net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() [ Upstream commit 8ece906150128d5ec2462aabcc978c568433eca4 ] skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/6E3A780D-FB87-421F-9964-B1D457D7D106@doyensec.com Signed-off-by: Paolo Abeni [ 7.2 and earlier do not have the put_page() call on the error path ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit 6493165034bca14033bf49c9cec7b45e97a91497 Author: Norbert Szetei Date: Fri Sep 4 10:45:33 2026 +0200 net: skbuff: don't touch shared zerocopy state in skb_tx_error() [ Upstream commit f66bdb1cc0fcd227a062378f8be0b5873aa5600a ] skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes. Fixes: 25121173f7b1 ("skb: api to report errors for zero copy skbs") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/CFAB292A-674B-4C14-BB2C-BB8830AD5659@doyensec.com Signed-off-by: Paolo Abeni [ There was no 'if' on 5.x as there is no skb_zcopy_downgrade_managed(). ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit a7ecd1a04f4f485d7be6443d0f0b2c61a800cb82 Author: Sonali Pradhan Date: Fri Sep 4 09:40:52 2026 +0000 usb: gadget: u_audio: Fix use-after-free on sound card disconnect commit 858965947081d10d41d9a1010a540d3d5eea958b upstream. g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero. Fixes: 6c67ed9ad9b8 ("usb: gadget: u_audio: don't let userspace block driver unbind") Cc: stable@vger.kernel.org Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260810071237.2207680-1-sonalipradhan@google.com Signed-off-by: Greg Kroah-Hartman [sonalipradhan: resolved ureq field naming and placement conflicts for 5.10-stable] Signed-off-by: Sonali Pradhan Signed-off-by: Sasha Levin commit f121db2df18dde8b4d8751cda206bfa4fd5924f4 Author: Tzung-Bi Shih Date: Wed Jul 15 02:44:53 2026 +0000 platform/chrome: sensorhub: Fix dropped timestamp events and log spam commit 9a3f43b30373c61477d0d3ab52946c05f9492bf9 upstream. Commit 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") evaluated the `sensor_num` against the bounds limit even for timestamp events. A timestamp event typically has a `sensor_num` of 0xff [1], causing the driver to flag it as invalid and skip to the next event. As a result, we'd see a flooding of "Invalid sensor number 255 from EC" warning logs and these timestamp events were being dropped. Move the bounds-check into cros_ec_sensor_ring_process_event() and evaluate it only after standalone timestamp events have already been processed and returned early. [1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427 Fixes: 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit 6fdb04bc660237022ae3c53e585902b4647e9702 Author: Zhan Xusheng Date: Wed Jul 22 16:24:25 2026 +0800 udf: Fix i_lenExtents truncation on 32-bit kernels commit a5a5ed23b1340ff0f32a14a7ca8585f7c4e9b2e2 upstream. In udf_do_extend_file() the total extent length is rounded up to a block boundary with: iinfo->i_lenExtents = (iinfo->i_lenExtents + sb->s_blocksize - 1) & ~(sb->s_blocksize - 1); i_lenExtents is a __u64, but sb->s_blocksize is unsigned long. On 32-bit kernels unsigned long is 32-bit, so ~(sb->s_blocksize - 1) is a 32-bit value (e.g. 0xfffff800 for a 2 KiB block) that is zero-extended in the AND, clearing the upper 32 bits of i_lenExtents. For UDF files whose total extent length exceeds 4 GiB this truncates i_lenExtents when the file is extended, corrupting the tracked extent length. Cast the block size to 64-bit before forming the mask. 64-bit kernels are unaffected. Fixes: 48d6d8ff7dca ("udf: cache struct udf_inode_info") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Link: https://patch.msgid.link/20260722082425.213311-1-zhanxusheng@xiaomi.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit dfc68c5440404f7e6c18ca24d3454f31976dbebd Author: Thomas Gleixner Date: Tue Aug 18 00:14:57 2026 +0200 timer: Keep debugobjects state consistent in migrate_timer_list() commit c793bbfc4a0a9f5a66978fc91559e9681748dbeb upstream. When timers are migrated away from an offline CPU the debugobjects state gets corrupted. The timer is accounted as inactive on deletion, but the enqueue on the alive CPU lacks the activation call. That used to work, but got broken when the trace point and the debug objects call got separated. That change missed to fixup migrate_timer_list(). Add the missing debug_timer_activate() invocation to fix it. Fixes: dc1e7dc5ac62 ("timer: Move trace point to get proper index") Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87bjb0l7ha.ffs@fw13 Signed-off-by: Greg Kroah-Hartman commit e015d1ac6b43a23c52c5163299414ae77d7d4ae0 Author: Bradley Morgan Date: Mon Jun 22 20:25:08 2026 +0000 signal: avoid shared siginfo namespace rewrites commit d19cdc167e696714509e87d3f7ae765b6e164589 upstream. send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it. Link: https://lore.kernel.org/86a8857d58d43ee26a8b365b837fd24830343494.1782159692.git.include@grrlz.net Fixes: 7a0cf094944e ("signal: Correct namespace fixups of si_pid and si_uid") Signed-off-by: Bradley Morgan Acked-by: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Adrian Huang Cc: Aleksandr Nogikh Cc: Christian Brauner Cc: Marco Elver Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 007c9e637e0e0b9d946b7f0e8a42f1f1aca48d7a Author: Myeonghun Pak Date: Fri Jun 26 19:35:52 2026 +0300 tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout commit 705c4ed0643366963547b2616d53165f2519c81f upstream. i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper. Cc: stable@vger.kernel.org # v5.10+ Fixes: 4c336e4b1556 ("tpm: Add support for the Nuvoton NPCT501 I2C TPM") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260626091653.54929-1-mhun512@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b30c021c6073559ea6851b522d8a17a524a27b4a Author: Maoyi Xie Date: Mon Jun 29 20:10:43 2026 +0800 w1: ds28e17: reject an oversize length on an I2C block read commit 169ae5e65e5aaf213b6a578f6478a9fd2e523606 upstream. w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does. Fixes: ebc4768ac497 ("add w1_ds28e17 driver for the DS28E17 Onewire to I2C master bridge") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Andi Shyti Link: https://patch.msgid.link/20260629121043.199487-1-maoyixie.tju@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit e059a14c1067bcc4f7b1947cd09f2baab98e340f Author: Chengfeng Ye Date: Sun Aug 23 00:45:56 2026 +0800 vsock/virtio: flush works in dependency order commit 728836ebca239810f164262b10211ef59182f811 upstream. virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush. Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260822164556.3750959-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e8fd57157ee7a9e2986a9218198a5c1b02f2310b Author: Abdun Nihaal Date: Mon Jul 27 12:12:22 2026 +0530 wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() commit 9f2948010764d708bda27369d09ce6f194abe8e3 upstream. The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb(). Fixes: aaab5d0e6737 ("rtw88: kick off TX packets once for higher efficiency") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260727064223.61836-1-nihaal@cse.iitm.ac.in Signed-off-by: Greg Kroah-Hartman commit 4b4a8ca0090b9fe7cd8edc1b83220c133d208534 Author: Stanislaw Gruszka Date: Thu Jul 23 13:06:40 2026 +0200 wifi: rtl818x: initialize eeprom_93cx6 struct to zero commit 799b5f45cb8194ebd06c9c89e0afdad5bedd2cc5 upstream. Commit 7738a7ab9d12 ("misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle") added extra 'quirk' field to struct eeprom_93cx6. Many existing users of eeprom_93cx6, including rtl818x drivers, allocate the structure on the stack without initializing all fields. As a result, the added quirk field has an undefined value and can randomly cause reading wrong data from the EEPROM. Fix by initializing the structures with {}. Fixes: 7738a7ab9d12 ("misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle") Cc: stable@kernel.org # v6.13+ Signed-off-by: Stanislaw Gruszka Reviewed-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260723110640.8588-1-stf_xl@wp.pl Signed-off-by: Greg Kroah-Hartman commit 8c67b8c50286e0cb7f18d667e6a37a2ec6e08ff9 Author: Fabio Estevam Date: Fri Jul 24 17:33:19 2026 -0300 wifi: mwifiex: Detach sync cmd buffer on interrupted wait commit ef06882c7d8a7400b67d0d003b1008093dd589ed upstream. mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> "bF878X,\0" which is a fragment of the VERSION_EXT firmware string exposed as debugfs "verext": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> "153.7\0$" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997. Cc: stable@vger.kernel.org Fixes: 3d026d09b28d ("mwifiex: cancel pending commands for signal") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260724203320.78793-1-festevam@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b1d0a90a844abccdfed9fe141b5d0d654a821485 Author: Abdun Nihaal Date: Mon Aug 3 11:35:06 2026 +0200 wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() commit 0d10db8e94fcb23a799789aaa696b4d8f937e207 upstream. The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. Cc: stable@vger.kernel.org Fixes: dd43a01c5cdb ("brcmfmac: use dynamically allocated control frame buffer") Signed-off-by: Abdun Nihaal [arend: rework as suggested by Johannes] Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260803093506.1647790-1-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 334cfb5e285cece5dc49fb3fb8ea9b70b2cb5d7e Author: Adrian Hunter Date: Thu Jul 23 10:57:47 2026 +0300 i3c: master: Fix info leak and UAF in device unregister path commit d2c743efd2d1ee64e94324664808f623dd865872 upstream. i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/ Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260723075747.34049-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit c3594070dce5db825fcd18d6197e48e75c1fe65c Author: Haotian Zhang Date: Sat Jul 11 22:21:55 2026 +0800 dm-switch: use WRITE_ONCE() in switch_region_table_write() commit c7391ebe33162c7962b313caea4d8e6b0bc2a671 upstream. switch_region_table_read() accesses the region table with READ_ONCE() and is called from the lockless switch_map() IO path. However, switch_region_table_write() stores to the same array with a plain assignment. This results in an inconsistent access pattern for a lockless shared variable and may trigger data race reports. Use WRITE_ONCE() to pair with the existing READ_ONCE() in switch_region_table_read(). Cc: stable@vger.kernel.org Fixes: 99eb1908e643 ("dm switch: factor out switch_region_table_read") Signed-off-by: Haotian Zhang Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit e45f0b0c41139810ff395ba2f3cfca1460a5b8a6 Author: Mikulas Patocka Date: Mon Aug 3 23:34:02 2026 +0200 dm-stats: fix a crash if allocation of per-cpu data fails commit cc87e26d9cce22061dc21e51e11afef29dbbc36a upstream. If "dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))" fails, the code jumps to the "out" label and calls dm_stat_free. dm_stat_free does "for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it. Reported-by: Junzhe Yu Signed-off-by: Mikulas Patocka Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit adbda2cd17a97a7ae70d325dfe30f54e34f42ab5 Author: Naman Jain Date: Thu Sep 3 16:23:31 2026 +0000 PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip [ Upstream commit 86bdd16e8f390d51bae9e77a4bc4164ca2f580fe ] The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback. On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to the outgoing CPU to a new target. If an interrupt still has its pending bit set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the new target through the irqchip's irq_retrigger() callback. As the Hyper-V PCI/MSI chip does not provide that callback, the pending interrupt is silently dropped, which can result in lost interrupts, stalls and "No irq handler for vector" messages during CPU hotplug. Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its new target CPU via the parent x86 vector domain. Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Cc: stable@vger.kernel.org Suggested-by: Long Li Suggested-by: Thomas Gleixner Reviewed-by: Aditya Garg Reviewed-by: Shradha Gupta Signed-off-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit aa8cabde7e83bf96269ee47427dc9b59e3ed8e60 Author: Matthieu Baerts (NGI0) Date: Thu Sep 3 10:35:12 2026 +0200 mptcp: pm: ADD_ADDR rtx: free sk if last [ Upstream commit b7b9a461569734d33d3259d58d2507adfac107ed ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-5-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski [ Karl Mehltretter: applied to pm_netlink.c and retained v5.10's fixed retransmission delays while centralizing timer rearming. ] Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Sasha Levin commit f5555a6d7c472849fdf2b426e3d0a85103118793 Author: Matthieu Baerts (NGI0) Date: Thu Sep 3 10:35:11 2026 +0200 mptcp: pm: ADD_ADDR rtx: always decrease sk refcount [ Upstream commit 9634cb35af17019baec21ca648516ce376fa10e6 ] When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-4-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski [ Karl Mehltretter: applied to pm_netlink.c; retained v5.10's ID 0 guard and routed it through the common refcount drop. ] Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Sasha Levin commit 4e56d3d60d3192ef0a0c08e8b433636690189384 Author: Haoze Xie Date: Thu Sep 3 15:17:57 2026 +0300 netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst commit c9c9b37f8c5505224e8d206184df3bb668ee00cf upstream. The br_netfilter fake rtable is embedded in struct net_bridge and is attached to bridged packets with skb_dst_set_noref(). If such a packet is queued to NFQUEUE, __nf_queue() upgrades that fake dst with skb_dst_force(). At that point the queued skb can hold a real dst reference after bridge teardown has started. The problem is not that every bridged packet needs its own dst reference. The problem is that NFQUEUE can keep the bridge private fake dst alive after unregister begins. Fix this by keeping the bridge fake dst model unchanged and pinning the bridge master device only while the packet sits in NFQUEUE. Record the bridge device in nf_queue_entry when the queued skb carries a bridge fake dst, take a device reference for the queue lifetime, and drop it when the queue entry is freed. Also make sure queued entries are reaped when that bridge device goes down, and drop the redundant nf_bridge_info_exists() test from the fake dst detection. This keeps netdev_priv(br->dev) alive until verdict completion, so the embedded fake rtable and its metrics backing storage cannot be freed out from under dst_release(). It also avoids the constant refcount bump and avoids using ipv4-specific dst helpers for IPv6 bridge traffic. Fixes: 34666d467cbf ("netfilter: bridge: move br_netfilter out of the core") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Haoze Xie Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit 41a952304cc8a308748e3f58462c879f2a9c4340 Author: Takashi Iwai Date: Thu Aug 6 17:32:20 2026 +0200 ALSA: serial-u16550: Check card index validity at probe commit e0fb960b227fcdebe22e4f26c9486d60943c0424 upstream. serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-4-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 45ea0707298798678a60ff861b695aea049a5469 Author: Takashi Iwai Date: Thu Aug 6 17:32:23 2026 +0200 ALSA: portman2x4: Check card index validity at probe commit 3690ef20469d5959378260e2752f2314a2572913 upstream. Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-7-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 1566ca99fc0e892b9164ad893d268b00064fff54 Author: Takashi Iwai Date: Thu Aug 6 17:32:22 2026 +0200 ALSA: mts64: Check card index validity at probe commit d18a260720f86a5f8b5fcfefc4ba2e9dd01c10f8 upstream. Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-6-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 4a3d6c22ca6b6c16e8055fb518aa87f5e043f754 Author: Takashi Iwai Date: Thu Aug 6 17:32:19 2026 +0200 ALSA: mpu401: Check card index validity at probe commit f7dcecb92ed192ff5fcf842918fb1aaea84b5bdd upstream. mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-3-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 9af08677aa57debaca5b57c8045c52a83d3dd376 Author: Baul Lee Date: Wed Aug 5 10:34:28 2026 +0900 ALSA: bcd2000: clear the URB pointers on disconnect commit 459d3a64766f5ca2f1886daeaf24582831a5f5ab upstream. bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: usb_kill_urb(bcd2k->midi_out_urb); usb_kill_urb(bcd2k->midi_in_urb); usb_free_urb(bcd2k->midi_out_urb); usb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; ... ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee Fixes: b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013428.38204-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c9204bc2ed2010e2469dbe5fce598878a37efd04 Author: Baul Lee Date: Wed Aug 5 10:34:23 2026 +0900 ALSA: 6fire: bound the MIDI event length from the device commit a478893b59e36cfe7d77a76b352f2db55502e879 upstream. usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: if (!urb->status) { if (rt->receiver_buffer[0] == 0x10) /* midi in event */ if (midi_rt) midi_rt->in_received(midi_rt, rt->receiver_buffer + 2, rt->receiver_buffer[1]); } receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013423.38175-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d1f0d353358987ca87f21d8956e2d2854951130d Author: Zhiling Zou Date: Sat Aug 22 16:49:27 2026 +0800 seg6: reset IP6CB after IPv6 decapsulation commit f967455fb2a5a2079b9eb5823e9ccf359174bf9f upstream. decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Andrea Mayer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fb889a619723032140f5d983a3a34d25a5a2bed4 Author: Zhiling Zou Date: Thu Aug 13 00:22:35 2026 +0800 net: cap advertised IP tunnel headroom commit 6b222adeb9340306e2ff97127c76117abb9b3df8 upstream. IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers. Fixes: 1a37e412a022 ("net: Use 16bits for *_headers fields of struct skbuff") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/ba04a1fd6bfae2377607fad5d8f80f7eb80fd4c4.1786542637.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 451fcf2e76647106aef3949fb16aa72008804ca8 Author: Koichiro Den Date: Thu Aug 20 02:25:39 2026 +0900 net: ntb_netdev: Count packets dropped on RX refill failure commit 31ded341c375bb2faac1d77ab0012a732ba3e2a6 upstream. When replacement skb allocation fails, ntb_netdev drops a packet that was received successfully and requeues the original buffer. The drop is counted, but rx_packets and rx_bytes are not. Count every good packet before allocating its replacement. Fixes: d2121faf133a ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4fd5f987d646ef111901f80cf67f51f7b9ede6c0 Author: Koichiro Den Date: Thu Aug 20 02:25:38 2026 +0900 net: ntb_netdev: Avoid double-accounting netif_rx() drops commit 82e15be2d8b9efa6fb1750528d9b6f40e6a8eea7 upstream. netif_rx() already accounts packets it drops in the core rx_dropped counter. ntb_netdev counts them again as both errors and drops. Leave netif_rx() drops to the core. Count the packet and bytes unconditionally since it was received successfully by the driver. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4890152a3069f5cb58cc24b08cfd5fe95e568fa1 Author: Koichiro Den Date: Mon Aug 17 14:35:19 2026 +0900 NTB: ntb_transport: Reject oversized TX buffers commit a4f2387db6f1cc2f03abba7f3a6807ad61e26ff7 upstream. ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-5-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 76c9ccc0c6bebfc74c0e727eda67687f5103ab06 Author: Koichiro Den Date: Mon Aug 17 14:35:18 2026 +0900 NTB: ntb_transport: Fail TX enqueue when the QP link is down commit 873ce713fef5dde0939220f04f3484ec86a16fba upstream. Commit f195a1a6fe41 ("ntb: Drop packets when qp link is down") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop. Fixes: f195a1a6fe41 ("ntb: Drop packets when qp link is down") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-4-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 89e14f6e4fd7ec9ff1b0a30256ee6992f5df4fca Author: Koichiro Den Date: Mon Aug 17 14:35:16 2026 +0900 NTB: ntb_transport: Recycle TX entries before client callbacks commit 256496397287334a19ed80ec7be92bffcae76b9d upstream. ntb_tx_copy_callback() invokes the client callback before returning the entry to tx_free_q. The callback may wake a stopped client queue, only for the next enqueue to find no local entry and return -EBUSY. The window is narrow, but the retry is unnecessary. Save the callback data and length, then return the entry to tx_free_q before invoking the client. A completion callback then means both the client buffer and transport entry are ready for reuse. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b351783e0a2ffbcf74e06db30fdae956d633df5 Author: Ruoyu Wang Date: Sat Aug 15 23:17:29 2026 +0800 net: openvswitch: fix nf_connlabels leak in ovs_ct_init commit f9de5db270a4c2641de87ee558c16a9bc6eb4cd8 upstream. ovs_ct_init() acquires a connlabels reference before initializing the conntrack limit state. If ovs_ct_limit_init() fails, its error is returned directly. The pernet core does not invoke the exit callback for the operation whose initialization failed, so ovs_ct_exit() cannot drop the reference. This leaves labels_used elevated when Open vSwitch pernet registration fails for an existing network namespace. Subsequent conntrack entries in that namespace may allocate label extensions even though Open vSwitch failed to register. Drop the connlabels reference before returning a conntrack limit initialization error. ovs_ct_limit_init() already releases its partial state, and the original error remains unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260815151729.3757984-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea5f7b45b582665541ddfb77dce98611354af4ab Author: Ilya Maximets Date: Sat Aug 15 02:58:56 2026 +0200 net: openvswitch: fix flow mask use-after-free on flow deletion commit 4e30317ff67a2eb12b4d890d39f72fd7e7117d48 upstream. The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042. Fixes: 56c19868e115 ("openvswitch: Make flow mask removal symmetric.") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260815005915.1097270-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ad715e713610d2d5473c3a6498c825ccecf26491 Author: Asim Viladi Oglu Manizada Date: Wed Aug 12 01:21:53 2026 +0000 net: tun: bound receive headroom commit 447c9303942c439a117d9b76ce6d6e2116b38ee7 upstream. tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths. Fixes: eaea34b23c46 ("net/tun: implement ndo_set_rx_headroom") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260812012139.2134643-1-manizada@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 54ed43a3ff5099557696a8cd3869b01f2e8d44d7 Author: Fabio Porcedda Date: Wed Aug 12 07:49:11 2026 +0200 net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition commit 1056e79fffd0841f43c6a1b25664b196b3caf1c6 upstream. Add the followin Telit Cinterion FE990D50 composition: 0x0991: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0991 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=2aa802d2 C: #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260812054911.447887-1-Fabio.Porcedda@telit.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 045e307ac21fbd735b789d8817b21be4d8ead054 Author: Aleksandr Khromov Date: Mon Aug 24 13:05:47 2026 +0300 slip: fix use-after-free in sl_sync() commit 2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d upstream. slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: /* Snapshot list, allow later requests */ list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); /* slip_devs[i] = NULL */ if (dev->needs_free_netdev) free_netdev(dev); ... /* Free network device */ kobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: they run under the same RTNL section, so the slot cannot have been reused in between. This also removes the second symptom of the missing exclusion: a destructor running after sl_alloc() had already handed the slot out to another channel used to clear a live entry, so sl_sync() stopped at that NULL, sl_alloc() returned the same index again, and register_netdevice() failed with -EEXIST because slN was still there. Reproduced on x86_64 with several threads looping over open("/dev/ptmx") + ioctl(TIOCSETD, N_SLIP) + close(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Aleksandr Khromov Link: https://patch.msgid.link/20260824100547.164773-1-haa@amicon.ru Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit dcb6db9ca6515fcd3e00c93ec5e27dc7a0a7012f Author: Weiming Shi Date: Tue Aug 18 23:45:15 2026 +0800 xdp: fix zero-copy frame layout commit 71283aaa6c65b3cec84caf1dc78560985737641f upstream. xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: b0d1beeff2a9 ("xdp: implement convert_to_xdp_frame for MEM_TYPE_ZERO_COPY") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260818154516.793517-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 639828ad4d374056167391dbaffd13dd5e5e5ddb Author: Alexandra Winter Date: Fri Aug 21 14:55:01 2026 +0200 net/iucv: filter frames in afiucv_hs_rcv() by ingress device commit 80230a18c164a4b5bbc048fe2768b219ac17bc5a upstream. afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Co-developed-by: Bryam Vargas Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260821125501.3718748-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 75ecc80ef0614a9f8441ab476fb748d3e919bea8 Author: Seiji Nishikawa Date: Wed Jul 1 02:43:48 2026 +0900 ipmi: si: Fix NULL pointer dereference after failed registration commit 6d920a75df9a83ab096b3cde7a643b656e4fdfeb upstream. try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs "Unable to get the device id" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well. Fixes: 2512e40e48d2 ("ipmi: Rework SMI registration failure") Cc: stable@vger.kernel.org Signed-off-by: Seiji Nishikawa Message-ID: <20260630174348.1483814-1-snishika@redhat.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 8990c7f6bfc1e7689b7012a7d4d0efb9f07a9c89 Author: Yousef Alhouseen Date: Wed Jun 24 19:53:53 2026 +0200 ipmi: ipmb: validate write message length commit 53637506884dbd5c91a89b1a3547d99d80f8ed2c upstream. ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message. Fixes: 51bd6f291583 ("Add support for IPMB driver") Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Message-ID: <20260624175353.8592-1-alhouseenyousef@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 03c3af594dea9196cf6ca70d914b42aa8c873c35 Author: Kuan-Wei Chiu Date: Thu Apr 16 19:08:40 2026 +0000 interconnect: Fix use after free in icc_get() and of_icc_get_by_index() commit 25c7e242aca084fdc1098248194032317dca625d upstream. In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock. Fixes: 3791163602f7 ("interconnect: Handle memory allocation errors") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu Link: https://patch.msgid.link/20260416190840.1753468-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov Signed-off-by: Greg Kroah-Hartman commit 3a76b87e1d065183e2e7ae5b800cb1f6e84f543d Author: Bryam Vargas Date: Thu Jun 18 00:46:28 2026 -0500 platform/chrome: sensorhub: Bound the EC-reported sensor number commit 833740a2333c2e4db4e02e3d0ffba04e8718a5f3 upstream. Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit 5bb5327b92aae17e91c7228953c350a6ee3c94e8 Author: Fan Wu Date: Thu Jul 23 11:28:41 2026 +0000 mmc: via-sdmmc: stop card-detect handling on probe failure commit 088eaa92fcebaa6b957ccf9635afdf39643a577d upstream. request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: e4e46fb61e3b ("mmc: via-sdmmc: fix return value check of mmc_add_host()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f870f2d8c417719091a4eae722efbdf52500e735 Author: Kevin Tian Date: Wed Aug 5 07:42:59 2026 +0800 iommu/vt-d: Fix no_iommu to disable platform opt-in commit 219cc978d69ce9b538d0d73936c569d4ca5b0a24 upstream. If user explicitly requests to disable iommu (via "iommu=off" or "intel_iommu=off"), there is no reason to force enabling it due to platform opt-in (for external-facing devices). User should be aware of any security implication of doing so. "intel_iommu=off" implements this policy by setting no_platform_optin to skip platform opt-in in platform_optin_force_iommu(). However, "iommu=off" (no_iommu=1) doesn't set no_platform_optin hence is broken in this aspect: - detect_intel_iommu() doesn't request ACS if no_iommu=1 - platform_optin_force_iommu() forces iommu on if external-facing devices exist and no_platform_optin is not set This leads to a bad configuration with ACS disabled while DMA remapping is enabled. Instead of setting no_platform_optin (will soon be removed) for no_iommu=1, directly check no_iommu in platform_optin_force_iommu(). Fixes: 89a6079df791 ("iommu/vt-d: Force IOMMU on for platform opt in hint") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 8a3a54aa3e65ed76f8560a387243a7738ae0cb1c Author: Krzysztof Wilczyński Date: Mon Jul 20 20:41:45 2026 +0000 PCI/proc: Use file_ns_capable() when checking config space read access commit f82f53e75eff382fc8f56b73279b54f7cf5a5c65 upstream. proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 ("pci: check caps from sysfs file open to read device dependent config space"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 ("pci: use security_capable() when checking capablities during config space read") and converted to the dedicated helper in commit ab0fa82b2df9 ("pci-sysfs: use proper file capability helper function"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204145.1500105-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1097361ef0a0341421e21bdecbe8001f3d7034e4 Author: Krzysztof Wilczyński Date: Wed Jul 29 07:59:09 2026 +0000 PCI/proc: Avoid spurious runtime PM wakeup on config space accesses commit 4ff664a81d729b37f2eb65de80a670abfb61c9a0 upstream. Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return early for zero-length configuration space accesses at valid offsets. Such an access invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync(), and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already returns early for in-range zero-length binary attribute accesses before pci_read_config() or pci_write_config() is invoked. In contrast, the VFS forwards zero-length requests to the procfs callbacks, where they continue into runtime PM handling. Return early from proc_bus_pci_read() and proc_bus_pci_write() when nbytes is zero, before any runtime PM involvement. The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729075909.1219906-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 56eed253aa31506eb85e0bb90c23b499cea8eed8 Author: Krzysztof Wilczyński Date: Mon Jul 20 20:43:56 2026 +0000 PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses commit b14b2bab88d7099ab4447560cbe4b40945e5c069 upstream. Currently, the boundary checks in pci_read_config() and pci_write_config() reject only offsets beyond the effective configuration space size. An access at an offset exactly equal to that size passes the check, has its length clamped to zero, and then invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync() and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already clamps accesses against the attribute size set through the bin_size() callback, which reports either 256 or 4096 bytes. As such, the affected accesses are reads at offset 64 (or 128 for CardBus devices) through files opened without CAP_SYS_ADMIN, and reads and writes at the exact configuration space size on devices where a quirk sets a non-standard size. Reject accesses at the boundary offset as well, so they return early before any runtime PM involvement, matching the procfs implementations in proc_bus_pci_read() and proc_bus_pci_write(). The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: tweak commit log, order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204356.1501749-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 00fa1f5b15593a5f4474c85d4a8b56f0d5a0089b Author: Ronald Claveau Date: Tue Jun 16 09:07:25 2026 +0200 PCI: meson: Fix GPIO state while requesting PERST# commit 40fb390cbcc11797c44c16dabdf763ec87643671 upstream. Meson devicetree defines the PERST# GPIO as 'reset' GPIO. Commit 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor") inverted the PERST# assertion logic to use proper GPIO descriptor semantics and moved the polarity configuration to the device tree as GPIO_ACTIVE_LOW. However, the initial PERST# GPIO state "GPIOD_OUT_LOW" was not updated accordingly. This results in the enumeration failure of the endpoint devices as PERST# would get deasserted while requesting the GPIO even before power and REFCLK becomes stable. Without this fix: ahci 0000:01:00.0: enabling device (0000 -> 0002) ahci 0000:01:00.0: SSS flag set, parallel bus scan disabled ahci 0000:01:00.0: Controller reset failed (0xffffffff) ahci 0000:01:00.0: probe with driver ahci failed with error -5 With this fix: ahci 0000:01:00.0: enabling device (0000 -> 0002) ahci 0000:01:00.0: AHCI vers 0001.0300, 32 command slots, 6 Gbps, SATA mode ahci 0000:01:00.0: 1/1 ports implemented (port mask 0x1) ahci 0000:01:00.0: flags: 64bit ncq led clo only pio ccc Change the GPIO request flag from GPIOD_OUT_LOW to GPIOD_OUT_HIGH to get the right behaviour. Fixes: 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor") Signed-off-by: Ronald Claveau [mani: CCed stable and commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Neil Armstrong Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616-fix-meson-pcie-reset-gpio-v1-1-fca404b4c8be@aliel.fr Signed-off-by: Greg Kroah-Hartman commit 5c79fef1db9d018f379f8706a095d6087b6187fb Author: Mohamad Raizudeen Date: Thu Jul 23 22:42:03 2026 +0530 PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk commit 23d7eed5974989de56273c964d7e510e4aad91e8 upstream. pci_quirk_enable_intel_rp_mpc_acs() reads a 32-bit DWORD from the MPC register, sets bit 26 (INTEL_MPC_REG_IRBNCE), but it writes it back using pci_write_config_word(). Because bit 26 resides in the upper 16 bits of the 32-bit register, a 16-bit write drops the newly set bit. The quirk logs that it is enabling IRBNCE, but the hardware never actually receives the command. Use pci_write_config_dword() to ensure the full 32-bit value is written back to the hardware. Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") Signed-off-by: Mohamad Raizudeen Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723171203.4892-1-raizudeen.kerneldev@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9e063165d3fe58db2a517717b830f17e82d03467 Author: Stefan Haberland Date: Wed Aug 5 13:15:55 2026 +0200 s390/dasd: Propagate partial completion length across ERP recovery commit 6fb5ba2e7e43173a3761e46f091070a8185efa14 upstream. dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state. Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 644b666c202cce12ccfcf9ded67089b18f4f7659 Author: Stefan Haberland Date: Wed Aug 5 13:15:56 2026 +0200 s390/dasd: Guard sysfs discipline callbacks against unallocated private data commit 2a1780f9fc2493bd34c418a0be6fc58943afcecf upstream. Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private. Fixes: c729696bcf8b ("s390/dasd: Recognise data for ESE volumes") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8cb96cffceead3cbd0541154d7ecc5e6474edda1 Author: Stefan Haberland Date: Wed Aug 5 13:15:54 2026 +0200 s390/dasd: Do not complete a failed ESE read as successful commit cddb447c62466f3076938ce120028d7b591f9f37 upstream. dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS. Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-2-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6bd453e328a0325f838c3bf64d4609c6c1866ed7 Author: Jianing Li Date: Mon Aug 10 08:47:01 2026 +0800 power: supply: max17040: synchronize work cancellation on suspend commit 86a3a8a926aa5969c329d1df2d3259f189961bbc upstream. max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes. Fixes: c6f4a42de60b ("Add MAX17040 Fuel Gauge driver") Cc: stable@vger.kernel.org Signed-off-by: Jianing Li Link: https://patch.msgid.link/20260810004701.1683-1-m13940358460@163.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 1321a4e6247164312eabc6d07f88572da2ee308c Author: Fan Wu Date: Fri Aug 7 03:35:20 2026 +0000 power: supply: lp8727: fix use-after-free in lp8727_release_irq() commit ceb6ac43b0f591722401922ceb958ce2616935e0 upstream. lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool. Fixes: d71fda016102 ("lp8727_charger: Clean up the interrupt handler") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260807033520.8551-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit e951b65ef1699439079b723ca5c72cbe44771647 Author: Jameson Thies Date: Wed Jul 22 19:50:59 2026 +0000 power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS commit 657cd3a42e937276262c0a8ae6b01a87004309de upstream. Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS. Fixes: 3af15cfacd1e ("power: supply: cros: add support for dedicated port") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260722195059.1420738-1-jthies@google.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 0b5096f6804161b61451b1cec0e38678630be849 Author: Bryam Vargas Date: Tue Jun 16 23:59:45 2026 -0500 power: supply: cros_usbpd-charger: bound the EC-reported port count commit 48355ce49359740f52e94d3623f6fc557ce341f0 upstream. cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */ ... for (i = 0; i < charger->num_charger_ports; i++) charger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: if (num_charger_ports < num_usbpd_ports || num_charger_ports > num_usbpd_ports + 1) return -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold. Fixes: f68b883e8fad ("power: supply: add cros-ec USBPD charger driver.") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260616-b4-disp-5e197080-v2-1-8aa5bffce945@proton.me Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 041f7df5a929d3e7435dd8387e8ea17f2d412b7d Author: Jun Yang Date: Mon Aug 24 16:18:20 2026 +0800 sctp: fix stream->outcnt underflow on duplicate RECONF responses commit 3faf13aff243ca9f78d08b1a2956ef5a6fc77b6e upstream. A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Link: https://lore.kernel.org/netdev/20260730110225.37371-1-juny24602@gmail.com/ Suggested-by: Xin Long Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-3-juny24602@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 76224f1b719caa429e35a8aa07e4d9c3b1f9bc0d Author: Jun Yang Date: Mon Aug 24 16:18:19 2026 +0800 sctp: distinguish sequence zero from wildcard in reconf lookup commit 63f44178f0a0f86060c9b576d6efab8a3ffa403e upstream. Zero is a valid response sequence after strreset_outseq wraps, but sctp_chunk_lookup_strreset_param() currently treats it as a wildcard. Add match_seq so response lookups match zero exactly while the one type-only lookup can still ignore the sequence. Fixes: 50a41591f110 ("sctp: implement receiver-side procedures for the Add Outgoing Streams Request Parameter") Cc: stable@kernel.org Suggested-by: Simon Horman Acked-by: Xin Long Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-2-juny24602@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 79ff751311e80fa0370007e46a79a6d601685e75 Author: Weiming Shi Date: Mon Aug 24 01:28:58 2026 +0800 sctp: fix NULL deref on untransmitted RECONF completion commit 2db9bfa3e27bdea15e05ea70b56bad3d21e570ec upstream. sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: t = asoc->strreset_chunk->transport; if (timer_delete(&t->reconf_timer)) sctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites. Fixes: 810544764536 ("sctp: implement receiver-side procedures for the Outgoing SSN Reset Request Parameter") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Suggested-by: Xin Long Assisted-by: Claude:claude-opus-5 Signed-off-by: Weiming Shi Acked-by: Xin Long Link: https://patch.msgid.link/20260823172857.896146-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3fc072e7cb4a0ff251d13cfc2d24f62489cd9386 Author: Hyunwoo Kim Date: Wed Aug 19 10:38:37 2026 +0900 sctp: drop a chunk if its transport was removed commit 03a9d10ecf71f54b2af8020935f2033d4a132be5 upstream. sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/aoUJHQmxL0LFIMCw@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7d970353eeb98f46a3b9dc602850e4f6336a9889 Author: Hyunwoo Kim Date: Sat Aug 15 07:36:18 2026 +0900 sctp: stop processing a packet once its association is deleted commit 47e15a8d12e366d0d261bcbc394394f44418938d upstream. sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/an-YYtoqw1QpTXUL@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32ea8ce96b9bd797c59c351ce490ffd97adaa8c0 Author: Yehyeong Lee Date: Sat Aug 1 17:18:18 2026 +0900 nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone commit 3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36 upstream. Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two. Fixes: 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 76139b5bbf531e675934b97227be3521c7fdd537 Author: Yehyeong Lee Date: Thu Jul 30 20:36:24 2026 +0900 nvme: zero the discard fallback page commit bededeaaeff404978a5a8e2a605a6c3017cddd3e upstream. nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent. Fixes: 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 1535115ea46b16e6bf4c5d89759b4fface421ea5 Author: Ewan D. Milne Date: Wed May 13 15:25:51 2026 -0400 nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error path commit 22eb631bf86ee3246f47885e4fa94154a46863e4 upstream. nvme_fc_create_hw_io_queues() will call __nvme_fc_delete_hw_queue() for the last queue on which __nvme_fc_create_hw_queue() reported an error when deleting all the io queues if they cannot all be created. This is incorrect since the last queue did not actually get created. The most recent change to this code was commit 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") which moved the cleanup to the delete_queues: label and changed the loop bounds, however the code was not correct prior to this change in a different way. The original commit e399441de911 ("nvme-fabrics: Add host support for FC transport") had a different error which called __nvme_fc_delete_hw_queue() on queue index 0 which is used for the admin queue. Fix this by correcting the initial loop index when deleting the io queues. Fixes: 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") Fixes: e399441de911 ("nvme-fabrics: Add host support for FC transport") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Maurizio Lombardi Reviewed-by: Laurence Oberman Reviewed-by: Justin Tee Signed-off-by: Ewan D. Milne Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit e3c413f789eaf0170275c7eba523ead73d963f30 Author: Michael Bommarito Date: Sun May 24 07:55:27 2026 -0400 lockd: pin next file across nlm_inspect_file lock-drop commit 526c49cff3f72c3ec74752016380c7567040581b upstream. nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table. Fixes: 01df9c5e918a ("LOCKD: Fix a deadlock in nlm_traverse_files()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260524115527.1734251-1-michael.bommarito@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 17ae7b97051e469db5054c71c42e09f5a0c4e888 Author: Cong Nguyen Date: Mon Aug 10 11:27:54 2026 +0700 hwmon: (max6621) fix temperature clamp range commit 24fbeb83d9b750a36da42cb835a154d80fd3d495 upstream. MAX6621_TEMP_INPUT_MIN and MAX6621_TEMP_INPUT_MAX are used to clamp the writable offset and critical thresholds. They are defined as -127000 and 128000. The driver decodes the temperature through an s8 and its own comment in max6621_read() documents an 8-bit two's complement value, whose range is -128 to +127 degrees C. The current limits therefore reject the valid -128 degrees C and accept +128 degrees C, which does not fit the 8-bit range. Correct the limits to -128000 and 127000. Fixes: 92b64580f14b ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://lore.kernel.org/r/9d3a4f1895a47794bb359a2a32fb1ccd6a15812c.1786334038.git.congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d3cd9b8963da7ff83761976dd8b00e4e0b1c7862 Author: Cong Nguyen Date: Mon Aug 10 11:28:39 2026 +0700 hwmon: (max6621) fix negative temperature offset and crit readings commit acc52bd431e2d8698fae8d82a74ac45d79b62e0a upstream. max6621_read() reads the CONFIG2 offset and the critical alert threshold registers into a u32 and scales them without sign extension: /* offset */ *val = (regval >> MAX6621_REG_TEMP_SHIFT) * 1000L; /* crit */ *val = regval * 1000L; Both attributes are writable and their write paths clamp to a negative minimum and encode negative values, so a value written as negative is read back as a large positive number. For example, writing a -10 degrees C offset stores max6621_temp_mc2reg(-10000) = (-10 << 6) = 0xfd80; the read then computes 0xfd80 >> 6 = 1014 -> 1014000 instead of -10000. Cast the register value to s16 before scaling so the read preserves the sign the write path encodes. The temperature input path already uses an s8 intermediate and is left unchanged. Fixes: 92b64580f14b ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://lore.kernel.org/r/ad0baddbd6163cf73545c8e9273258136718585c.1786334038.git.congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5de5d554141a15b3f1f5c978fd9f7f4fd6d0600a Author: Norbert Szetei Date: Sat Aug 22 11:12:11 2026 +0200 openvswitch: only skb_tx_error() a packet we are about to drop commit 0dbc2398fca3bb33eda963849f865ddb1b3aa05e upstream. queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says "skb must be freed afterwards"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the "Fragnesia" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the "default" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Link: https://patch.msgid.link/55A52703-7548-4A55-A9CE-2A37145BDCAD@doyensec.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit bf310718c6fa6adeee06d207a55489546d860e2c Author: Ali Ahmet Memis Date: Fri Aug 21 01:45:27 2026 +0000 openrisc: fix arbitrary kernel memory access via or1k_atomic syscall commit 78004e9a87f240df03e2f73120d291763c32e0a7 upstream. sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style] Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit c28dc3407937aa8f225942538cd585c9b28ea65a Author: Zhan Xusheng Date: Thu Aug 6 10:20:44 2026 +0800 ocfs2: fix readdir position truncation on 32-bit kernels commit a63308ab426f3a3c7e33b02c150ea59054620261 upstream. In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask ~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected. Link: https://lore.kernel.org/20260806022044.167962-3-zhanxusheng@xiaomi.com Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Zhan Xusheng Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Andreas Dilger Cc: Jan Kara Cc: Ojaswin Mujoo Cc: "Ritesh Harjani (IBM)" Cc: Ted Ts'o Cc: "zhangyi (F)" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 15c656e3ac48405300e11c95bbb98cb2d80b8c4f Author: Joseph Qi Date: Wed Jul 22 20:49:33 2026 +0800 ocfs2: cluster: fix o2hb_dependent_users leak on pin failure commit 12c2ab42dbe227956c765e2674364bfca5de0533 upstream. In o2hb_region_inc_user(), o2hb_dependent_users is incremented unconditionally before calling o2hb_region_pin(). If the pin fails, the counter is never decremented and any partially-pinned regions are never unpinned, since the caller does not call o2hb_region_dec_user() on error. The leaked counter causes subsequent o2hb_region_inc_user() calls to skip pinning entirely (the > 1 check), leaving heartbeat regions unprotected. Fix by rolling back on failure: call o2hb_region_unpin(NULL) to release any partially-pinned regions and decrement o2hb_dependent_users to restore the pre-increment state. Link: https://lore.kernel.org/20260722124933.430554-4-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3043b9b788ba94ef989c176e3cb6bef8d1b26e5e Author: Joseph Qi Date: Wed Jul 22 20:49:32 2026 +0800 ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from drop_item commit cd789996db3c87427343f54f509d17810bd7ba7c upstream. o2hb_heartbeat_group_drop_item() is called from configfs rmdir with the parent directory's inode_lock held. It calls o2hb_region_pin() -> o2nm_depend_item() -> configfs_depend_item(), which acquires the configfs root inode_lock. This creates a parent -> root inode_lock nesting that could deadlock against paths taking root -> parent (e.g. subsystem unregistration). Fix this by using configfs_depend_item_unlocked() when o2hb_region_pin() is called from a configfs callback context. This variant skips the root inode_lock when caller and target are in the same subsystem, which is safe because VFS already holds a lock preventing unregistration. Add o2nm_depend_item_unlocked() wrapper and a from_callback parameter to o2hb_region_pin() to select the appropriate variant. Link: https://lore.kernel.org/20260722124933.430554-3-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4d64f8da82fb9e8dbd5aa9b64c9bb6ac0decea03 Author: Joseph Qi Date: Wed Jul 22 20:49:31 2026 +0800 ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() commit af09df89db9a68a1d76df0f75667998135bc8d65 upstream. Patch series "ocfs2: cluster: o2hb_region_pin() fixes", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep. Link: https://lore.kernel.org/20260722124933.430554-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20260722124933.430554-2-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f882e9e32d017a6569b2996c63ba3864717788e6 Author: Ibrahim Hashimov Date: Thu Jul 9 15:26:09 2026 +0200 ocfs2: validate rl_used against rl_count in refcount block validator commit 4ca62df6bc0708947b48da3f6a712ecb8e73929c upstream. ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { rec = &rb->rf_records.rl_recs[i]; ... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: if (index < le16_to_cpu(rf_list->rl_used)) memmove(&rf_list->rl_recs[index + 1], &rf_list->rl_recs[index], (le16_to_cpu(rf_list->rl_used) - index) * sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the "used" bound before any code walks h_list.l_recs[]: if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { rc = ocfs2_error(...); goto bail; } if (le16_to_cpu(eb->h_list.l_next_free_rec) > le16_to_cpu(eb->h_list.l_count)) { rc = ocfs2_error(...); goto bail; } Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing "!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count. Link: https://lore.kernel.org/20260709132609.44233-1-security@auditcode.ai Fixes: f2c870e3b12e ("ocfs2: Add ocfs2_read_refcount_block.") Signed-off-by: Ibrahim Hashimov Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Assisted-by: AuditCode-AI:2026.07 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4a5798253212093b9ff7d90c6cfbe348bcda1594 Author: Bryam Vargas Date: Mon Jun 29 00:01:44 2026 -0500 ocfs2: validate lengths in dlm_mig_lockres_handler commit b54e03d9b3697d25f4a0063cf717d459c5e3ad94 upstream. A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected. Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-2-6953bcc0421f@proton.me Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Bryam Vargas Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e1288865b8ceac0dcd1009ecba43de961f13d5bd Author: Bryam Vargas Date: Mon Jun 29 00:01:43 2026 -0500 ocfs2: bound namelen in dlm_migrate_request_handler commit ea5b5609305a8437bc955a0834a530c12246d78f upstream. Patch series "ocfs2/dlm: bound peer-controlled lengths in the o2dlm". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected. Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-0-6953bcc0421f@proton.me Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-1-6953bcc0421f@proton.me Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Bryam Vargas Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5ff30f07def6d0e6edacf47952807b5ff60f3af6 Author: Dmitry Antipov Date: Tue Jul 21 13:28:40 2026 +0300 ocfs2: always run deallocs on copy-on-write completion commit 82ea9d4fc05fb7a387db547c6a7c0aa6a3719616 upstream. Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 This happens when 'ocfs2_cache_block_dealloc()' called from 'ocfs2_cache_extent_block_free()' uses the suballocator to schedule extent removal, so 'ocfs2_run_deallocs()' should be run unconditionally to complete the removal with 'ocfs2_free_cached_blocks()'. An extra semi-automated static analysis [1] suspects that the same scenario looks possible in 'ocfs2_attach_refcount_tree()' and 'ocfs2_reflink_remap_blocks()' as well, but, since 'ocfs2_run_deallocs()' is a safe no-op for an empty dealloc context, 'ocfs2_create_reflink_node()' and 'ocfs2_reflink_xattrs()' may be adjusted in the same way too, thus keeping the code pattern consistent. Link: https://lore.kernel.org/20260721102840.387663-1-dmantipov@yandex.ru Link: https://lore.kernel.org/ocfs2-devel/f1d7e266-4b44-41b9-98c0-5b3868a8d9c3@yandex.ru [1] Fixes: 6f70fa519976 ("ocfs2: Add CoW support.") Signed-off-by: Dmitry Antipov Suggested-by: Joseph Qi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 173bfd69696815bcf1c052f61cb69c26cca4e443 Author: Zhiling Zou Date: Fri Jul 24 02:01:46 2026 +0800 orangefs: skip leading spaces before parsing client debug masks commit d410cd5303ec59c7cf23dd61423752ce8e9ecb59 upstream. orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, " "), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf(). Fixes: f7be4ee07fb7 ("Orangefs: kernel client part 4") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit 712c4235fcc73c11a2f1d59a499d489e49c374a4 Author: Yifei Gao Date: Mon Aug 3 01:07:55 2026 +0000 orangefs: fix double-free of trailer_buf on readdir copy failure commit f574296be7f46eb60beca851240b526df232f480 upstream. On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op. Fixes: 382f4581e67f ("orangefs: rewrite readdir to fix several bugs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit f3666548a4abf995bb0c9e790eb18450465ee09c Author: WenTao Liang Date: Sat Jun 27 00:03:26 2026 +0800 regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after ownership transferred to rdata commit 7c8cc25d8d86f9eb3979255935cfdc7d062ad746 upstream. In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a reference on reg_np which is then stored in rdata->reg_node, transferring ownership to the regulator data array. The subsequent of_node_put(reg_np) at the end of the function releases the last matched regulator node's reference, leaving rdata->reg_node as a dangling pointer for the last entry. Remove the spurious of_node_put(reg_np) call. Cc: stable@vger.kernel.org Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d9b1407477fb736978b04108073180ca84958936 Author: WenTao Liang Date: Sat Jun 27 00:01:50 2026 +0800 regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer commit f9324d670ae0b88cbfb0aa48fcaefa5baeb8da4c upstream. In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference. Cc: stable@vger.kernel.org Fixes: bc407334e9a6 ("regulator: as3722: add regulator driver for AMS AS3722") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260626160150.54291-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3dd07b369371a2f29e1c3caf1ade85bb92b4c551 Author: Norbert Szetei Date: Mon Jul 27 10:08:36 2026 +0200 RDMA/ucma: Lock the handler in ucma_set_ib_path() commit ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820 upstream. ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call. Fixes: 09e328e47a69 ("RDMA/ucma: Fix the locking of ctx->file") Link: https://patch.msgid.link/r/2823D190-92D5-4714-8769-4FB643C64FF3@doyensec.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e6e79e7be87c5ea92728060a3d7fb56890a91e45 Author: Fan Wu Date: Thu Aug 6 13:01:27 2026 +0000 RDMA/cxgb4: Cancel reg_work before freeing device on remove commit a7100601aa1a39f799a566acce10db20eaf4b7f2 upstream. c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool. Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking warning") Link: https://patch.msgid.link/r/20260806130128.465460-1-fanwu01@zju.edu.cn Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e2214e2793154b745436e46c6a9a7985d9b3781d Author: Vaibhav Nagare Date: Tue Aug 18 13:03:09 2026 +0530 qede: Fix NULL pointer dereference in TPA fragment processing commit 06aa3d26327f24edd039ff249672fdf6f2ba5695 upstream. Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a "ghost" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage. Fixes: 8a8633978b84 ("qede: Add build_skb() support.") Cc: stable@vger.kernel.org Signed-off-by: Vaibhav Nagare Link: https://patch.msgid.link/20260818073309.2266072-1-vnagare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f1c9512ae072996647fb829c6402348d1b72af39 Author: Johan Hovold Date: Mon Jul 6 08:56:14 2026 +0200 remoteproc: scp: Fix device reference leak on failed lookup commit 22f9efb3ae07f966a1901d929d16df1388cce65c upstream. Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away. Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Cc: stable@vger.kernel.org # 5.6 Cc: Erin Lo Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20260706065614.389412-1-johan@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit aced522709e06bfb90e0d7147c2c104669aa197e Author: Chunkai Deng Date: Thu Jun 18 00:16:39 2026 -0700 rpmsg: glink: smem: order FIFO read after availability check commit 786439ad58763e04b91bc2ec5f590e463939f197 upstream. glink_smem_rx_peek() reads the RX FIFO payload after the caller has determined data is available via glink_smem_rx_avail(), which reads the remote-updated head index. A control dependency between the head read and the subsequent payload read does not order the two loads, so the CPU may speculatively read the FIFO before observing the head update and consume stale data the remote has not yet published. Add rmb() in glink_smem_rx_peek() before the memcpy_fromio() so the availability (head) read is ordered ahead of the FIFO payload read, matching the consumer pattern in Documentation/core-api/circular-buffers.rst. Fixes: caf989c350e8 ("rpmsg: glink: Introduce glink smem based transport") Cc: stable@vger.kernel.org Signed-off-by: Chunkai Deng Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260618-rpmsg-glink-smem-mb-v1-1-68a026453a69@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 225587bdbf4b0eb5265a71ee4dc183561a1857fc Author: Doruk Tan Ozturk Date: Mon Jul 13 23:32:51 2026 +0200 wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets commit 3bbd05723d15dd06f0560bcd94fbf9a91b5f5613 upstream. ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260713213251.21161-1-doruk@0sec.ai Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit f64e01a90326bb85a3cc8aa0199931dc2f15b589 Author: David Lee Date: Wed Jul 8 10:17:09 2026 +0000 udf: reject VAT indexes equal to the entry count commit cac0cb07f29ccfb373fd4a36c81e908ef3ce608c upstream. UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Link: https://patch.msgid.link/20260708101712.1706564-1-david.lee@trailofbits.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ac9efc29346b6942e71f0e24a3178a9121330fab Author: Chuck Lever Date: Thu May 28 15:32:08 2026 -0400 SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field commit ad484748eec0a66eac0f13ab53b3fbedb7333c91 upstream. gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit "extra count" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob. Fixes: cf4c024b9083 ("sunrpc: trim off EC bytes in GSSAPI v2 unwrap") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-1-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 159a4fab7170badd6c4a553aef81cac079d6f4ee Author: Chris Mason Date: Sat May 30 20:42:52 2026 -0400 sunrpc: init gssp_lock before publishing proc entry commit 5ce1ed6159731a41fdd0b03eedbed4e147036a5a upstream. create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data("use-gss-proxy", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a "lock used without init" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry. Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260530-tier2-local-v2-1-5a0fd532db57@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3691c4b3488d8ca046b9941e5be30c626dbbbb50 Author: Chris Mason Date: Sat May 23 21:02:11 2026 -0400 SUNRPC: harden gss_unwrap_resp_priv length checks commit 87831b92112c81db251d46756d65daa4f91af6a2 upstream. gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length"). Fixes: 2d2da60c63b6 ("RPCSEC_GSS: client-side privacy support") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-3-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 299d281c7225ded15b28cb861a98d818d82787fc Author: Chris Mason Date: Sat May 23 21:02:13 2026 -0400 SUNRPC: harden gss_krb5_unwrap_v2 against short tokens commit 6959297aaa9572783d620a226d73c3fb94494888 upstream. gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction. Fixes: de9c17eb4a91 ("gss_krb5: add support for new token formats in rfc4121") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-5-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b0aa6a03d30c4ee51b4d4eb287fc79b413cd2816 Author: Chris Mason Date: Thu May 28 15:32:11 2026 -0400 SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat commit f8870b9b75afb77986bc65940a231d54068ff2b1 upstream. svcauth_gss_release() reads gc_proc and switches on gc_svc before consulting rq_auth_stat. On the SVC_DENIED path after a failed svcauth_gss_accept(), those fields may hold stale values from a prior request or uninitialized slab residue: svcauth_gss_accept() allocates gss_svc_data with non-zeroing kmalloc and clears only gsd_databody_offset and rsci per request, not clcred. Because RPC_GSS_PROC_DATA is zero, a zeroed or stale-zero gc_proc passes the existing guard and falls through into the gc_svc switch, which can dispatch to svcauth_gss_wrap_integ() or svcauth_gss_wrap_priv(). Both wrap helpers call svcauth_gss_prepare_to_wrap() before any rsci->mechctx dereference, and that helper already returns early when rq_auth_stat is not rpc_auth_ok, so the downstream NULL dereference is blocked. The dispatch itself remains structurally wrong: it reads scalars that the caller has no contract to have initialized after a failed authentication. Mirror the existing rq_auth_stat gate in svcauth_gss_prepare_to_wrap() one frame up, so svcauth_gss_release() skips the clcred dispatch entirely when authentication has not succeeded. The cleanup tail that releases rq_client, rq_gssclient, cr_group_info, and rsci still runs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-4-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit dec787a15c96a5665e9ffc61b429a6a4ab26e6b9 Author: Jeff Layton Date: Tue May 26 15:35:06 2026 -0400 SUNRPC: always drain cache_cleaner before destroying a cache_detail commit f42d0fda0c67695db6bc704b04b7c10240805377 upstream. sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered. Fixes: 820f9442e711 ("SUNRPC: split cache creation and PipeFS registration") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260526-cache_cleaner_vs_destroy_no_sync-v1-1-a707a6fcfd32@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9accc25e5af0bac8479f6054e674b2c593c45281 Author: Jeff Layton Date: Mon Jul 6 09:29:21 2026 -0400 sunrpc: route to a populated pool in svc_pool_for_cpu() commit f6310491c4cdb88af73aa551ec9df1f10a90c709 upstream. svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in "pernode" or "percpu" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race(). Fixes: bfd241600a3b ("[PATCH] knfsd: make rpc threads pools numa aware") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260706-sunrpc-pool-mode-v5-1-6c4ee7cd89aa@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a3d77bcd974b8625d16bddf448cb3a1b5e37049c Author: Chris Mason Date: Sat May 23 21:02:12 2026 -0400 SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow commit 3f491306dcb673ff5e78e1044ba450c58978774e upstream. xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case. Fixes: 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-4-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4534e0eead692bb069ad1e6a5a245fc2e2078300 Author: Harshit Varu Date: Sat Aug 15 17:22:05 2026 +0530 mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction commit b878dfdd12d7a5b8722a78d35e313506140ca3d9 upstream. mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Cc: stable@vger.kernel.org Signed-off-by: Harshit Varu Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260815115205.197151-1-harshitvaru666@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit aa4fe0b450a461aa1162fe8375f5d28f4c957df8 Author: Qing Ming Date: Fri Aug 14 17:54:04 2026 +0800 mpls: reload header after pskb_may_pull() commit 29e63b8d9fc150cc191b1c6eb7e16e1247e1b650 upstream. mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer. Fixes: 9f427a0e474a ("net: mpls: Fix multipath selection for LSR use case") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260814095404.7205-1-a0yami@mailbox.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 94c820d99a4305d4ded41a97ed37ec7d26c56e7f Author: Coly Li Date: Mon Jul 20 19:14:00 2026 +0800 md: do overflow check for sb->bblog_shift in super_1_load() commit 35d522bd32462afcf1981dab6da8a9256c26c1e0 upstream. In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant. Fixes: 2699b67223ac ("md: load/store badblock list from v1.x metadata") Fixes: 1726c7746783 ("badblocks: improve badblocks_set() for multiple ranges handling") Cc: stable@vger.kernel.org Cc: Ramesh Adhikari Signed-off-by: Coly Li Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720111400.2120834-1-colyli@fygo.io Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit b4975f2ff6c82adc24ae547f029f82530ba43cfe Author: Bryam Vargas Date: Wed Jun 24 01:03:45 2026 -0500 libnvdimm/labels: Prevent integer overflow in __nd_label_validate() commit 037770686126155eafc44501312989e2837b9659 upstream. The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e ("libnvdimm: namespace indices: read and validate"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label(). Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") Cc: stable@vger.kernel.org Reviewed-by: Alison Schofield Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-1-cdb6cab28b41@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit dffbfb3117138e8e0e09d05f507bd36ca1f696e5 Author: Yuyang Huang Date: Sat Aug 15 17:46:51 2026 +0900 ipv6: use RCU iterator to dump route exceptions commit 47cdab0d51aaa9bd85f8e4904585bd5bd4df4488 upstream. rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list. Fixes: 1e47b4837f3b ("ipv6: Dump route exceptions if requested") Cc: stable@vger.kernel.org Signed-off-by: Yuyang Huang Reviewed-by: Stefano Brivio Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260815084651.69477-1-sigefriedhyy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cb1afd087aedc90e5274537e4fb9bf3f98e5afdb Author: Zhiling Zou Date: Thu Aug 13 00:22:34 2026 +0800 ip6_gre: fix hardware header length for NBMA tunnels commit 505b6d296c486ef7d1274f279d4c43a172f63224 upstream. ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices. Fixes: 832ba596494b ("net: ip6_gre: set dev->hard_header_len when using header_ops") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/64b46542bbe1701f07702aaa50273e2a87903db5.1786542637.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 6e8eff8ed13b14708bc39f170144eacde494aac6 Author: Zhiling Zou Date: Tue Aug 11 21:31:11 2026 +0800 ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() commit 87f21b59ddc618eff9670c174842964ad65fdade upstream. ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit(). Fixes: 058214a4d1df ("ip6_tun: Add infrastructure for doing encapsulation") Cc: stable@vger.kernel.org Reported-by: Vega Reviewed-by: Ido Schimmel Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/30807a062ccc5c9c8a5ec2c5eb805ef279c50bdd.1786452593.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9db7f3327b899fdd6e135833adac9825e6790087 Author: Guangshuo Li Date: Sat Aug 8 13:30:57 2026 +0800 Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is negative commit c7e9a8cb6918656884a0757c92465075c7555ffa upstream. intel_set_power() calls pm_runtime_use_autosuspend() when powering on the device, but the power-off path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: 74cdad37cd24 ("Bluetooth: hci_intel: Add runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 4539e074340c7e320b4c06f80ea2bd89a569f202 Author: Valentin Kindschi Date: Tue Aug 18 15:29:35 2026 +0200 Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection commit 941929abe5feaed672b9a52e330e547d333240c6 upstream. le_conn_complete_evt() clears HCI_LE_ADV before looking at the event status, on the premise stated in its comment that all controllers stop advertising when a connection is created. That premise only holds when a connection was actually created. On a non-zero status none was, and the controller is still advertising: after the host issues LE Create Connection Cancel the event arrives with Unknown Connection Identifier (0x02), and a connection timeout behaves the same way. Clearing the flag there leaves the host believing advertising is off while the controller has it on. It is also wrong for extended advertising, where several sets can be advertising at once. hci_cc_le_set_ext_adv_enable() is careful about this - on disabling one set it walks hdev->adv_instances and only clears HCI_LE_ADV once no instance is still enabled. The unconditional clear here discards that bookkeeping, so one set connecting drops the flag while the others keep advertising. The direction of the error matters. A flag left set is self-correcting: hci_disable_advertising_sync() sends LE Set Advertising Enable(0) and the command complete puts the state back. A flag left clear is not, because that same function returns early without sending anything while the flag is clear: - LE Set Advertising Parameters is then sent to a controller that is still advertising, and is correctly rejected with Command Disallowed (0x0c); - hci_enable_advertising_sync() returns at that point, before the LE Set Advertising Enable that would set HCI_LE_ADV again. On a controller without LE Extended Advertising that is reachable from here: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true, so the parameter write is retried for as long as advertising is configured: Bluetooth: hci0: Opcode 0x2006 failed: -16 Only clear the flag when a connection was established. Note this is not on its own sufficient to stop that retry loop - the redundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself and recreates the same mismatch, which patch 1 addresses. This patch fixes the event handler reporting a state the controller is not in. Verified on the affected device (BCM43455, legacy advertising only) with this patch and patch 1 applied. A 221 s btmon capture with an out-of-range peer at -90 dBm contains two outgoing connection attempts that the host cancelled, each producing exactly the event this patch changes: < LE Set Advertising Parameters 0x2006 Success < LE Set Advertising Enable 0x200a Success < LE Create Connection Cancel 0x200e Success > LE Connection Complete Unknown Connection Identifier (0x02), central Nothing follows either one; the next command is an unrelated scan restart 70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent, all Success; 10 LE Set Advertising Enable, all Success; no Command Disallowed of any opcode, and no 2 s cadence anywhere. Two central connections to other peers completed normally afterwards, with feature exchange and a connection parameter update, so advertising was still live across the cancelled attempts. The extended advertising case above is a code argument, not a measurement: this controller has no LE Extended Advertising, so that path is not exercised by the capture. Fixes: fbd96c151cdc ("Bluetooth: Fix clearing HCI_LE_ADV for LE connections") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 62ce8b33eb238cf18c15207332fbdc26d858f592 Author: Chengfeng Ye Date: Sun Aug 23 00:43:41 2026 +0800 Bluetooth: RFCOMM: serialize security confirmation handling commit 759c185d0bbdb131357408f50b8735e04ed3caff upstream. rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0 Fixes: 08c30aca9e698faddebd34f81e1196295f9dc063 ("Bluetooth: Remove RFCOMM session refcnt") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0f1e0dd999d6ec80135076c561ad3737baaf8726 Author: Gongwei Li Date: Fri Aug 21 10:45:55 2026 +0800 Bluetooth: hci_uart: Fix false success return in hci_uart_setup() commit a9355799343e10014f2acfd4b6844d2335ecafea upstream. When reading the local version information for vendor detection fails, the error is only printed and 0 is returned, which masks the setup failure from the HCI core. Return PTR_ERR(skb) instead. Fixes: fb2ce8d11f039 ("Bluetooth: hci_uart: Add support for vendor detection flag") Fixes: 82f5169bf3d3b ("Bluetooth: hci_uart: add serdev driver support library") Cc: stable@vger.kernel.org Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit cdef7c325f8f171942ef59de53febc7676763efd Author: Guangshuo Li Date: Sat Aug 8 13:15:32 2026 +0800 Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is negative commit dc6b7c771a963e20aedf4a21ffa22543b9837ba8 upstream. bcm_request_irq() calls pm_runtime_use_autosuspend(), but bcm_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: e88ab30d3669 ("Bluetooth: hci_bcm: Add suspend/resume runtime PM functions") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2d503bc2639cea0868f15bf6573700f03a8bf785 Author: Hui Su Date: Thu Aug 6 22:23:04 2026 +0800 cpufreq: schedutil: Fix rate limit overflow commit 3bff8f8e95fdc6ad19c8a1a8f87029094747e4bf upstream. rate_limit_us is an unsigned int, while NSEC_PER_USEC is defined as 1000L. On 32-bit systems, the multiplication is therefore performed using 32-bit unsigned arithmetic before the result is assigned to freq_update_delay_ns. For example, writing 4294968 to rate_limit_us wraps the delay from 4294968000 ns to 704 ns. This makes schedutil update far more often than configured. Add sugov_update_rate_limit_us() to widen rate_limit_us to s64 before converting it to nanoseconds. Use the helper when updating the tunable through sysfs and when starting the governor, so both paths perform the conversion without overflow. Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data") Signed-off-by: Hui Su Reviewed-by: Zhongqiu Han Cc: All applicable Link: https://patch.msgid.link/20260806142304.1761454-1-sh_def@163.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 35cd3b278448c79614f65ab6bbc9ed348d847df9 Author: Bryam Vargas Date: Fri Jul 31 17:54:55 2026 -0500 dm array: reject an array block whose value size is not the caller's commit 4538a287bdf5d0f9a379c678e5262b9f5783f547 upstream. array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only. Fixes: 6513c29f44f2 ("dm persistent data: add transactional array") Suggested-by: Ming-Hung Tsai Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 35ba81c93fe7392c973af9881640180490e76f34 Author: Ilya Krutskih Date: Sun Jul 19 13:01:03 2026 +0000 dm raid1: reserve space for NUL-terminator in build_constructor_string() commit 73c37fe54cd056d07461b142ab0b8b81e1ef6ad8 upstream. Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf(). Fixes: f5db4af466e2 ("dm raid1: add userspace log") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 54dd21ca945ecc07885012b9f3e8197f091cfba0 Author: liyouhong Date: Fri Jul 31 10:08:49 2026 +0800 dm-era: fix shadowed superblock leak on take-snap failure commit 39c5aa3bd8ec3912d2cd0b3fe092642b0d2b0713 upstream. metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap(). Fixes: eec40579d848 ("dm: add era target") Cc: stable@vger.kernel.org Signed-off-by: liyouhong Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 770715784b689749014ce193ef986b706fe8f51c Author: Jiangshan Yi Date: Sat Aug 15 20:21:49 2026 +0800 bnx2x: fix double free in bnx2x_init_firmware() error path commit d2796ffe38cb4155afe0eab23636295b096c27a5 upstream. bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op. Fixes: 94a78b79cb5f ("bnx2x: Separated FW from the source.") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260815122149.951215-1-yijiangshan@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7275e801cc9482bb35a606d3b0c23337f492e92a Author: Christoph Zwerschke Date: Sun Jul 5 11:28:57 2026 +0200 Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU commit 6f0624b4427e38c3bb63a951c536cf8adaee1238 upstream. Add the vendor/product ID (0x0b05, 0x1d70) to the usb_device_id table for the Realtek RTL8761CU-based ASUS USB-BT600 adapter. It binds via the generic Bluetooth class today, so BTUSB_REALTEK is never set and the rtl8761cu firmware is not loaded, leaving the controller non-functional. With the entry the driver loads rtl_bt/rtl8761cu_fw.bin (already shipped by linux-firmware) and the adapter works (tested: A2DP and ASHA). Similar to commit bc597f0cc44f ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV"). Device info from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 23 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=1d70 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Controller C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 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=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by: Christoph Zwerschke Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 5b3f64156784e38b93c7cf767e6afa06fe0c8989 Author: Christoph Zwerschke Date: Sun Jul 5 11:28:56 2026 +0200 Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU commit 980084de4d9b25193398d89a1c0430ba3501b683 upstream. Add the vendor/product ID (0x0b05, 0x1bef) to the usb_device_id table for the Realtek RTL8761CU-based ASUS USB-BT540 adapter. It binds via the generic Bluetooth class today, so BTUSB_REALTEK is never set and the rtl8761cu firmware is not loaded, leaving the controller non-functional. With the entry the driver loads rtl_bt/rtl8761cu_fw.bin (already shipped by linux-firmware) and the adapter works (tested: A2DP and ASHA). Similar to commit bc597f0cc44f ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV"). Device info from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 22 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=1bef Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Controller C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 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=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by: Christoph Zwerschke Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 07975b8daa3b0ab3cbc02cc48ea7bc48fadcec53 Author: Niklas Cassel Date: Thu Jul 2 12:59:58 2026 +0200 ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes commit 79cce911e623c0baa0fde307ce3a434e084b881a upstream. ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: size = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); if (size != len) /* len == sdp->sector_size */ goto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with "Parameter list length error" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM. Reviewed-by: Hannes Reinecke Fixes: ef2d7392c4ec ("libata: SCT Write Same / DSM Trim") Cc: stable@vger.kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 2094a3c3995f3b5c88573813a33da2afa170e1b4 Author: Matt Turner Date: Thu May 28 19:05:16 2026 -0400 alpha: marvel: Fix lock ordering in init_io7_irqs() commit 24d68db713d63dfe3660c56b50e887784844baea upstream. Move irq_set_chip_and_handler() and irq_set_status_flags() calls outside the io7->irq_lock raw spinlock. These functions take sparse_irq_lock, which is a mutex, and taking a sleeping lock while holding a raw spinlock is invalid. The raw spinlock only needs to protect the hardware CSR accesses. This fixes the following lockdep splat during boot: [ BUG: Invalid wait context ] swapper/0/0 is trying to lock: sparse_irq_lock{....}-{4:4}, at: irq_mark_irq other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: #0: &io7->irq_lock{....}-{2:2}, at: init_io7_irqs.constprop.0 Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260528230516.1839694-2-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit 4274aa5254cc9d5228e108e542fe657b42bb66d8 Author: Matt Turner Date: Thu May 28 19:05:15 2026 -0400 alpha: marvel: Fix irq_set_status_flags to use correct IRQ number commit 3a3ac1f6c6a67b3803f2643584310f78301e58a8 upstream. Pass base + i to irq_set_status_flags() to match the IRQ number used in irq_set_chip_and_handler(). Previously, IRQ_LEVEL was set on the wrong (low-numbered) IRQ descriptors rather than the IO7 IRQs at base + i. Cc: stable@vger.kernel.org Fixes: 08876fe8519c ("alpha: marvel: Convert irq_chip functions") Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260528230516.1839694-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit accb962e8068cde55acc39dd547acbe2b48923d5 Author: Krzysztof Wilczyński Date: Mon Jul 6 17:54:23 2026 +0000 alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write() commit 651fb94aaf245430590216d497fb8b02dd73d5f9 upstream. pci_legacy_write() in arch/alpha/kernel/pci-sysfs.c passes its arguments to outb(), outw() and outl() in the wrong order: outb(port, val); The Alpha I/O accessors in arch/alpha/include/asm/io.h take the value first and the port second: extern void outb(u8 b, unsigned long port); So the port number is written as data to the I/O address taken from the user-supplied value, and the intended write to the requested port never happens. The arguments have been reversed since the file was added, and the function returns the access size regardless, so the caller sees success while the requested port is left untouched. Fixes: 10a0ef39fbd1 ("PCI/alpha: pci sysfs resources") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Magnus Lindholm Reviewed-by: Magnus Lindholm Acked-by: Magnus Lindholm Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260706175423.98305-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6a5426f56de98faf7886702f8720828bf346a48f Author: Ivaylo Dimitrov Date: Fri Jul 24 16:05:22 2026 +0300 hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device commit e81250ec6b69248b00d38c523dc6a13efaf38aab upstream. The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities. Cc: stable@vger.kernel.org Fixes: f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") Reported-by: Merlijn Wajer Closes: https://lore.kernel.org/linux-omap/4ed95c71-2066-6b4c-ad1b-53ef02d79d53@wizzup.org/ Signed-off-by: Ivaylo Dimitrov Link: https://patch.msgid.link/20260724130522.706480-1-ivo.g.dimitrov.75@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 7f3a479764fbda45289ddd06da5ae4f684cfec02 Author: Tien Sung Ang Date: Mon Jun 29 23:57:19 2026 -0700 fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration commit c14a8b15c87b49efc3ef898cec8ac7c30336a080 upstream. Fix incorrect stratix10_svc_done() usage during FPGA reconfiguration. Do not call stratix10_svc_done() at the end of write_init() on success, so the SVC session remains active through write() and write_complete(). Call stratix10_svc_done() on failure in write_init() and write() so the shared SVC mailbox is released when reconfiguration aborts, allowing coexistence with other SVC clients such as soc64-hwmon. Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver") Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: Tien Sung Ang Signed-off-by: Tze Yee Ng Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/8768ce3260489c9febdfce08e27d03f5f5ed9c33.1782801986.git.tze.yee.ng@altera.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit effd589568b2c4399894a23000286210c60af6d7 Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: fix off-by-one when saving/restoring non-PCI config space commit 9393f1d656a79693e0c123ff7bc7c5c0f708046d upstream. nv_suspend() and nv_resume() walk the non-PCI configuration space with for (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as u32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: np->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the "?" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes. Fixes: 1a1ca86158ee ("[netdrvr] forcedeth: save/restore device configuration space") Cc: stable@vger.kernel.org Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367885.3748309.10595890901761762683@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b149f77d04082a9da75944cdc488becb0e35258f Author: Myeonghun Pak Date: Wed Jul 1 20:12:24 2026 +0900 fbdev: uvesafb: unregister connector callback on init failure commit de8db23aa7c337e606fca9faf48b3ba72968597a upstream. uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d7904f6fcd121101e154712297fcaa888d591cbb Author: Florian Fuchs Date: Mon Jul 13 12:16:38 2026 +0200 fbdev: pvr2fb: correct user pointer annotation and sentinel initializer commit 5dc2e70dd74b1f03e2e13bfb6922111d9e0adf90 upstream. Add __user annotation to buf, as it is passed as a user pointer in pin_user_pages_fast(). Use an empty initializer for the sentinel board-table entry to avoid initializing a function pointer with an integer literal. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607131247.fpQ6eTc7-lkp@intel.com/ Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ef20d4e17d7fb0d83144caa9667e6f3198288993 Author: Runyu Xiao Date: Tue Aug 18 21:53:18 2026 +0800 fbdev: omapfb: panel-dsi-cm: initialize lock before registering display commit f8e43fe0f22b7137ce456e6fe3581d3098174f74 upstream. dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit b7141dd79f2992ddabc84e5c9fa08e843e864d96 Author: Yemu Lu Date: Mon May 25 16:56:49 2026 +0800 fat: restore original value when fat_ent_write failed commit 64d9183203eebe33de6188b70a8c1e91f52885db upstream. fat_ent_write() may have committed the new link to the primary FAT but then failed on the mirror copy, leaving the chain pointing to new_dclus even though the caller will free it. Restore the original value to keep the chain consistent. Link: https://lore.kernel.org/20260525085649.781643-1-n05ec@lzu.edu.cn Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yemu Lu Signed-off-by: Ren Wei Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Acked-by: OGAWA Hirofumi Cc: Christian Brauner Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 81bc593fc0dac395e334f614ffb1b98a6bc44370 Author: Yichong Chen Date: Thu Jul 2 13:29:58 2026 +0800 ecryptfs: show filename encryption options commit 496ec2d0852a02d2e631771b5c439130b9c7dce7 upstream. ecryptfs_show_options() prints most user-visible mount options but omits the filename encryption cipher and key size. Print ecryptfs_fn_cipher and ecryptfs_fn_key_bytes when filename encryption is enabled so that the displayed mount options reflect the active filename encryption settings. Fixes: 87c94c4df014 ("eCryptfs: Filename Encryption: mount option") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 177e0c32fec3602bb3b64139bb8bb610cd6722c7 Author: Yichong Chen Date: Wed Jul 1 13:34:06 2026 +0800 ecryptfs: release message context on send failure commit 219644a3ad5518217b2d62cad6d2c36a2308c949 upstream. ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer. Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit df5f375a6151ef71f636da044bcef90c26697255 Author: Yichong Chen Date: Wed Jul 15 13:20:06 2026 +0800 ecryptfs: reject too-small tag 70 packets commit e97bbe1b2bd82ec2ae37ad2e4965b4d3e78bbf7f upstream. ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data. Fixes: 9c79f34f7ee7 ("eCryptfs: Filename Encryption: Tag 70 packets") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 2cd21340163494d312836c77c9fbfe2530b3d075 Author: HanQuan Date: Tue Jul 14 00:57:03 2026 +0000 ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet commit 5babe9c177c364521e3e682b949c5a8c47f4a441 upstream. parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: HanQuan [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future] Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit e7573b0e3058c6bbdfe81673f22c09900fde9e65 Author: Yichong Chen Date: Wed Jul 15 13:20:04 2026 +0800 ecryptfs: pass packet set buffer size to parser commit 2602b79c5b3e2f6fce12e38a670f8e3fda4e46a2 upstream. ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 64d8998e36cfd2bb7114f3af0aa51c5a559a39b3 Author: Yichong Chen Date: Sun Jun 28 11:37:25 2026 +0800 ecryptfs: hold msg ctx list lock when cleaning daemon queue commit 779972513c2fa8c7938e54976f686091dafff22f upstream. ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users. Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 46bdc3e69589d917cefb13ecf08d37d5e80a9283 Author: Yichong Chen Date: Wed Jul 15 13:20:05 2026 +0800 ecryptfs: fix tag 11 packet exact-fit size check commit 8b2ec0f56f55477f547d332526c9ae2a8fabc0a5 upstream. parse_tag_11_packet() rejects a packet when the already-consumed tag and length bytes plus the packet body exceed the caller supplied maximum packet size. The check currently adds one extra byte, even though *packet_size already includes the tag byte before the length is parsed. Remove the extra byte so a tag 11 packet that exactly fits the available buffer is accepted while oversized packets are still rejected. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit fbb97d86597eaba5a3b15f2eb8bcecd47fd7de2c Author: Pengpeng Hou Date: Mon Jul 20 19:56:24 2026 +0800 eCryptfs: bound the packet-length peek to the user buffer commit 95540462e630edbc8504e9537d16453d6942d143 upstream. ecryptfs_miscdev_write() accepts the minimum one-byte packet-length encoding, but always copies the maximum two-byte encoding from userspace before parsing it. A six-byte message therefore reads one byte beyond the submitted user buffer. Zero-initialize the peek buffer and copy only the packet-length bytes present. The existing exact packet-size check still rejects truncated two-byte encodings after the parser determines their encoded length. Fixes: 8bf2debd5f7b ("eCryptfs: introduce device handle for userspace daemon communications") Cc: Signed-off-by: Pengpeng Hou Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit cb38b1f149b7143355b37e86c841acf0076e5c2a Author: Jiangshan Yi Date: Tue Jul 28 21:14:42 2026 +0800 HID: mcp2221: validate report size in mcp2221_raw_event() commit 2c9a6998c19503626c57a2267bf279e204113079 upstream. mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 416194933af63bd58d03b7605b1ebc1711186838 Author: Haoxiang Li Date: Tue Jul 7 15:15:45 2026 +0800 HID: sensor: custom: Fix field sysfs group cleanup on failure commit 3789d0802ddb4b3be04062caf4bfadd23496e9a7 upstream. hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array. Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cebb20b9a29cfc90bf56e54337333084f85a69dd Author: Xu Rao Date: Fri Jul 31 16:49:26 2026 +0800 HID: roccat: free buffered reports when destroying device commit bbff0ccbff360a5498075525005f6a913239a3d7 upstream. roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device. Fixes: 206f5f2fcb5f ("HID: roccat: propagate special events of roccat hardware to userspace") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1a02056c2bf7ef9b5fd05ee6913aeeadb703c443 Author: Ibrahim Hashimov Date: Wed Jul 15 13:53:01 2026 +0200 HID: picolcd: clamp eeprom debugfs read to bytes actually received commit e9c667395ac1f8024f623250b32bae4c7af9caa0 upstream. picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: ret = resp->raw_data[2]; if (ret > s) ret = s; if (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs "eeprom" file: BUG: KASAN: slab-out-of-bounds in _copy_to_user Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies. Fixes: 9bbf2b98ba11 ("HID: add experimental access to PicoLCD device's EEPROM and FLASH") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9cac21f8eb82675ed19fb955b8bbb9dd14cc3d58 Author: Jérémy Jean Date: Tue Aug 11 22:01:27 2026 +0000 audit: avoid dropping live tree ref on fsnotify rule autoremove commit 783f0f0974c156aca630f4ffff248671082a098d upstream. audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. Cc: stable@kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina [PM: dropped unnecessary comment for line length reasons] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 848b80ca6b410f350d08b8ac19a00ef88223f2ea Author: Michael Bommarito Date: Tue Jul 7 14:05:57 2026 -0400 ceph: bound xattr value length in __build_xattrs() commit 68d541754d6cd3bb98d1fd8314f57e5eb533557d upstream. __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored. Cc: stable@vger.kernel.org Fixes: 355da1eb7a1f ("ceph: inode operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 091137821e1fc88f37e15201abf055c9494ddc61 Author: Xiubo Li Date: Tue Jul 14 16:13:43 2026 +0800 ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock commit 7af4c4f01305b0935adf6d4301b1ec407025485d upstream. list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again. Cc: stable@vger.kernel.org Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit ee59040d6ed1a5f8d10d27174b8f32c90ca8e89a Author: Jérémy Jean Date: Sat Aug 15 21:46:37 2026 +0000 libceph: reject buckets with mismatched CRUSH ids commit 3cde4a8302301679937474a5f7a851394cc1bd11 upstream. crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior. Cc: stable@vger.kernel.org Fixes: 66a0e2d579db ("crush: remove mutable part of CRUSH map") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 42d7954b0a1907d4ef122aef94561952a033cdc3 Author: Chuck Lever Date: Thu Jul 9 13:40:24 2026 -0400 NFSD: Prevent lock owner use-after-free during client teardown commit 5e2fa29d223a9a1e6a948e40b109d09081d1decd upstream. __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock. Reported-by: Wolfgang Walter Closes: https://lore.kernel.org/linux-nfs/6eccafaaaa60651ef091257c3439c46b@stwm.de/ Fixes: 68ef3bc31664 ("nfsd: remove blocked locks on client teardown") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-1-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5f00e0ab4de45d4f9e4bd0883cf2517acf63fc0d Author: Jeff Layton Date: Fri Jul 10 10:00:10 2026 -0400 nfsd: revoke copy-notify stateids before dropping their reference commit 3b0c3595db99bb4bebd7c8aa8a36f3c50e411bb7 upstream. Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op). Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-6-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7a1cee51ddbd53b52f6ebfb99ea95f36fdfb9591 Author: Jeff Layton Date: Thu Jun 11 16:00:57 2026 -0400 nfsd: reject reclaim LOCK after RECLAIM_COMPLETE commit 2327ba1d9546727a35b17888777e991f68a9b305 upstream. nfsd4_lock() only checks the namespace-wide grace flag when deciding whether to accept a reclaim LOCK. It does not check the per-client NFSD4_CLIENT_RECLAIM_COMPLETE bit. An NFSv4.1+ client that has already sent RECLAIM_COMPLETE can submit lk_reclaim=1 while grace is still active (e.g. lockd holds the grace list open), and the server accepts it instead of returning NFS4ERR_NO_GRACE as required by RFC 8881 section 18.51.3. The OPEN path already enforces both tiers: the grace check plus the per-client RECLAIM_COMPLETE check in nfs4_check_open_reclaim(). Add the equivalent per-client check to the LOCK path. Fixes: 3b3e7b72239a ("nfsd: reject reclaim request when client has already sent RECLAIM_COMPLETE") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: Correct the RFC citations in the commit message ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-14-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cdc3299f7072777b09c9582a3b8b65bb163ddcf3 Author: Robbie Ko Date: Tue Jun 16 13:39:58 2026 +0800 nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE commit 26709c8ffe73772eb69e68d553ac71d91228dccc upstream. The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for "set to the current server time", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means "set both atime and mtime to now". Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Robbie Ko [ cel: various tweaks, addenda, and clean-ups ] Link: https://patch.msgid.link/20260616054027.2360930-1-robbieko@synology.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 863b6e995665472f2af5be2436a874ab6a9e5ac6 Author: Jeff Layton Date: Fri Jul 10 10:00:08 2026 -0400 nfsd: initialize copy-notify stateid before publishing it commit 129643893b79f8a3c6b72045f933fbab5ee424ca upstream. nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry. Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-4-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 356decf074b82bac5564568203c12426dcea3470 Author: Jeff Layton Date: Wed May 27 14:30:41 2026 -0400 nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo commit 8b989aaec85e1293a871d602590c951fe44b8647 upstream. nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes. Fixes: efcae97fa425 ("NFSD: da_addr_body field missing in some GETDEVICEINFO replies") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260527-pnfs-fixes-v1-1-784f39dc1eca@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3a7fd224df0fbb42167eb1b77be45d72fe0b1098 Author: Jeff Layton Date: Thu May 28 10:38:15 2026 -0400 nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget commit f9868174af49d207fbaf0c5e055d088a983684af upstream. The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use "8 + len" but xdr_encode_opaque() actually writes "4 + xdr_align_size(len)" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants. Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260528-pnfs-fixes-v1-1-8a1255ae2f16@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8dd34844e25f86720bda7494e894928ff0bcfb4e Author: Jeff Layton Date: Thu Jun 11 16:00:52 2026 -0400 nfsd: fix version mismatch loops in nfsd_acl_init_request() commit 9bc761051dcd9a4a8b59e64b2b185172d13c716d upstream. The loops that compute the supported version range for PROG_MISMATCH test nfsd_support_acl_version(rqstp->rq_vers) instead of nfsd_support_acl_version(i), so every iteration fails and the function returns rpc_prog_unavail instead of rpc_prog_mismatch. Replace rqstp->rq_vers with the loop variable i, matching the pattern used by the sibling nfsd_init_request() function. Fixes: e333f3bbefe3 ("nfsd: Allow containers to set supported nfs versions") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-9-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 63e18fc65587fd3f7b4c6d70e96d32fc41d82ba3 Author: Chris Mason Date: Fri Jul 10 10:00:05 2026 -0400 nfsd: fix cpntf publish race in nfs4_init_cp_state commit be3a5c1d857b0dcbc11796cea603ef25834f75b2 upstream. nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics. Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260710-nfsd-testing-v3-1-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 88daaed26e17e1c7e851859b5bbb4f0e1ab6d0e9 Author: Jeff Layton Date: Fri Jul 10 10:00:09 2026 -0400 nfsd: check client ownership when cancelling a copy-notify stateid commit 6bdbfab96e0cf25e5f57dac5c09dc1749751a4bf upstream. On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry. Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-5-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ffdc844e673d2bcb2af8c8c3eef8cdea59d0bf32 Author: Jeff Layton Date: Wed May 27 10:53:37 2026 -0400 nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref commit c59738a00aa51b16adc1b5ceb7c80877168efb4d upstream. When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point. Fixes: b9e8638e3d9e ("NFSD: allow inter server COPY to have a STALE source server fh") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260527-putfh_foreign_fh_null_deref_consumers-v1-1-1b8a5aa28c59@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1a44fa8f9d7eae7875cc9fb490a59879faea471e Author: Jeff Layton Date: Thu Jun 11 16:00:49 2026 -0400 nfsd: add filehandle match check to nfsd4_delegreturn() commit 04cce9d79f2b1a114f7128e08bf60a473e10f1ec upstream. nfsd4_delegreturn() is the only stateful NFSv4 operation that does not call nfs4_check_fh() to verify the delegation's file matches cstate->current_fh. A client can DELEGRETURN with a mismatched filehandle, destroying the correct delegation but waking the wrong inode's waiters. Add the missing nfs4_check_fh() call after the generation check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-6-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3eec9d791968c177a4a8cda9af5c04f79dae09cb Author: Jeff Layton Date: Thu Jun 11 16:00:54 2026 -0400 nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() commit 4e475be769aa9f7a2c1ce55a2b8592cfccacddcc upstream. The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify(). Fixes: cc265089ce1b ("nfsd: Disable NFSv2 timestamp workaround for NFSv3+") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-11-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 36011308b3f01ce7dc9954f3cefcbb5291af9f95 Author: Jeff Layton Date: Sat May 30 09:19:25 2026 -0400 nfsd: validate symlink target length in NFSv4 CREATE commit 041f57056e5fb9c80adc088269322d2c61074406 upstream. nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-9-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 435e4246c7dfff2fbd76dfdbf91975d5d9f788c9 Author: Chuck Lever Date: Fri May 22 17:45:58 2026 -0400 nfsd: sample writeback error cursor before async COPY loop commit 20a67a7d18221af736f124770c2c5e859b479046 upstream. _nfsd_copy_file_range() samples dst->f_wb_err into "since" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling "since", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range(). Closes: https://sashiko.dev/#/patchset/20260522194441.436065-1-cel@kernel.org?part=1 Fixes: 555dbf1a9aac ("nfsd: Replace use of rwsem with errseq_t") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260522214558.460859-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4c4d476d46ac37055177256917036ea1d4a9a3c5 Author: Jeff Layton Date: Fri Jul 10 10:00:11 2026 -0400 nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types commit 45b06a75086f331f52cbb81223a59421d43f8809 upstream. nfsd4_decode_nl4_server() handled only NL4_NETADDR and returned nfserr_bad_xdr for NL4_NAME and NL4_URL. Those forms are well-formed XDR, so BADXDR is misleading -- the request is unsupported, not malformed. Decode and discard the utf8str_cis for NL4_NAME and NL4_URL to keep the stream consistent, and return nfserr_notsupp. nfsd4_proc_compound() honors a decode-time op->status, so the op fails without executing. Fixes: 84e1b21d5ec4 ("NFSD add ca_source_server<> to COPY") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-7-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cc5f7cef0659a27c13dd33edd8e2f79257b095c6 Author: Chuck Lever Date: Fri May 22 16:37:23 2026 -0400 nfsd: Reset write verifier when async COPY writeback fails commit f5cb2276954cb80987a93ef9f9dfbfdbfc0f10b9 upstream. Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure. Fixes: eac0b17a77fb ("NFSD add vfs_fsync after async copy is done") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260522203723.446841-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ae251937c6f0237e5b555a5e4ba4595b8206e865 Author: Mike Snitzer Date: Fri Jun 12 15:14:10 2026 -0400 NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check commit aa0cf48a448c5a9fe1a1e880899ecd589ce39e6e upstream. The header for commit e75b23f9e323 ("nfsd: check d_can_lookup in fh_verify of directories") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer. Fixes: e75b23f9e323 ("nfsd: check d_can_lookup in fh_verify of directories") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Link: https://patch.msgid.link/20260612191410.50177-1-snitzer@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2b59029b8f24a99b5d844af2da3950d39d36eeea Author: Michael Bommarito Date: Sun May 24 09:06:54 2026 -0400 NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock commit 036c1b182f4da65363e79ec0ac276edc6b7296e5 upstream. nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap. Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260524130654.1924556-1-michael.bommarito@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 26425872d4ee092694c041014fa582f43c68bf4d Author: Chuck Lever Date: Thu Jul 16 20:12:28 2026 -0400 NFSD: Fix off-by-one in DRC bucket pruning limit commit d0728723c80dcb3432effd67c7e919b596004b1d upstream. nfsd_prune_bucket_locked() evicts an entry before checking the freed count against @max. The check uses "++freed > max", which does not break until freed exceeds max, resulting in max + 1 evictions. Use ">=" so the limit stated in the function comment is honored. Fixes: a9507f6af145 ("NFSD: Replace nfsd_prune_bucket()") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Link: https://patch.msgid.link/20260717001232.438792-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b8a30f094c28649618f11d89c2107e2dfa73869a Author: Chuck Lever Date: Sun Jul 12 11:09:11 2026 -0400 NFSD: Encode only the status in NFS-ACL v2 GETACL error replies commit ed4edddad19babf76b56882ad9600f5646b167a0 upstream. The NFSv2 ACL GETACL reply is a union that carries file attributes and ACL data only when the status is NFS_OK. All error cases are void results. However, currently the NFSv2 ACL GETACL result encoder decides whether to append the "OK" body by testing only whether the file handle resolved to a positive dentry, not the actual reply status. A GETACL request that resolves its file handle but then fails for another reason (an unsupported mask value, a getattr failure, or an ACL retrieval error) therefore appends file attributes and ACL data after the error status on the wire. Worse, when the mask is rejected, fh_getattr() hasn't been called at all, so those attributes are serialized from a zero-filled kstat and are junk. The logic before the xdr_stream conversion used the reply status. Revert to that approach (but keep the xdr_stream conversion in place). Fixes: f8cba47344f7 ("NFSD: Update the NFSv2 GETACL result encoder to use struct xdr_stream") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260712150911.48461-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ab7405bd86331cc2dbc8201699d4adc33bea75e7 Author: Ibrahim Hashimov Date: Fri Jul 24 09:43:27 2026 +0200 ubifs: fix out-of-bounds read in signature length check commit 95d27c1708bb6e8823c8e7c623f9abc2a91bf4bf upstream. ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: if (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most snod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in. Fixes: 817aa094842d ("ubifs: support offline signed images") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Richard Weinberger Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit fd0c7bbda81c0e0c1cb7b68d267b87371584f560 Author: Abdurrahman Hussain Date: Wed Aug 5 13:31:00 2026 -0700 of: fix out-of-bounds read in of_alias_scan() stem parser commit 5bb01c657ff9fc807c2c592ca18af34c4fc3bc6f upstream. The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first. Fixes: 611cad720148 ("dt: add of_alias_scan and of_alias_get_id") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260805-nh-of-alias-overlay-v6-1-74f21d440819@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 39005fd1ce654ffdecacddc406b9a038efe606e6 Author: Ryusuke Konishi Date: Fri Jul 17 13:39:43 2026 +0900 nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation commit 45662dedb8f272ef7f16e69f13424c4bd0399240 upstream. Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/r/08A3603A-ADB6-484C-9015-9AC1340E6FB8@gmail.com Fixes: 36a580eb489f ("nilfs2: direct block mapping") Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit f7ae26c100a6c26c2a166d2c41e73188067b36bd Author: Junrui Luo Date: Tue Jul 14 15:24:37 2026 +0800 media: vicodec: fix out-of-bounds write in FWHT encoder commit cf4500ebf6fb57bf4ab83c3dd349a40257dbe2a9 upstream. vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback. Fixes: 16ecf6dff97c ("media: vicodec: Add support for 4 planes formats") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f2499b720ea9b874d58770885c6c2e8445a8c3ef Author: Weigang He Date: Thu Jun 11 23:22:48 2026 +1000 media: cec: stm32: prevent out-of-bounds write on RX overflow commit fb9dda38d4b9e90db07ed9a0ee2d35bf85494035 upstream. stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL. Fixes: d69ae57453c8 ("[media] cec: add STM32 cec driver") Cc: stable@vger.kernel.org Signed-off-by: Weigang He Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 04ae68af4107600120c3c41c94268f43bc350d48 Author: Vincent Mailhol Date: Thu Jul 23 21:40:31 2026 +0200 lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() commit cec0d03fe785380540dc1b4d07c80f67ae2ffc78 upstream. Patch series "lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read. Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-0-9ea94e32a358@kernel.org Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-1-9ea94e32a358@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Vincent Mailhol Cc: Kees Cook Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1c0463f0f028801a933f090cd2695f132635b374 Author: Xingrui Li Date: Wed Aug 5 18:57:53 2026 +0000 HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature commit c92693f3ed099401d0383ef35ca1fe1e6ba033de upstream. sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer. Fixes: 5459ada2b3cd69 ("HID: sensor-hub: Fix packing of result buffer for feature report") Cc: stable@kernel.org Assisted-by: OpenAI:GPT-5.5-Cyber Signed-off-by: Xingrui Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 447b3c893987a0106a65f04b62ec3271892e9d98 Author: Daisuke Matsuda Date: Thu Jul 23 08:19:12 2026 +0000 fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write commit 9da70a43b5fea60d758137f7f0ccfe19356cb5bb upstream. The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer. Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver") Cc: stable@vger.kernel.org Signed-off-by: Daisuke Matsuda Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260723081912.74082-1-dskmtsd@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit fbe3db4b650c284df8eb4cb68eebcf270cf861b5 Author: Neill Kapron Date: Fri Jul 24 20:41:16 2026 +0000 usb: gadget: f_fs: Prevent deadlock during ep0 read loop commit 569dd7e5dcffe1e1c6b26ca2cd3be57eb433e082 upstream. Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo "" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling. Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260724204117.4036015-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman commit ddb1b0d5d858584ed0d3a5aaa042ee693998c7e2 Author: Jeffin Philip Date: Thu Aug 13 23:13:11 2026 +0530 usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() commit bdab5605259ba5d6ff927c1a85cc83eb3ecfdacc upstream. In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind(). Reported-by: syzbot+de553c19cb054f174a35@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de553c19cb054f174a35 Fixes: 0f9df9393855 ("usb: gadget: uvc: fix error path in uvc_function_bind()") Fixes: 6d11ed76c45d ("usb: gadget: f_uvc: convert f_uvc to new function interface") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260813174311.130823-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit abad5daa41cf5d0a0a9cba0397d3a0e7f11e0277 Author: Yun Zhou Date: Fri Jul 31 16:11:51 2026 +0800 usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() commit 9dbf74f4022f80f7669d2b3c22c5deb46c1b5674 upstream. usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead. Reported-by: syzbot+c9f9d646b08f3b6032fe@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c9f9d646b08f3b6032fe Fixes: 4bb8548df632 ("usb: gadget: f_tcm: add configfs support") Cc: stable@vger.kernel.org Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260731081151.285599-1-yun.zhou@windriver.com Signed-off-by: Greg Kroah-Hartman commit 925bb3d9dfcb34ac9fefe49fdb0d9572f33c578b Author: Myeonghun Pak Date: Tue Aug 4 23:05:10 2026 +0900 usb: gadget: snps_udc_plat: clean up PHY on probe deferral commit 886338ea7d40e4ba5123c58204d7f7e53d825825 upstream. When the referenced extcon device has not registered yet, extcon_get_edev_by_phandle() returns -EPROBE_DEFER after the driver has initialized and powered on the PHY. The direct return bypasses the common cleanup path and leaves both operations unbalanced. Store the lookup error first and route deferred probing through exit_phy, while retaining the existing behavior of suppressing the error message for deferral. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1b9f35adb0ff ("usb: gadget: udc: Add Synopsys UDC Platform driver") Cc: stable@vger.kernel.org Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260804140510.37639-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit cee5c07b8b6f3c2cb515f630c14e0a764e0fa8ef Author: Johan Hovold Date: Fri Jul 17 17:49:57 2026 +0200 USB: phy: fsl-usb: fix missing static keywords commit 80574c40598aedbc1751c528e414d7e224bc6313 upstream. A recent change enabling compile testing of a Freescale dual-role controller indirectly enabled a USB PHY driver to be built. That driver in turn is missing a bunch of static keywords which results in warnings like: drivers/usb/phy/phy-fsl-usb.c:105:5: error: no previous prototype for 'write_ulpi' [-Werror=missing-prototypes] 105 | int write_ulpi(u8 addr, u8 data) | ^~~~~~~~~~ which consequently breaks -Werror builds. Add the missing static keywords. Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver") Cc: stable@vger.kernel.org # 3.0 Reported-by: Mark Brown Link: https://lore.kernel.org/r/4f9f5ff9-8eaa-4bd5-9331-37119f78e13f@sirena.org.uk Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260717154957.1853976-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4b1001e24d230d823309ac8152fd0562bea3e5df Author: Hao-Qun Huang Date: Sat Jul 4 16:16:13 2026 +0800 staging: greybus: hid: fix SET_REPORT return value commit 6d45195a9626d8aaaaed212c55638829a9c624a3 upstream. __gb_hid_output_raw_report() stores the result of gb_hid_set_report() in ret and even adjusts it to account for the report ID byte, but then always returns 0. This hides Greybus transport errors from HID_REQ_SET_REPORT callers, and makes hidraw report zero bytes written to user space on success, although hid_hw_raw_request() is expected to return the number of bytes transferred or a negative errno. The sibling GET_REPORT path, __gb_hid_get_raw_report(), already follows this convention. Return ret like the other HID transport drivers do. Fixes: 96eab779e198 ("greybus: hid: add HID class driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260704081613.434445-1-alvinhuang0603@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8b998c171ed875e402e1fd1c5cd619e4ca05e9c1 Author: Hans Verkuil Date: Fri Jul 17 15:42:45 2026 +0200 Revert "media: v4l2-dev: fix error handling in __video_register_device()" commit e7600f5cee5de14065f950807931d6e6d40fb2d7 upstream. This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust. Reviewed-by: Laurent Pinchart Fixes: 2a934fdb01db ("media: v4l2-dev: fix error handling in __video_register_device()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-media/20260520090624.1071139-1-lgs201920130244@gmail.com/ Link: https://lore.kernel.org/all/2026042058-charm-storable-4ad8@gregkh/ Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 00c5ed913b0dc563fbeb8a97ea8916c03bbbbf6a Author: James Kim Date: Fri Jul 24 08:52:20 2026 +0900 rapidio: mport_cdev: fix use-after-free in dma_req_free() commit 5cbef379a94b161726c5f504598bf4791d45cedc upstream. dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface. Link: https://lore.kernel.org/20260723235220.588424-1-james010kim@gmail.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: James Kim Reviewed-by: Dan Carpenter Cc: Alexandre Bounine Cc: Greg Kroah-Hartman Cc: Matt Porter Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ed639b53fb6052928b2dc68d74f5b02c4e080114 Author: Bartosz Golaszewski Date: Mon Jul 6 14:44:13 2026 +0200 powerpc/powermac: fix OF node refcount commit bd0abfe6b013aeb2a1aebc5fbc7ceeb50355bda3 upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 81e5d8646ff6 ("i2c/powermac: Register i2c devices from device-tree") Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-1-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit c1a4fb7aa290f158d50654d640292e49d9055fd1 Author: Hui Su Date: Mon Aug 17 20:06:44 2026 +0800 tracing: Fix crash passing ERR_PTR to kthread_stop() commit 649bc7df3e5d7be6f7996a95084037dbf3cad1e5 upstream. event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad ("ring-buffer: Fix crash passing ERR_PTR to kthread_stop()"). Cc: stable@vger.kernel.org Fixes: e6187007d6c3 ("tracing/events: add startup tests for events") Link: https://patch.msgid.link/20260817120642.668375-3-sh_def@163.com Signed-off-by: Hui Su Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit dcb437298bdaf9c2708142f1aaf4b640b8ec80f9 Author: Kiryl Shutsemau (Meta) Date: Mon Jul 13 14:37:52 2026 +0100 x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg() commit 1fe104b048d77d6cb25bd938e6a67450fb50e61d upstream. KVM's instruction emulator has a small helper, assign_register(), that writes a value into a register following the x86 rules for writes to general-purpose registers: an 8- or 16-bit write leaves the rest of the register untouched, a 32-bit write zero-extends the result to 64 bits, and a 64-bit write replaces the whole register. The TDX guest #VE handler needs the same logic for port I/O emulation to get 32-bit zero-extension right. Rather than add a third copy of the same switch, move the helper verbatim to , rename it to insn_assign_reg(), and route KVM's callers through it. Add to the header's includes so it builds standalone in callers that have not pulled it in transitively. No functional change. Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Dave Hansen Acked-by: Sean Christopherson Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260713133753.223947-3-kirill@shutemov.name Signed-off-by: Greg Kroah-Hartman commit ce4b5755ca301710ab151a081c9bd003a698f1b9 Author: Joy H.J. Lee Date: Thu Jul 2 05:06:35 2026 +0900 tools/compiler: match glibc 2.42 definition of __attribute_const__ commit 8700a4761beb219873956666cf91776a2c61e698 upstream. glibc 2.42 added __attribute_const__ to sys/cdefs.h: # define __attribute_const__ __attribute__ ((__const__)) GCC 15 warns when a macro is redefined to a different replacement list (-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids, objtool) pass -Werror, this conflict becomes fatal. The warning is suppressed on standard native builds because GCC treats /usr/include as a system header path (-isystem), and macro-redefinition warnings from system headers are silently suppressed by GCC. It fires when glibc headers are on a regular include path (-I) instead, which is the case in cross-compilation setups such as NixOS, where the sysroot's glibc is passed explicitly via -I rather than -isystem. Per (C11 6.10.3), identical replacement lists are accepted silently. Match the glibc definition exactly, including the space before "((", so the redefinition is accepted without warning regardless of whether glibc headers are treated as system or non-system includes. Link: https://lore.kernel.org/20260701200635.3992767-1-rkr0k0r@gmail.com Signed-off-by: Joy H.J. Lee Cc: Nathan Chancellor Cc: David Laight Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ebf762a393630d1582645be3f0fc22a674eb9122 Author: Guopeng Zhang Date: Fri Jul 24 10:18:05 2026 +0800 mm: memcg: stop reclaim when a limit update is superseded commit 9477820c63cbf4d97114238f3d1ff10dfd6bee3f upstream. kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to "max" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above. Link: https://lore.kernel.org/20260724021805.1234583-1-guopeng.zhang@linux.dev Fixes: 8c8c383c04f6 ("mm: memcontrol: try harder to set a new memory.high") Fixes: b6e6edcfa405 ("mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage") Signed-off-by: Guopeng Zhang Acked-by: Tao Cui Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4f50593c9cbc883d8c9b50148a3e8a8b1fd35f57 Author: Breno Leitao Date: Mon Aug 10 02:57:36 2026 -0700 mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() commit 25f52e81216884a7444bf07a606691feb09a94e3 upstream. I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] Link: https://lore.kernel.org/20260810-rcu_task_shrink_lruvec-v1-1-4d9f7d5251cb@debian.org Link: https://lore.kernel.org/all/amdWVTs0WKOxguxP@gmail.com/ [1] Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 592c71db3e77ed2281980bce99a75a28d513b312 Author: Jordan R Abrahams-Whitehead Date: Fri Jul 31 20:15:19 2026 +0000 include/linux/list.h: mark list_add and __list_add as __always_inline commit 2780860eddecba9ffe210bb9436eee3cf22bfcdd upstream. This commit resolves an issue where modpost section verification fails due to section mismatches between list_add and its callers. At present, list_add (and its internal __list_add) are called from both .text and .init code sections. Since inlining can vary per call site, list_add can be 4 different states: list_add in text with arguments to non-.init.data values list_add in init with arguments to static .init.data values list_add in init with arguments to non-.init.data values list_add in text with arguments to static .init.data values It is last instance that ends up causing the section mismatch caused by constant propagation of the address of static libs inside the `dir_add` as seen below (with the dir_list being defined statically in initramfs.c, resting in .init.data). WARNING: modpost: vmlinux.o: section mismatch in reference: __list_add (section: .text.unlikely.) -> dir_list (section: .init.data) Because of these section matching requirements, semantically, __list_add and list_add MUST be inlined. This will then ensure callers inside .init will receive a list_add that exists and refers to only .init data, and list_add code in .text sections will only refer to non-init data. This issue manifests predominently in AutoFDO with clang, which is very hesitant to inline cold functions such as list_add even when marked `inline`. Marking them as `__always_inline` therefore matches the existing semantic constraints imposed by modpost's section mismatch checks. Link: https://lore.kernel.org/20260731-always-inline-list-add-v1-1-d29f54ce5477@google.com Link: https://lore.kernel.org/all/CANn89iJVQe=wedLheJmjZjOTJsWHijT0jZs=iRxKssJZbjAxHw@mail.gmail.com/ Signed-off-by: Jordan R Abrahams-Whitehead Suggested-by: Nathan Chancellor Suggested-by: Eric Dumazet Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reported-by: Giuliano Procida Reported-by: Yabin Cui Closes: https://github.com/ClangBuiltLinux/linux/issues/2173 Cc: Bill Wendling Cc: Justin Stitt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6d4b937251386d9c6f968e7802f0cb16a8523772 Author: Jérémy Jean Date: Sun Aug 9 19:04:16 2026 +0000 timers/itimer: Zero-init old itimerval before copy to userspace commit 18c7d85864e554adc8fad1e8d2e9d2cb6c3911c8 upstream. On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary. Signed-off-by: Jérémy Jean Signed-off-by: Thomas Gleixner Assisted-by: Codex:gpt-5 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260809190428.1523014-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Greg Kroah-Hartman commit 0cc4b14d7401d50e53a01f1554147ee075ee6943 Author: Felix Yan Date: Thu Jun 25 06:04:34 2026 +0800 clocksource/drivers/timer-sun4i: Advertise a real minimum delta commit d21808328225ab8cee46885bf9a0dffcefbe630e upstream. sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation. Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program") Reported-by: Indrek Kruusa Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Assisted-by: Codex:gpt-5.5 Signed-off-by: Felix Yan Signed-off-by: Daniel Lezcano Tested-by: Indrek Kruusa Acked-by: Jernej Skrabec Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Link: https://patch.msgid.link/20260624220434.4183732-1-felixonmars@archlinux.org Signed-off-by: Greg Kroah-Hartman commit f57467114f40c5aacebbea96fb4ff9e5cd2b7f18 Author: Takashi Iwai Date: Tue Sep 1 12:37:29 2026 +0200 ALSA: aloop: Fix racy access at PCM trigger [ Upstream commit 826af7fa62e347464b1b4e0ba2fe19a92438084f ] The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF. Reported-by: syzbot+5f8f3acdee1ec7a7ef7b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/69783ba1.050a0220.c9109.0011.GAE@google.com Cc: Link: https://patch.msgid.link/20260203141003.116584-1-tiwai@suse.de Signed-off-by: Takashi Iwai [ Karl Mehltretter: open-coded spin_lock_irqsave() instead of scoped_guard(); used snd_pcm_running() instead of cruntime->state; dropped the access-mode comparison and notification (462494565c27, e299a9fd433f, cdac6e1f7164); kept the stop_count handling from the e5c33cdc6f40 backport. ] Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Sasha Levin commit 2a6663b4fdcf9ad6e0b3edfda78464fa25bb3853 Author: Fedor Pchelkin Date: Sun Aug 30 17:53:19 2026 +0300 Revert "USB: serial: keyspan_pda: fix information leak" This reverts commit cccef1711efbcdbe999738ac27d37b9ef6271abd which is commit 6bfc8d01ac4068eced509f8fc74d0cd205e4dcec upstream. The 5.10 backport is incorrect - instead of keyspan_pda_write_start() it touches the wrong function keyspan_pda_write() which now returns an incorrect number of buffered bytes. It turns out that the proper fix for keyspan_pda_write_start() has been already incorporated into the ported version of upstream commit 034e38e8f687 ("USB: serial: keyspan_pda: add write-fifo support"), for unknown reason. Other stable kernels, starting with 5.15, got proper backports. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Signed-off-by: Fedor Pchelkin Signed-off-by: Sasha Levin