commit 500df175a7f9e6bc1a9c328590ca5150f84f9ff0 Author: Greg Kroah-Hartman Date: Mon Sep 14 13:41:11 2026 +0200 Linux 7.2.6 Link: https://lore.kernel.org/r/20260912065648.999753832@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Salvatore Bonaccorso Tested-by: Ronald Warsow Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Benjamin Boortz Tested-by: Markus Reichelt Tested-by: Barry K. Nathan Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 61a8d06600c8c397f9a7e01940479d4c94a82f5f Author: Namjae Jeon Date: Fri Aug 28 08:39:57 2026 +0900 ksmbd: prevent out-of-bounds reads in share config responses commit f25e93768fcc5d8287e50b1ec52a42e4c276df34 upstream. Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length. Fixes: a677ebd8ca2f ("ksmbd: validate payload size in ipc response") Reported-by: Kanishka De Silva Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 1f0085f15004dafdc0ca98ce82dc52562b7a6181 Author: Ian Rogers Date: Mon Jun 15 18:15:24 2026 -0700 perf python: Add missed explicit dependencies commit 01fa2d416aceab51f97ec2769e8da9971a605eeb upstream. Fix missing #include of pmus.h found while cleaning the evsel/evlist header files. Also define PY_SSIZE_T_CLEAN before including Python.h to comply with modern Python 3 C-API requirements, and introduce CHECK_INITIALIZED and CHECK_INITIALIZED_INT safety macros to be used by subsequent patches. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 8f57985e30a28026232bf8a07d968ad9da846426 Author: Ian Rogers Date: Wed Jul 22 21:59:47 2026 -0700 perf ui hists: Fix dso_filter reference leak and exit zoom cleanup commit bd86119c3ee6ed7b8fc9be8298fe49f1a5355a46 upstream. In hists_browser__zoom_map(), the active dso is assigned as a raw pointer to hists->dso_filter without acquiring a reference using dso__get(). This creates a potential use-after-free defect if the underlying dso is released while the filter remains active. Fix it by properly acquiring a reference via dso__get() when assigning the filter, and releasing it with dso__put() when clearing it. Additionally, since the browser stack relies on pstack__new() and deletes it completely upon exiting, we must fully reset the persistent hists structure by un-eliding columns and recalculating histogram filter states for dso, thread, and symbols upon exit to guarantee immaculate, uncorrupted state across browser tab switching. Closes: https://lore.kernel.org/linux-perf-users/20260709170834.52F1A1F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 078aca7b8051322b835a6f5667f386f299ceac93 Author: Ian Rogers Date: Thu Jul 16 00:23:42 2026 -0700 perf hists browser: Increase MAX_OPTIONS to prevent stack buffer overflow commit 2ec3b985872594031cc1000b830344de5c26633d upstream. In evsel__hists_browse(), the 'options' and 'actions' arrays are statically allocated on the stack with a size of MAX_OPTIONS (16). Further down, the function sequentially calls several add_*_opt() functions, which increment nr_options without bounds checking. Depending on the context (e.g., branch mode, scripting, annotations), the sum of added options can theoretically exceed 16 (potentially reaching up to ~19). This could lead to a stack buffer overflow. Increase MAX_OPTIONS to 32 to safely accommodate the maximum possible number of options without risking an overflow. Closes: https://lore.kernel.org/linux-perf-users/20260708235834.3FB771F00A3A@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Link: https://lore.kernel.org/linux-perf-users/20260708235834.3FB771F00A3A@smtp.kernel.org/ Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 72e9387884554f47b03bfd40fb8b2bf52789c68d Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:22 2026 -0400 net/sched: fq: clamp quantum and initial_quantum in change path [ Upstream commit 094cc07f98dfe70a34e2a1923af17fd29b8cf622 ] The fq change path accepts TCA_FQ_QUANTUM in [1, INT_MAX] and TCA_FQ_INITIAL_QUANTUM up to INT_MAX, while fq_init() already clamps to [1, 1<<20]. A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp prevents. Narrow iq_range.max to 1<<20 so TCA_FQ_INITIAL_QUANTUM is rejected at parse time. Clamp TCA_FQ_QUANTUM to [256, 1<<20] in fq_change() and fq_init() quantum to [256, 1<<20] for tiny-MTU devices. Conditions to recreate the bug: CONFIG_NET_SCH_FQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq tc qdisc change dev dummy0 root fq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.2 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b04326c7927af7048fd4e730f5770cca350d0a60 Author: Pavel Begunkov Date: Fri Sep 4 14:43:07 2026 +0100 tcp: reject non zerocopy devmem tx [ Upstream commit 125755776bc6d4dd53eaf551c87e3d460625d638 ] Devmem tcp tx doesn't work without zero-copy, however it's not currently enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked() will try the copy path and try to copy data from an iovec which consists of offsets into the dma-buf and would normally fail. Moreover, d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") relies on that and assumes that the devmem binding is present IFF we're using the zero-copy path, which can be used to mix net-iov and pages in a single skb, and break invariants. Let's reject devmem tx without zero-copy. Note, the parameter check the patch is modifying is too loose, we can create an io_uring request with dmabuf_id and all ZC flags, but which won't have the binding. We replace it with stricter validation. Fixes: bd61848900bff ("net: devmem: Implement TX path") Fixes: d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") Signed-off-by: Pavel Begunkov Reviewed-by: Mina Almasry Link: https://patch.msgid.link/fdc2478d8f21268d7078556409887d8e6ba0ad32.1788529053.git.asml.silence@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2bfcedbf68cbd311f2ea7ed2fec55121a91f48cf Author: Steffen Klassert Date: Mon Aug 17 07:17:58 2026 +0200 Revert "esp: do not unref managed frag pages in esp_ssg_unref()" [ Upstream commit 0fda52de8bbd4ca9a852c8a7ef6536cf82bd71fd ] This reverts commit 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80. The patch does not fix the issue completely, so revert for now and wait for an updated version. Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit dd08a645195f410f2dcaa40de379a45ce110e873 Author: Ben Cressey Date: Thu Aug 20 21:44:57 2026 +0000 dm-integrity: fix buffer overflow with keyed discard commit 59e6f919d77d72ec79cbf171256f2f7819737580 upstream. Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page. Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes. Fixes: 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker") Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 872317e84fd019ceffba125e62d31586e3336d41 Author: Jamal Hadi Salim Date: Wed Aug 26 11:33:39 2026 -0300 net/sched: sch_htb: limit htb_classify inner-class filter hops [ Upstream commit 729c4896ab829169f95915d65edd530325910b37 ] htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Vega Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826143339.271935-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 47eb90299e6882d6445672530dd7c51ac33ebdbd 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 75667703115154a4fd9cf259d4f826d8729cbcda 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 5975009651c4e5ec1492612962d0dd3dc86f6bda 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 a540a49fcca59d1c92c3a6462e67ca21676a88df Author: Eric Dumazet Date: Wed Aug 26 10:52:38 2026 +0000 slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() [ Upstream commit 23c53269f2baaedf2d92784290cb9ef6db2a3bce ] Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close(). Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Reported-by: Jaeyoung Chung Reported-by: Eulgyu Kim Closes: https://lore.kernel.org/netdev/20260825150655.1450271-1-jjy600901@snu.ac.kr/ Cc: Qingfang Deng Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260826105238.3323436-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16d21a27df3f50b7251c9388fc5a7ab22703b469 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 a9d88c79746cf696fe2100645100792278f26ac6 Author: Edoardo Pinci Date: Mon Aug 24 15:11:43 2026 +0200 net: dsa: mxl862xx: enable assisted learning on CPU port [ Upstream commit 88c71cc0ad9800d8814bd3627b21a0da9028e057 ] The MxL862xx driver enables FDB isolation but does not enable assisted learning on the CPU port. Consequently, MAC addresses learned through a physical switch port are not updated in hardware when the corresponding station moves to a foreign bridge port, such as a Wi-Fi interface. The stale hardware FDB entry continues directing return traffic toward the original physical port. Traffic entering that same port is then filtered instead of being forwarded to the CPU and software bridge. This causes downstream unicast traffic, including DHCP OFFER and ACK packets, to disappear after a client roams to a local wireless interface. The client eventually considers the connection unusable and disconnects. Enable assisted CPU-port learning so DSA installs foreign bridge FDB entries on the CPU port. This keeps the hardware FDB synchronized with the software bridge and allows return traffic to reach locally attached Wi-Fi clients after roaming. Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface. - Without patch, wired uplink on lan6 port (mxl path) Wifi clients connect but roam away not getting DHCP offers - Without patch, wired uplink on wan port (no mxl path) Wifi clients connect and roam successfully - With this patch, uplink on lan6 (mxl path) Wifi clients connect and roam successfully Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading") Signed-off-by: Edoardo Pinci Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c0d3f9560cc890bc2d96d9f487584688ae6e5185 Author: Pascal Kneuper Date: Mon Aug 24 14:50:14 2026 +0200 net: stmmac: restore NET_IP_ALIGN in the RX DMA offset [ Upstream commit 23680bf5f8c69c923546b84a8e6c401bef8b88fe ] Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318fe67e ("stmmac: align RX buffers") made a similar change in 2021 and was reverted by commit 12d125b4574b ("stmmac: Revert "stmmac: align RX buffers"") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for. Fixes: df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") Cc: Daniel Baldin Signed-off-by: Pascal Kneuper Link: https://patch.msgid.link/20260824125014.47862-1-PKneuper@dspace.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b445030cca1f6c443f5c4de0902590c641e133c9 Author: Lorenzo Bianconi Date: Mon Aug 24 11:59:08 2026 +0200 net: stmmac: drop gso_enabled_types and rely on netdev features [ Upstream commit 9c24a504a3af1acb96da8d6a45a373fda8a9c687 ] The gso_enabled_types field is used by stmmac_xmit() to decide whether a GSO skb should be passed to stmmac_tso_xmit(). It is updated in stmmac_set_features() based solely on NETIF_F_TSO, so disabling IPv4 TSO while keeping IPv6 TSO (NETIF_F_TSO6) enabled zeroes the mask. As a result IPv6 GSO frames, which the networking stack still generates since NETIF_F_TSO6 is enabled, fall through to the non-TSO xmit path where they are not handled. The networking stack already manages the GSO logic: a GSO skb is only delivered to the driver when the matching offload feature (NETIF_F_TSO, NETIF_F_TSO6 or NETIF_F_GSO_UDP_L4) is enabled, otherwise the frame is segmented in software before reaching ndo_start_xmit(). stmmac_features_check() also validates each GSO frame against the TSO hardware constraints and falls back to software GSO when they are not met. Drop the gso_enabled_types field and rely on skb_is_gso() in stmmac_xmit() instead, which correctly routes IPv6 GSO frames to the TSO path when NETIF_F_TSO is disabled. This also removes the data race between stmmac_set_gso_types(), called from the feature-set path, and the lockless read of gso_enabled_types in stmmac_xmit(). Fixes: 2e4082e4b739 ("net: stmmac: simplify GSO/TSO test in stmmac_xmit()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260824-stmmac-fix-tso6-features-v3-1-c73a7a4a0ec7@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 482b2542eeb82fc04c9c1cf3c96348e29c964def Author: Maxime Chevallier Date: Wed Aug 26 16:04:58 2026 +0200 net: stmmac: selftests: Don't test flow control for small rx fifos [ Upstream commit 96e8cb5527ce50c024a8e2d22d2bfedeccaf97d0 ] On dwmac1000, dwmac4 and dwxgmac, we only emit pause frames if there's at least 4096 bytes in each queue's fifo. The phylink mac capabilities are still MAC_ASYM_PAUSE | MAC_SYM_PAUSE as otherwise we won't be able to negotiate 'rx on' pause. ASYM only will prevent negotiating 'rx off tx on', while SYM only doesn't really matche the reality (not symmetric if we can only do RX pause). Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-7-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a106e59b0519710a87a23da05caf5b03c92a296 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 d1fad6804be2a50012a65bef564fff59e2a8ac09 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 10cf85addedeb1938442b3539e951ae81e00fd52 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 db57c2c4eaa524717bf7b9dcced3d10fa02a17e3 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 756932d2c6a0b2b0d19a2f0fe7acbae5743d2757 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 2bbd61823f2275ce747e0504e04647eda8a3a019 Author: Anoop Vijay Date: Tue Aug 25 10:28:28 2026 -0700 drm/xe/sysctrl: Read mailbox phase bit from hardware [ Upstream commit a62212b35a214c2ff3bd1c785a440d7ad8205ec9 ] The mailbox PHASE bit in SYSCTRL_MB_CTRL is toggled per-message and was tracked in software as sc->phase_bit, reset to 0 on error paths. If the cached value ever drifts from what the hardware last saw, all following messages carry the wrong phase and get silently misread by firmware. Drop the cache and read PHASE directly from SYSCTRL_MB_CTRL before each frame instead, removing xe_sysctrl_mailbox_init() and its call sites along with it. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Signed-off-by: Anoop Vijay Reviewed-by: Umesh Nerlige Ramappa Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260825172827.3801591-2-anoop.c.vijay@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 04984fcdbf6876c940c01026a7404c1e9cc91ba7) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 08f8c20feca962b031fd1967e0985065c4ab9850 Author: Riana Tauro Date: Thu Jun 18 11:36:36 2026 +0530 drm/xe/xe_ras: Add support to get error counter value [ Upstream commit fe48a86980798ffc78c8713ec964877c8594610d ] Add request/response structures and helper functions to query system controller to get error counter value. Reviewed-by: Raag Jadav Link: https://patch.msgid.link/20260618060633.2790109-10-riana.tauro@intel.com Signed-off-by: Riana Tauro Stable-dep-of: a62212b35a21 ("drm/xe/sysctrl: Read mailbox phase bit from hardware") Signed-off-by: Sasha Levin commit da853f33044955d8ce3c2ee244195e408a1a3d88 Author: Riana Tauro Date: Thu Jun 18 11:36:35 2026 +0530 drm/xe/uapi: Add additional error components to xe drm_ras [ Upstream commit cdeb5e248de11537cf23cd5174f6c55bab2e850b ] Add additional Error components supported by XE drm_ras (Reliability, Availability and Serviceability). Reviewed-by: Aravind Iddamsetty Reviewed-by: Mallesh Koujalagi Acked-by: Rodrigo Vivi Link: https://patch.msgid.link/20260618060633.2790109-9-riana.tauro@intel.com Signed-off-by: Riana Tauro Stable-dep-of: a62212b35a21 ("drm/xe/sysctrl: Read mailbox phase bit from hardware") Signed-off-by: Sasha Levin commit 1ffe1bd34b497af384cc8f93d00f5e36720fd9ed Author: Daniel Pawlik Date: Thu Aug 20 10:59:40 2026 +0200 net: airoha: npu: fix missing streaming DMA mask [ Upstream commit 6fe7e31a45e3418a39e6343a85126124feec1c2f ] The driver calls dma_set_coherent_mask() but never dma_set_mask(), leaving the streaming DMA mask at the bus default. On the non-coherent EN7581 platform (Cortex-A53), this causes the NPU mailbox to hang after approximately 41 calls when using streaming DMA mappings. Replace dma_set_coherent_mask() with dma_set_mask_and_coherent() to set both the streaming and coherent DMA masks, matching standard driver practice. Fixes: 6f884eb87a79 ("net: airoha: Fix DMA direction for NPU mailbox buffer") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260814110017.2795022-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260809152813.585797-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260805070851.2885888-1-pawlik.dan@gmail.com/ Signed-off-by: Daniel Pawlik Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260820085941.380401-1-pawlik.dan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc3ee01090856c3e079afd41d6bbe848e302ca5a Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:36 2026 +0100 selftests/arm64: Fix MTE prctl TAP plan [ Upstream commit bb52892f9234e4ecd982fa51222aab33ce282f79 ] The MTE prctl test emits one result from check_basic_read() followed by one result for each of the seven entries in mte_modes[]. However, the TAP plan only accounts for the array entries, producing: # Planned tests != run tests (7 != 8) Include the basic read check in the plan so that all eight emitted results are declared. Reviewed-by: Mark Brown Fixes: 1f488fb91378 ("kselftest/arm64/mte: Add MTE_STORE_ONLY testcases") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 5791116f96d4f50ed997f3cad7ffb88c64244017 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 a327373156bb51b2e7f803c2b79864646bc4722c Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:34 2026 +0100 selftests/arm64: Print missing MTE TAP headers [ Upstream commit 8d2237e9d6902e234bb89aabb9cd6a9e91357223 ] Most MTE tests set a TAP plan and emit results without first printing the TAP version header. Direct execution therefore starts with a plan such as "1..20" instead of "TAP version 13". The problem is particularly visible in the GCR_EL1 context-switch test. It prints its plan before forking 1,024 child processes. When stdout is fully buffered, the plan remains in the stdio buffer. Each child inherits the pending "1..1" line and flushes its copy from exit(), producing repeated plan lines. ksft_print_header() prints the TAP header and enables line buffering. Call it in every MTE test that is missing it. In the GCR_EL1 test, call it before the plan so the plan is flushed before the children are forked. In the remaining tests, call it before setup and prerequisite checks so early failures and whole-test skips also retain the header. Fixes: 29f080881601 ("kselftest/arm64: check GCR_EL1 after context switch") 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 18c08f84ca483029f04e426ec7ca3b5d3684cf22 Author: Takashi Iwai Date: Thu Aug 27 13:39:03 2026 +0200 ALSA: control: Don't add invalid kcontrols to LED layer [ Upstream commit 74e3b979ce8b78a690f8b94ccf2e2c965f7f5c11 ] The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer. Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com Fixes: 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer") Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de Signed-off-by: Sasha Levin commit 1e7fb6801d9cc826adcdb7fa0533c397730657f2 Author: Pablo Neira Ayuso Date: Wed Aug 19 13:42:36 2026 +0200 netfilter: nf_tables: skip double clone set expressions on element insert [ Upstream commit 43559058d21e0493aa220ac167e0279334dea5f9 ] Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they represent an override. Use this new override_exprs flag to dump the dynset expression override to userspace. This simplifies the existing logic and it also fixes a bug with the connlimit expression which results in a module refcount imbalance WARNING splat when resorting on the default set expressions. Fixes: 65038428b2c6 ("netfilter: nf_tables: allow to specify stateful expression in set definition") Fixes: fca05d4d61e6 ("netfilter: nft_dynset: honor stateful expressions in set definition") Reported-by: Xingyuan Mo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0044a4b853728fadd51119ba7d1fc0a3af3f448e 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 6a7d3b074cfbb64513f5f92d60ab1b216ae98076 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 75c271c48f483af678e514734e10b2452410e08c Author: Alice Mikityanska Date: Sat Aug 22 15:01:16 2026 +0300 virtio-net: Ensure that TCP packets don't overflow gso_segs [ Upstream commit c27c449d455aafd9018a3cbab150f1c42c87923f ] The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649. Fixes: 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") Signed-off-by: Alice Mikityanska Suggested-by: Eric Dumazet Link: https://patch.msgid.link/20260822120117.1163423-2-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 905d648e97ef3a291f71a935a7fab0133f27f0f7 Author: Arvind Yadav Date: Thu Aug 20 12:24:45 2026 +0530 drm/xe: Reject page faults from non-fault-mode scratch VMs [ Upstream commit 5e977521d21717edb8e91d004434697d6e3f248c ] Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs. If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely. Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected. Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Cc: Matthew Brost Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Suggested-by: Matthew Brost Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260820065445.567228-1-arvind.yadav@intel.com (cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 9cc86bf96cfc3a66d33d1f99089f85cb37d50855 Author: Balasubramani Vivekanandan Date: Wed Aug 19 13:04:58 2026 +0530 drm/xe/xe_gt_idle: Add CCS to the powergating info print [ Upstream commit 369ba0d1efe91cccabe98ae53c53b7425f327edf ] While reading the main GT powergating info from debugfs, include both RCS and CCS engine masks. Fixes: 0914c1e45d3a1 ("drm/xe/xe_gt_idle: add debugfs entry for powergating info") Signed-off-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260819073457.1812722-2-balasubramani.vivekanandan@intel.com Reviewed-by: Matt Roper Signed-off-by: Matt Roper (cherry picked from commit 8899e413c5ab85443ec9bbc50cffe924c6b596de) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 2f1fac18cbe80004586d9f10d1281f2ca381ab7e Author: Daniele Ceraolo Spurio Date: Tue Aug 18 21:35:20 2026 +0000 drm/xe: Do not apply WA 14025883347 to media 3503 [ Upstream commit f0feab6e9e008faa406d189fb40cb7ab1bed420a ] The database was updated and the WA is no longer listed as applicable to media 3503, so don't enable it there. Fixes: c57db41b8d2c ("drm/xe/guc: Add Wa_14025883347 for GuC DMA failure on reset") Signed-off-by: Daniele Ceraolo Spurio Cc: Sk Anirban Cc: Badal Nilawar Cc: Matt Roper Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260818213520.283063-1-daniele.ceraolospurio@intel.com (cherry picked from commit fae59d5de5de39bc51ac2839f74970312e0c8905) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 1b871710ae9f636ad5588c84779dee8c6d45e455 Author: Maxime Chevallier Date: Tue Aug 25 23:17:46 2026 +0200 net: stmmac: selftests: Pass the IP proto mask in the TC selftest [ Upstream commit 9a56a27e6002e29a6707dc4238d469ec84c3a68e ] The stmmac TC filtering rules have recently gained sanity checks to make sure the passed keys and their respective masks are aligned with the HW filtering abilities. The stmmac selftests failed to pass the mask in the match data for L4 filtering tests, and are now failing consistently with -EINVAL : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering -22 24. L4 SA TCP Filtering -22 25. L4 DA UDP Filtering -22 26. L4 SA UDP Filtering -22 Let's pass the ip_proto mask in the l4 filtering tests match data. Found on imx8mp, which now have passing L4 tests : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering 0 24. L4 SA TCP Filtering 0 25. L4 DA UDP Filtering 0 26. L4 SA UDP Filtering 0 While at it, initialize the masks and keys to avoid re-using whatever was on the stack. Fixes: 5536d7c84363 ("net: stmmac: fix l3l4 filter rejecting unsupported offload requests") Reviewed-by: Andrew Lunn Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260825211748.360935-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dadcbaa98de3f25305bb6ff28d6201e3dcea9efb Author: Jiawen Wu Date: Mon Aug 24 15:21:19 2026 +0800 net: wangxun: use BIT_ULL() to prevent shift overflow on 32-bit archs [ Upstream commit 63c885688f38a757947d7050b1ee4171215269ce ] The macros TXGBE_INTR_MISC() and WX_INTR_Q() rely on the standard BIT() macro to generate interrupt masks based on the queue vector index. On 32-bit architectures, BIT() evaluates to a 32-bit `unsigned long`. Since the number of queue vectors can be up to 63 on txgbe devices, performing a left shift of 32 or more results in an integer overflow and undefined behavior. This causes incorrect interrupt masking and unmasking logic for both the queue and miscellaneous interrupts on 32-bit systems. Fix this by replacing BIT() with BIT_ULL() in these macros. This ensures that the bitwise shift is always performed safely on a 64-bit `unsigned long long` type, regardless of the underlying architecture. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/45F5565CE6AC4329+20260824072119.48399-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a32c4a6dc96cc2b57601d8c9c7f16b18ced413cf Author: Vitaliy Sochnev Date: Sun Aug 23 14:06:36 2026 +0100 net: phy: air_en8811h: move LED GPIO configuration to config_init [ Upstream commit 03b4702fc5e311cbac9ba8654021a88f0dac914c ] The LED GPIO pins (GPIO3/4/5, mapped to LED2/LED1/LED0) are only ever configured as outputs once, in .probe(). But .config_init() restarts the MD32 MCU via en8811h_restart_mcu() on every call after the first (priv->mcu_needs_restart), and that restart resets buckpbus-mapped MCU state, including EN8811H_GPIO_OUTPUT. As a result the LED GPIOs fall back to inputs after the first event that re-triggers .config_init() (link renegotiation, ifdown/ifup, resume), and the PHY's LEDs stop reflecting link/activity state even though they worked right after probe. Move the GPIO-as-output configuration from .probe() to the end of .config_init(), so it is reapplied every time the MCU may have been restarted. Fixes: 71e79430117d ("net: phy: air_en8811h: Add the Airoha EN8811H PHY driver") Suggested-by: Mikhail Zhilkin Signed-off-by: Vitaliy Sochnev Link: https://patch.msgid.link/20260823130638.1166453-2-sochnev.v.74@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 94a913cd521c0f0408820bcdbd80dadf076d97b5 Author: Yifei Chu Date: Mon Aug 24 10:27:19 2026 +0800 net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure [ Upstream commit cec261b0b4c5c0b044165303198d10ffcdf3414c ] IPPROTO_SMC sockets create an internal TCP sock ("clcsock") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op. Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC") Reported-by: Abaci Assisted-by: abaci:qwen3.8-max Signed-off-by: Yifei Chu Reviewed-by: Dust Li Link: https://patch.msgid.link/178753843966.342810.566471390946765094@linux.alibaba.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ff481b7ba651da81cd992a81d6f31a80f9461856 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 2e658329d77498416c724e6455ec3fe05bc9e1b0 Author: Shengyu Qu Date: Thu Aug 27 01:20:50 2026 +0800 ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants [ Upstream commit 15596a87fcc6fa07a162858e5fd00ba31752096b ] Existing quirk doesn't cover all known existing FA401EA devices, so use "FA401EA" to cover all of them. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221310#c49 Fixes: 27d090f3ccd4 ("ASoC: amd: acp: add ACP70 DMI override for new ASUS TUF platforms") Signed-off-by: Shengyu Qu Link: https://patch.msgid.link/20260826172050.15686-1-wiagn@4d2.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf839636911d8313f3ecd098329fd0b96499e4cf Author: Haotian Zhang Date: Wed Aug 26 09:50:50 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify [ Upstream commit 6727b7618f49401acf373fa3ec5712e2ec52e5cf ] ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015050.10772-1-vulab@iscas.ac.cn Fixes: e1067a07cfbc ("ftrace/samples: Add module to test multi direct modify interface") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 84b5c7670a867c3a7c846d73b1e728631d79b3d4 Author: Haotian Zhang Date: Wed Aug 26 09:50:34 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify [ Upstream commit d79fb758e7e2e7a181eab630c0545a56041c473d ] ftrace_direct_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015034.10755-1-vulab@iscas.ac.cn Fixes: ae0cc3b7e7f5 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit c77633a9595658210a6e216a071e5a396a0835a7 Author: Aleksandr Nogikh Date: Fri Jul 31 10:14:50 2026 +0000 libceph: validate banner payload length [ Upstream commit f374967fcdf04001c9b66df1c19106fa83cd91f7 ] When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 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 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error. Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+87c7c2d63c44e41c77a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=87c7c2d63c44e41c77a3 Link: https://syzkaller.appspot.com/ai_job?id=c8ca3d63-717a-4933-89ec-f3d761b8690d Signed-off-by: Aleksandr Nogikh Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 36138bde421a3155618a62e8a27fa09c0a09625b Author: Xiubo Li Date: Tue Jul 21 13:06:53 2026 +0800 ceph: revalidate ki_pos for O_APPEND writes after cap acquisition [ Upstream commit d2a8d446a09c74c8ddfe108b50dd791c889983fc ] For O_APPEND writes, ki_pos is set to the current EOF via generic_write_checks() after fetching i_size from the MDS. However, ceph_get_caps() may need to wait for Fwx exclusive caps if the write extends the file (endoff > i_max_size). While waiting for Fwx, the previous Fwx holder (another client) may have already extended the file. When the MDS grants us Fwx, the cap grant message updates the local i_size, but ki_pos remains at the old EOF, causing the append write to land at a stale offset and overwrite data from the other client. Fix by re-reading i_size_read(inode) after ceph_get_caps() returns. At this point we hold Fwx exclusive caps, no other client can modify the file, and i_size reflects the true EOF from the MDS cap grant. No extra MDS round-trip is needed. Only adjust ki_pos when the EOF has actually changed. After adjusting ki_pos forward, the write range [pos, pos+count) may now exceed the i_max_size that was validated by ceph_get_caps() for the old range. Re-check against i_max_size and truncate the write if necessary to stay within the MDS-granted limit. Link: https://tracker.ceph.com/issues/7333 Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel if O_APPEND is specified") Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit c5fd89f5e127334429e4092ebbdf1b219a623a04 Author: Hongling Zeng Date: Thu Jun 4 15:43:25 2026 +0800 ceph: Fix ERR_PTR(0) in ceph_mkdir() [ Upstream commit 4f49c3f8a5a86d237bb202ecb17c2802ddc8fd2f ] When mkdir succeeds, ceph_mkdir() sets ret to ERR_PTR(0) which is incorrect. It should return NULL instead for success. Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 55126ef66298e43c69f192acebae8c7cc0022cf6 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 8968852e664f4850aa6c6c300e4d7e80333eb676 Author: Fuad Tabba Date: Wed Aug 26 12:22:34 2026 +0100 of/irq: Fix device node refcount leak in of_irq_get_affinity() [ Upstream commit fe66c3ff85e85d492673c6dc95c3d624a63e0282 ] of_irq_parse_one() raises the refcount of the interrupt controller node on success, and of_irq_get_affinity() returns without putting it, so every call past the parse leaks one reference. It is reached from platform_get_irq_affinity(), used by arm_pmu, arm_spe_pmu and coresight-trbe. Put it once irq_populate_fwspec_info() has run: no in-tree ->get_fwspec_info() returns a mask that lives in the node. Fixes: 5404f5c06dd4 ("of/irq: Add interrupt affinity reporting interface") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260826112234.1033974-1-fuad.tabba@linux.dev Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit dd52ab1c5436be86f5b8ca118fa8e5d61d63ffed 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 889fa17a0af09ff93a9166abc82ee7a654faa49b Author: Jérémy Jean Date: Sat Aug 15 10:09:18 2026 +0000 crypto: acomp - allocate async request context when cloning [ Upstream commit ee440d4fc0d2f15894ab1f64c474a3adbc858880 ] ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization. Fixes: 097c432caaa6 ("crypto: acomp - Add ACOMP_REQUEST_CLONE") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f0e06321c70e9f3349ad9142b4d4c3efca5a131c 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 e6d7d9b665419cda3e9f91030d81c9f8ba71e51d 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 0cd75037948567193f7f5767176538822ce23873 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 da16c31517cd2c06bb2c78c73e91ae192c01c426 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 2446644b0f6d045b01db6acbaf55552dbec8a59a 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 bf97fd2163ad1191ef8daa3d4df8372aee19e396 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 f2fe291fbf71c854a36d340469e2fd044c8b361c 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 9f499e5827fdb6d7fdb46a7ce731852f6b1a1bb9 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 e35acd56f244d94355f9ab237c2ecc8fba5e6f04 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:04 2026 -0400 net/sched: fq: add overflow bounds to quantum and initial quantum [ Upstream commit 709f34f7c28dc4dd6c40343d101850f11e172312 ] fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-2-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e69bde4eb566aea8fa97cbb93e0bab608964f1a5 Author: Tetsuo Handa Date: Sat Aug 22 17:18:31 2026 +0900 net: fix a resource leak in copy_net_ns() error handling path [ Upstream commit 3220b62fbb8a55feebd2a826d5ead0f49f09ed5a ] Currently, preinit_net() does two things: (1) call ns_common_init() which might fail (2) initialize resources which does not fail However, preinit_net() is returning early when (1) fails, and copy_net_ns() is jumping to the dec_ucounts: label. As a result, resources allocated by net_alloc() are leaking. We need to call key_remove_domain() and net_passive_dec() in order to release resources allocated by net_alloc(). We cannot simply jump to the put_userns: label when preinit_net() failed, for (2) is not yet done. But we can reorder (1) and (2), for there is no dependency between (1) and (2). Therefore, this patch decouples (1) from preinit_net() and changes preinit_net() back to a void function, and calls ns_common_init() after preinit_net() succeeded. Then, we can jump to immediately after ns_common_free() of the put_userns: label. Reported-by: sashiko (no mail address) Closes: https://sashiko.dev/#/patchset/af7dabf3-d0d7-46dc-a878-e1715b3c9ac6%40I-love.SAKURA.ne.jp Fixes: 08027f6b790b ("net: use ns_common_init()") Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/c182cf90-1ed7-435b-88f7-9f00e88a0487@I-love.SAKURA.ne.jp Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit efb4cdd8d72bd0f25eee465d6c97a20f3d973a2c Author: Mina Almasry Date: Sun Aug 23 18:36:01 2026 +0000 net: core: check skb_frags_readable before uncloning in skb_copy_ubufs [ Upstream commit 00e11ee9831b3439264e0ae6762a0470126515af ] skb_copy_ubufs drops clones and modifies the SKB via pskb_expand_head() before checking for !skb_frags_readable(skb). This alters the SKB geometry prior to throwing an -EFAULT on an invalid SKB. Check readability first. Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260823183602.1051453-1-almasrymina@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 62126464f3a6159c0a3dd89e196ba65bfeb0afc6 Author: Eric Dumazet Date: Sun Aug 23 18:22:41 2026 +0000 net/sched: act_skbmod: fix length calculations and avoid invalid header warnings [ Upstream commit 81d0d1e64f30d9989c829c0953cd6e6c68d9c5fb ] syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER. Fixes: 56af5e749f20 ("net/sched: act_skbmod: Add SKBMOD_F_ECN option support") Reported-by: syzbot+1d56f14f95c0480cfdc9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8b39c0.dbb3a75c.13dd47.0051.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260823182241.1958695-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0f0f3df2bde2ef79599047890b64acf5cf97b124 Author: Karl Mehltretter Date: Sat Aug 8 22:03:12 2026 +0200 selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC [ Upstream commit 0685630fdccb62dcb0e3f44525a40578da5f6dc8 ] test_maps_tearing_from_split times out when READ_IMPLIES_EXEC is set. This happens by default on pre-ARMv6 CPUs, which lack no-execute support. split_vma() re-maps the first page with mod_info->prot | PROT_EXEC to make it differ from its neighbours. With READ_IMPLIES_EXEC the original mapping is already executable, so no split occurs and the test hangs waiting for the modifier child. Use PROT_NONE for the split mapping, which always differs from its readable neighbours. Link: https://lore.kernel.org/20260808200312.6326-1-kmehltretter@gmail.com Fixes: beb69e817246 ("selftests/proc: add /proc/pid/maps tearing from vma split test") Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Karl Mehltretter Acked-by: Suren Baghdasaryan Cc: Alexey Dobriyan Cc: Jann Horn Cc: Liam R. Howlett Cc: Shuah Khan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7efd495853aeb7614db6aeb9aeeec7889d6add2b Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:25 2026 -0400 maple_tree: fix argument name in header [ Upstream commit 00f67814a14e614b749ebe54076ef1e3e6454f2b ] The mas_prev_range() function takes a min and not a max. Link: https://lore.kernel.org/20260821192627.4085470-18-liam@infradead.org Fixes: 6b9e93e01020 ("maple_tree: add mas_prev_range() and mas_find_range_rev interface") Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit dfe9ee26a9ad0df76d521025267b1c337b7156f1 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:20 2026 -0400 maple_tree: catch race in mas_alloc_cyclic() [ Upstream commit 35f1342e5b893a740eff2ef9ab337bfaa63ab76d ] If mas_alloc_cyclic() is called during a low memory situation, it is possible the lock may be dropped so reclaim can occur. There is a window where some other task may allocate the same id and cause the mas_insert() to fail with -EEXIST. In this scenario the function will return -EEXIST, which is not expected. Modifying the retry on mas_nomem() to re-search for a slot means that any race with other writes will not matter as the lock will be held between finding the index and writing the index. Moving the flag logic avoids cases where the flag is modified on drop lock/reacquire or when the write fails after clearing the flag. No existing users are exposed to this issue. Link: https://lore.kernel.org/20260821192627.4085470-13-liam@infradead.org Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett (Oracle) Reported-by: Chris Mason Reviewed-by: Chuck Lever Cc: Boqun Feng Cc: Breno Leitao Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 21aea0891c2043b7c0c18bf877325be35ba80879 Author: Usama Arif Date: Mon Aug 17 03:38:35 2026 -0700 mm/memcontrol: avoid false sharing between vmstats and events [ Upstream commit c1afbd5de131f5e3c4fc7559acf055f8d9d86868 ] Moving v1 userspace eventfd handling into memcontrol-v1.c shrank struct vmpressure from 112 to 24 bytes when CONFIG_MEMCG_V1 is disabled. This moved memory_events_local[MEMCG_SWAP_FAIL] and the hot vmstats_percpu pointer onto the same cacheline. The stress-ng mremap stressor exercises MADV_PAGEOUT with swap disabled, generating about 20 million MEMCG_SWAP_FAIL updates per 60-second run on a 176-CPU test system. Those writes bounce the line while memcg statistics paths load vmstats_percpu. Move cgwb_list into the existing alignment gap and cacheline-align vmstats_percpu. This separates the pointer from the event counters without increasing the size of struct mem_cgroup in the tested configuration. The blamed commit reduced median mremap throughput by 4.38% on the test system with one socket. The patched kernel brings the performance to within 0.5% of the parent which is within the observed boot-to-boot spread (up to 1.2%). Link: https://lore.kernel.org/20260817103835.2937733-1-usama.arif@linux.dev Fixes: ea928e9e18da ("mm/vmpressure: move v1 userspace eventfd code into memcontrol-v1.c") Signed-off-by: Usama Arif Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608131743.c6a7dda4-lkp@intel.com Tested-by: kernel test robot Link: http://lore.kernel.org/aoAABX59IzUXz/Rv@ly-workstation Acked-by: Shakeel Butt Acked-by: Michal Hocko Cc: David Hildenbrand Cc: Johannes Weiner Cc: Muchun Song Cc: Roman Gushchin Cc: Yi Lai Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3b06d0cc8154700d048a04aed926d55825a52759 Author: Hongfu Li Date: Fri Aug 7 09:35:55 2026 +0800 selftests/mm: fix read_file() return value check [ Upstream commit 4050b5b0b60c93160a816d68ea1eb9ae92739a73 ] read_file() returns 0 on open/read failures and never returns negative values. Existing < 0 error checks never trigger, so read failures are silently ignored. Check for zero return to detect read_file() failures. Also fix misleading error message in get_finfo(). The error string incorrectly references read_num when reading uevent files. Link: https://lore.kernel.org/20260807013555.36525-1-hongfu.li@linux.dev Fixes: e0c13f9761df ("khugepaged: add self test") Signed-off-by: Hongfu Li Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8625208f464ef1014ccd0e137d357667d252d682 Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:17 2026 +0100 selftests/mm: skip COW tmpfile cases when fallocate() is unsupported [ Upstream commit 4004c130c358b1561a55323b0e747f20f5133f7b ] Patch series "selftests/mm: Handle unsupported and transient test conditions", v3. Several MM selftests report failures when the test environment lacks an underlying prerequisite, such as fallocate() support, MADV_REMOVE, local page-cache semantics, or swap. This series converts those unsupported cases to SKIP while preserving failures for unexpected errors. It also allows migration tests to retry transient move_pages() failures. This patch (of 4): The tmpfile-backed COW cases allocate a one-page file with fallocate() before exercising private and shared mappings. When the filesystem backing tmpfile() does not implement fallocate(), setup fails with EOPNOTSUPP and no COW behavior is exercised. This occurs when the temporary directory resides on a filesystem with limited allocation support, such as NFSv3. Reporting a failure adds noise because the test prerequisite is absent rather than the COW implementation being broken. Report EOPNOTSUPP as a skip. Continue treating every other fallocate() error as a failure so unexpected setup regressions remain visible. Link: https://lore.kernel.org/20260727095225.372655-1-usama.anjum@arm.com Link: https://lore.kernel.org/20260727095225.372655-2-usama.anjum@arm.com Fixes: f8664f3c4a08 ("selftests/vm: cow: basic COW tests for non-anonymous pages") Signed-off-by: Muhammad Usama Anjum Tested-by: Sarthak Sharma Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f6ec40d1e4f174845576167b1983ecd53784d225 Author: Ze Tan Date: Tue Aug 11 14:00:46 2026 +0800 smb/client: preserve open info type across compound queries [ Upstream commit 9437f2113b60a5a8593aa4b41b6f6632f5cabcfd ] contains_posix_file_info describes the metadata stored in the fi/posix_fi union. GET_REPARSE and QUERY_WSL_EA do not update that union, so clearing the flag while processing those responses can make POSIX metadata look like FILE_ALL_INFORMATION. Set the flag when CREATE or a validated query response actually populates the union, and leave it unchanged for auxiliary compound operations. This also avoids changing the type when a query fails before copying any metadata. The issue can be reproduced against a Samba server with SMB3 UNIX extensions enabled: mount -t cifs /// /mnt/cifs \ -o vers=3.1.1,posix,reparse=nfs,actimeo=0 mkfifo /mnt/cifs/test-fifo umount /mnt/cifs mount -t cifs /// /mnt/cifs \ -o vers=3.1.1,posix,reparse=nfs,actimeo=0 stat -c '%F %s' /mnt/cifs/test-fifo Before this change, stat reports "fifo 1024" although the server-side EOF is zero. After this change, it reports "fifo 0". Fixes: 9df23801c83d ("smb311: failure to open files of length 1040 when mounting with SMB3.1.1 POSIX extensions") Signed-off-by: Ze Tan Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit a58270c1b3445371a6d61c2b1e07798fbc583ce8 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 a0fcbea79f034f49bdd44915f28938922023458d Author: Sai Krishna Date: Fri Aug 21 15:53:37 2026 +0530 octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init() [ Upstream commit 3b11a77f69980932c3924054d66e565c9a135747 ] rvu_mbox_init() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ng_rvu object, leaking the first allocation when the pointer was overwritten on the second call. Sharing one ng_rvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutex_init() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mbox_lock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvu_remove(). Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pci_enable_sriov() error paths. Fixes: e53ee4acb220 ("octeontx2-af: CN20k basic mbox operations and structures") Signed-off-by: Sai Krishna Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821102337.2989169-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e33c6bd049b532d2ec4916895ef07e538bed905 Author: Suman Ghosh Date: Fri Aug 21 16:25:35 2026 +0530 octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup [ Upstream commit b09a0503c755b6609fad59a84cc7f05b6843a03c ] af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is allocated during PF/VF probe. Representors and other non-AF_XDP paths leave the pointer NULL, but several call sites used test_bit() on it unconditionally. Switching to devlink eswitch mode creates representors and runs otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses when dereferencing the NULL bitmap. Add NULL checks before every af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init paths. Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Suman Ghosh Signed-off-by: Geetha sowjanya Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260821105536.2998765-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 281f9fda2e06d6c211bb365a5379ed2e05cc2e21 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 4f9827b314ee57cd99f86f8dbadcaf567112e2b2 Author: Long Li Date: Fri Aug 21 11:37:36 2026 -0700 net: mana: Cap MSI-X vectors to the device MSI-X table size [ Upstream commit 2c7493f980140a5c40eb4f98f97c557193a2c330 ] mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix and the CPU count, but never from the device MSI-X table. On a 1792 vCPU M-series VM that yields 1793 while the table has 1024 entries, and mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the end of the region mapped by msix_map_region(): BUG: unable to handle page fault for address: ff8e347f8b99800c RIP: 0010:msix_prepare_msi_desc+0x7a/0x90 RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000 Call Trace: __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 RAX is index 1024 * PCI_MSIX_ENTRY_SIZE, one entry past the table. msi_insert_desc() does range check the index, but only against the MSI domain hwsize, which matches the table only for devices on an MSI parent domain. With a global PCI/MSI domain hwsize is MSI_XA_DOMAIN_SIZE, so nothing bounds the request. Cap num_msix_usable with pci_msix_vec_count(). Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically") Signed-off-by: Long Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821183736.733296-1-longli@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 138b0054021fd7d57bc3eb68b3f4e2bcec037849 Author: Victor Nogueira Date: Fri Aug 21 13:40:31 2026 -0300 net/sched: act_ife: Only operate on Ethernet frames [ Upstream commit 5b483f7791b079bb97d411f1066652ff659207ff ] act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len. Fixes: 295a6e06d21e ("net/sched: act_ife: Change to use ife module") Reported-by: vega@nebusec.ai Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260821164031.32824-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a93b72eb2f5a852d3c1a2a9ad30e62044f322607 Author: Wei Fang Date: Fri Aug 21 14:41:40 2026 +0800 net: enetc: restore RX ring congestion mode for ENETC v4 [ Upstream commit fa1a8457b8581725ae237efefb2358eddd7e05c9 ] ENETC v4 has the same problem as ENETC v1: the RX BD ring congestion mode (CM) is only configured in the phylink .mac_link_up() callback, so it is cleared when enetc_reconfigure() rebuilds the RX BD rings at runtime (for example when enabling or disabling PTP RX hardware timestamping) without a link status change, and it is never restored. As a result, the MAC can no longer generate PAUSE frames on ingress congestion and flow control stops working. Fix it in the same way as ENETC v1. Track the desired CM state in the software flag ENETC_RXBDR_CM. Route enetc4_set_tx_pause() through the shared helper enetc_set_congestion_mode(), which sets or clears the flag according to tx_pause and updates the ENETC_RBMR_CM bit under si->gen_lock. When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores the CM bit accordingly, so flow control survives ring reconfiguration even when the link status does not change. Fixes: f5b9a1cde0a2 ("net: enetc: add PTP synchronization support for ENETC v4") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821064140.1315611-3-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18ca1be8426aac01b53744143580fdaf13110cb0 Author: Wei Fang Date: Mon Jul 20 09:43:10 2026 +0800 net: enetc: remove invalid code from enetc4_pl_mac_link_up() [ Upstream commit 59bb3d62489ce08d45dac2b7ec7b8f99a7b2040b ] When adding phylink MAC operations support to the NETC switch driver, Russell King pointed out several pieces of invalid logic in the .mac_link_up() implementation (see [1] and [2]): 1) Half-duplex backpressure is not supported by the kernel, Ethernet relies on packet dropping for congestion management. 2) phylink_autoneg_inband() is unnecessary, as RGMII in-band status is not supported. 3) TX and RX pause are disabled in half-duplex mode, so there is no need to override them in .mac_link_up(). The same invalid logic is also present in enetc4_pl_mac_link_up(), so remove the invalid code from it. Given enetc4_set_hd_flow_control() is removed, pf->caps.half_duplex has also become useless and should therefore be removed as well. Link: https://lore.kernel.org/imx/acEIQqI-_oyCym8O@shell.armlinux.org.uk/ # 1 Link: https://lore.kernel.org/imx/acEFwqmAvWls_9Ef@shell.armlinux.org.uk/ # 2 Signed-off-by: Wei Fang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260720014317.1059359-9-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa1a8457b858 ("net: enetc: restore RX ring congestion mode for ENETC v4") Signed-off-by: Sasha Levin commit 1039c56c4c99fbccadd261c71aa2fafe37f17401 Author: Wei Fang Date: Mon Jul 20 09:43:06 2026 +0800 net: enetc: improve MAFT entry management with bitmap tracking [ Upstream commit 6228fc9c2bbe224a376c77e309bcf90158e0595c ] Replace the counter-based MAFT entry tracking (num_mfe/mac_filter_num) with a bitmap (maft_eid_bitmap) stored in struct ntmp_user, which is a more appropriate place for NTMP resource management. The bitmap approach brings two improvements. First, the entry deletion in enetc4_pf_clear_maft_entries() now checks the return value of ntmp_maft_delete_entry() and only clears the corresponding bit on success, keeping hardware and software state in sync. Previously, the counter was reset unconditionally regardless of whether the hardware deletion actually succeeded. Second, entry allocation in enetc4_pf_add_maft_entries() uses ntmp_lookup_free_eid() to find available IDs dynamically, with an upfront capacity check via bitmap_weight() to avoid partial failures. The MAFT entry count is moved into ntmp_user.maft_num_entries and initialized once during enetc4_init_ntmp_user(). Helper functions enetc4_ntmp_bitmap_init() and enetc4_ntmp_bitmap_free() manage the bitmap lifetime. The debugfs show function is updated accordingly to iterate over set bits under rtnl_lock(). Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260720014317.1059359-5-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa1a8457b858 ("net: enetc: restore RX ring congestion mode for ENETC v4") Signed-off-by: Sasha Levin commit d25a4a481cfbe9e9d4f47248940606daa2eb2666 Author: Wei Fang Date: Mon Jul 20 09:43:05 2026 +0800 net: enetc: convert ndo_set_rx_mode() to ndo_set_rx_mode_async() [ Upstream commit debf0c7a34fab2c4c47fc257a97a145543b6d3aa ] The current ndo_set_rx_mode() is called under netif_addr_lock spinlock with BHs disabled, which prevents drivers from sleeping. To work around this limitation, the enetc driver uses a dedicated workqueue to defer MAC address list updates to a sleepable context. Since commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work") introduced the ndo_set_rx_mode_async() callback, drivers can now handle address list updates directly in a sleepable context. Therefore, convert the enetc driver to use ndo_set_rx_mode_async() and remove the dedicated workqueue and the deferred work item accordingly. Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260720014317.1059359-4-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa1a8457b858 ("net: enetc: restore RX ring congestion mode for ENETC v4") Signed-off-by: Sasha Levin commit c77effb3edb82226d1d0649e948fc59a94d4029a Author: Wei Fang Date: Mon Jul 20 09:43:04 2026 +0800 net: enetc: extract common helpers for MAC hash filter configuration [ Upstream commit 0ce10770963e7b4bf252fe0f0283326504bcbb36 ] The PSIUMHFR and PSIMMHFR registers in ENETC v4 have the same bit layout as in ENETC v1. The only difference between the two hardware generations is the register address offsets. Since the register functionality is identical, the MAC hash filter configuration code can be shared between the ENETC v1 and v4 drivers. Extract two new common helper functions, enetc_set_si_uc_hash_filter() and enetc_set_si_mc_hash_filter(), into enetc_pf_common.c. These helpers select the correct register offset based on the hardware revision via is_enetc_rev1(). Remove v1-specific enetc_clear_mac_ht_flt() and enetc_set_mac_ht_flt() from enetc_pf.c, and v4-specific enetc4_pf_set_si_uc_hash_filter() and enetc4_pf_set_si_mc_hash_filter() from enetc4_pf.c, as they are now superseded by the shared implementations. Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260720014317.1059359-3-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa1a8457b858 ("net: enetc: restore RX ring congestion mode for ENETC v4") Signed-off-by: Sasha Levin commit ccdc23869332a2e881d7c3c1df4a5e31ed1d9bf2 Author: Wei Fang Date: Mon Jul 20 09:43:03 2026 +0800 net: enetc: extract common helpers for MAC promiscuous mode setting [ Upstream commit 2557834ad0ff36fe3ec220bf1d7e6098265a326d ] The PSIPMMR (Port Station Interface Promiscuous MAC Mode Register) in ENETC v4 has the same bit layout as the PSIPMR register in ENETC v1: bit n controls unicast promiscuous mode for SI n, and bit (n + 16) controls multicast promiscuous mode for SI n. The only difference between the two hardware generations is the register address offset. Since the register functionality is identical, the MAC promiscuous mode setting code can be shared between ENETC v1 and v4 drivers. Rename ENETC_PSIPMR to ENETC_PSIPMMR in enetc_hw.h to match the actual register name used in the reference manual, and extract two new common helper functions, enetc_set_si_uc_promisc() and enetc_set_si_mc_promisc(), into enetc_pf_common.c. These helpers select the correct register offset based on the hardware revision via is_enetc_rev1(). Remove the v4-specific enetc4_pf_set_si_mac_promisc() function from enetc4_pf.c and the duplicate PSIPMMR_SI_MAC_UP/MP macro definitions from enetc4_hw.h, as they are now superseded by the shared code. Signed-off-by: Wei Fang Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260720014317.1059359-2-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fa1a8457b858 ("net: enetc: restore RX ring congestion mode for ENETC v4") Signed-off-by: Sasha Levin commit 1a20660772b67297b1595d1365014450104ae03d Author: Wei Fang Date: Fri Aug 21 14:41:39 2026 +0800 net: enetc: restore RX ring congestion mode after ring reconfiguration [ Upstream commit 9e94d8e14ae45e3fda8c0919f745db3ed3715433 ] The RX ring congestion mode (CM) is only configured in the phylink .mac_link_up() callback enetc_pl_mac_link_up(), which sets the ENETC_RBMR_CM bit when tx_pause is enabled. This callback runs only when the link status changes. However, enetc_reconfigure() tears down and re-creates the RX BD rings at runtime without any link status change, for example when attaching or detaching an XDP program, or when enabling/disabling PTP RX hardware timestamping. The rings are rebuilt from a cleared RBMR, so the CM bit is lost. Since the link status does not change, enetc_pl_mac_link_up() is not called again and the CM bit is never restored. As a result, the ENETC MAC can no longer generate PAUSE frames on ingress congestion, and flow control stops working after such a reconfiguration. Track the desired CM state in a software flag ENETC_RXBDR_CM. Set or clear this flag in enetc_pl_mac_link_up() according to tx_pause. When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores the ENETC_RBMR_CM bit accordingly, so flow control survives ring reconfiguration even when the link status does not change. RBMR is now written as a whole word from enetc_enable_rxbdr() rather than by read-modify-write from several call sites. Serialize the remaining RBMR read-modify-write paths, the congestion mode update and the RX VLAN offload update, with the new si->gen_lock so they cannot race each other. Fixes: 5093406c784f ("net: enetc: implement ring reconfiguration procedure for PTP RX timestamping") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821064140.1315611-2-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3235a8790a1a6818e02b62a6f4df2b0b08bdbbe Author: Naveen Mamindlapalli Date: Fri Aug 21 11:24:45 2026 +0530 octeontx2-af: Fix TL3/TL2 link config ENA clearing [ Upstream commit 9edf8d4876e8a2471e66f54d36208eaff2858392 ] Clear and restore the ENA bit for each TL3/TL2 link entry during SMQ flush instead of repeatedly using the same link index. Fixes: 019aba04f08c ("octeontx2-af: Modify SMQ flush sequence to drop packets") Signed-off-by: Nitin Shetty J Signed-off-by: Naveen Mamindlapalli Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821055445.2517568-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 200460a0793dc6af97d3b36d92ac245350ac26fc 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 ef42c9e922dfa806576d9d82867da2f3cd76b3ca Author: Anshumali Gaur Date: Thu Aug 20 14:06:34 2026 +0530 octeontx2-vf: fix workqueue and netdev race in probe/remove [ Upstream commit 3ba97ff4f873481d370bee7f7dfb87f8296af9be ] Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup. Fixes: cbc100aa2205 ("octeontx2-nicvf: add ndo_set_rx_mode support for multicast & promisc") Signed-off-by: Nitin Shetty J Signed-off-by: Anshumali Gaur Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820083634.1641740-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f460aa0211e97c011ef0cfe5016f8f2a2ed059b Author: Anshumali Gaur Date: Thu Aug 20 11:24:51 2026 +0530 octeontx2-af: fix out-of-bounds read setting MSI-X irq affinity [ Upstream commit 4d5df98369c5f45710b786499f8bd7ffc3196433 ] rvu_register_interrupts() walks every MSI-X vector and uses strstr() to match "Mbox" or "FLR" in irq_name before pinning those interrupts to CPU 0. irq_name is a per-vector NAME_SIZE buffer, but not every slot is populated before this loop runs. strstr() keeps scanning until it finds a NUL terminator, so an uninitialized slot can trigger a KASAN slab-out-of-bounds read at boot when debug options are enabled. Use strnstr() with NAME_SIZE to bound the search within each vector's name buffer. Fixes: 4e527f1e5c15 ("octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon") Signed-off-by: Anshumali Gaur Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260820055451.2642358-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fdf7358e2688f12eff41290bc45030b7aff0845e Author: Anshumali Gaur Date: Thu Aug 20 10:33:33 2026 +0530 octeontx2-af: fix NULL deref in NIX TM tree debugfs read path [ Upstream commit ec65631bd5ec251cdf67a4919fac7a3149a6e235 ] rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL. Fixes: b907194a5d5b ("octeontx2-af: Add debugfs support to dump NIX TM topology") Signed-off-by: Anshumali Gaur Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260820050333.2606095-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8d85498016a5bb56339734a14c276209fa65bafc 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 bf9387488d6394845076928c6ca5315ce5d84f54 Author: Stanislav Fomichev Date: Wed Aug 19 09:05:34 2026 -0700 xsk: honor XDP_TX_METADATA in zero-copy path [ Upstream commit a6e4b9a6deb9362ef7a0706c70d674e92fe1411a ] The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change. Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Reviewed-by: Alexander Lobakin Signed-off-by: Stanislav Fomichev Reviewed-by: Maciej Fijalkowski Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260819160535.1472459-3-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e00ea9e97a390856a64dab09cfff7db5c46f24e Author: Stanislav Fomichev Date: Wed Aug 19 09:05:33 2026 -0700 xsk: align TX metadata layout across ABIs [ Upstream commit bd7d30bd1d3856d8354b5acef947d68ad1faf886 ] Add explicit padding before launch_time so xsk_tx_metadata has the same layout on 32-bit and 64-bit systems. On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old native 32-bit layout put launch_time at offset 12 and had a natural size of 20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already rejected because the length must be a multiple of eight, so the straightforward use of the interface was broken on those ABIs. Userspace could still register a padded length of 24 bytes, though; mixing the old and new layouts then silently reads launch_time from the wrong offset and misprograms packet launch times. This intentionally replaces that incompatible layout because the affected architectures are unlikely to have any notable users. (x86_64 and arm64 have the most users and are _not_ affected) Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Reviewed-by: Simon Horman Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2eafcf310f4e0ad4f387881db01116bbe3cc0b39 Author: Radek Podgorny Date: Mon Aug 24 13:00:20 2026 +0200 Bluetooth: do not leak an hci_conn when a second LE connect is rejected [ Upstream commit 7e1e4047200fd7519f9bdfe8a001437715e618b4 ] create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed. The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device. Fixes: c9f73a2178c1 ("Bluetooth: hci_conn: Fix hci_connect_le_sync") Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3988cbb1be501dbff909a2ee024670e3c955a66d 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 22d419db7f9a01bea22cfcf66774d2b2fd4bb354 Author: Ali Ahmet Memis Date: Fri Aug 14 18:28:48 2026 +0000 Bluetooth: btnxpuart: Validate the FW dump header length [ Upstream commit 060fa7592bdc043a93b6b7870f5b8551206d315d ] nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated. Fixes: 998e447f443f ("Bluetooth: btnxpuart: Add support for HCI coredump feature") Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 94a71da6d6b375b6616060f5c2aab5bb20f71e1d Author: Pauli Virtanen Date: Sun Aug 16 11:59:01 2026 +0300 Bluetooth: hci_sync: add conditional locking annotations [ Upstream commit 5b9b68abb5fa548478e20ee38a0ef5c18e9cf4b7 ] Add context analysis annotations to functions doing conditional locking, to suppress analysis warnings. Fixes: cdc36db204ff ("Bluetooth: hci_sync: Fix advertising data UAFs") Tested-by: Nathan Chancellor # build Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7b80d2701a68456c536f82e577dbed2f60ccb82b Author: Chris Lu Date: Mon Aug 17 17:53:32 2026 +0800 Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path [ Upstream commit fa0ad2d277c7adead61d1c22411c55cea6990c2a ] btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures. 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 d84bc309288b20494cecabb68008f86d7263e2ee 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 956b5a979b0df10b0175d9ad0134e6bb2e97964f Author: Ismail Tarim Date: Sat Aug 15 14:56:24 2026 +0300 Bluetooth: btmtk: Do not discard the subsystem reset timeout [ Upstream commit 21b50c24843b51f88ac4316dd470d2803da0c42f ] When the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs "Reset timeout" and keeps the error in err, but err is then overwritten by the return value of the following btmtk_usb_id_get() call, so the timeout is never reported to the caller. Commit 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") discarded the return value of the chip id read, so the function returned the timeout error as intended. Commit 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") started assigning err at that call and silently dropped it. Keep the timeout in a separate variable and return it, restoring the original behaviour without changing the control flow. Fixes: 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 820e64cb52dbf9f8fdad13009e4ab940a90ee8b9 Author: Ismail Tarim Date: Sat Aug 15 14:56:23 2026 +0300 Bluetooth: btmtk: Do not report success when subsys reset fails [ Upstream commit 59c3ee19ca88210bfc0e22ce59218091cb1a3c48 ] btmtk_usb_subsys_reset() validates the subsystem reset by reading the chip id back. When that read succeeds at the bus level but yields an id of zero, the reset has demonstrably not taken effect: the function logs "Can't get device id, subsys reset fail." and then returns the return value of btmtk_usb_id_get(), which in that case is zero, i.e. success. btusb_mtk_reset() returns that value unchanged, so its caller cannot tell a completed reset from a failed one. Return -ENODEV when the chip id reads back as zero, leaving the existing MT6639 exemption intact. Observed on an MT7902 [13d3:3579]. The path can be reached on demand by asking the controller for a coredump, since btmtk requests a reset once the dump completes: # echo 1 > /sys/class/bluetooth/hci0/device/coredump Bluetooth: hci0: Mediatek coredump end Bluetooth: hci0: Can't get device id, subsys reset fail. usb 3-10: reset high-speed USB device number 5 using xhci_hcd usb 3-10: device descriptor read/64, error -110 usb usb3-port10: attempt power cycle usb usb3-port10: unable to enumerate USB device The same sequence occurs unprompted when the controller firmware asserts on its own. Note that this corrects the error reporting only; it does not by itself make the controller recoverable in the case above. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 32a7bc6e93be36b37fe61f351d312d358195bd61 Author: Pauli Virtanen Date: Sat Aug 8 12:08:45 2026 +0300 Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan [ Upstream commit 66d6ef18548ae6d7dd452b84115fc82c0a73a4ea ] For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking. Fixes: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ee2135a14fb2a3e176149122764d293f0796b1eb Author: Pavel Shpakovskiy Date: Sat Aug 8 19:31:11 2026 +0300 Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference [ Upstream commit 59eecbe2f2f38d8f3e1104bd11da97f9a2c58998 ] 'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e556850e ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c47339e169bf4a0a4cfabb91351471f67744c2bc Author: Pauli Virtanen Date: Sun Aug 9 01:06:05 2026 +0300 Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN [ Upstream commit d4bfa78fd67929b62b02013c107973e0c5b7aa9a ] New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case. Fixes: 2ff1a41a912d ("Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()") Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9265e754091c2d27ea29 Signed-off-by: Pauli Virtanen Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Tested-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f49321c85785178214fd67f2e9b4b73d6363783b Author: Pauli Virtanen Date: Sun Aug 9 20:42:41 2026 +0300 Bluetooth: L2CAP: access chan->conn safely in get/setsockopt [ Upstream commit ca2c4c26498643f421d35ffe258fafbd3ed461c3 ] Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev. Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Reported-by: syzbot+b106284c2a0b7bc80cf9@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=b106284c2a0b7bc80cf9 Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a34fb2fa48fbf5afc35056f322b8617b97a77d06 Author: Seongjae Jeong Date: Mon Aug 24 02:32:31 2026 +0000 f2fs: use adjusted write range after f2fs_write_checks() [ Upstream commit 3b2c5d35cf4398edf47c4a3ad076838654a30015 ] generic_write_checks() in f2fs_write_checks() can adjust iocb->ki_pos for append writes and truncate the iterator to limit the number of bytes to write. In f2fs_file_write_iter(), the pinned-file overwrite check currently uses the position and count saved before f2fs_write_checks(), so it can check a range different from the actual write range. The forced buffered I/O cleanup also uses orig_pos saved before f2fs_write_checks(). For O_APPEND writes, this can make the cleanup flush and invalidate the wrong page cache range. Move the pinned-file overwrite check after f2fs_write_checks() and use the adjusted iocb->ki_pos and iov_iter_count(from). Also save the adjusted write position and use it for the forced buffered I/O cleanup. Fixes: 3fdd89b452c2 ("f2fs: prevent writing without fallocate() for pinned files") Fixes: 92318f20d703 ("f2fs: preserve direct write semantics when buffering is forced") Signed-off-by: Seongjae Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2f10bc3ff24c91657887901c3235b803e5055f2b Author: Vladimir Murzin Date: Wed Aug 19 15:48:59 2026 +0100 arm64: process: Fix context switching MTE store-only tag check [ Upstream commit b8f070ac3167595069feb1f794c127b805115645 ] SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK Fixes: 4d51ff5bba00 ("arm64/kernel: Support store-only mte tag check") Signed-off-by: Vladimir Murzin Reviewed-by: Catalin Marinas Reviewed-by: Yeoreum Yun Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ae0cfa977298229c6c7489cf92e9102294706535 Author: Wei-Lin Chang Date: Fri Aug 14 23:24:57 2026 +0100 arm64: ptdump: Make note_page_flush() range aware [ Upstream commit 902caade3cfd60f99bf71b355e7c86344bd831e5 ] note_page_flush() calls note_page() with addr == 0 and level == -1 to dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around) renders a huge region with enormous size for address spaces with IA bits < 64. For example the stage-2 page tables and the EFI runtime page table. More importantly, the last region of the address space and everything after the address space up to 1 << 64 are merged into one row of output. If the last region within the address space is valid, it will appear to remain valid up to 1 << 64 with the same attributes. Currently only the EFI runtime ptdump is affected by this, but KVM will soon fix its stage-2 ptdump by using note_page_flush(). Here is an example of an EFI runtime ptdump (last row): 0x0000008000000000-0x0000000000000000 17179868672G PGD With this patch: 0x0000008000000000-0x0001000000000000 261632G PGD To fix this, cache the end address of a ptdump in ptdump_pg_state so note_page_flush() can call the final note_page() with the correct end address. Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") Signed-off-by: Wei-Lin Chang Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8f9a725d89711ad027f6b7183586ef91528f106d Author: Bernd Schubert Date: Fri Aug 21 18:19:09 2026 +0200 fuse: Fix the condition to enable over-io-uring [ Upstream commit 1f59015e958174e89be58cc8db16d70a60d17255 ] The existing condition in fuse_uring_cmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORING_OP_URING_CMD if the connection/channel didn't get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bg_lock and queue->lock). The change itself is trivial, but brings behavior change, FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers to accept any IORING_OP_URING_CMD. Libfuse does that and the only non-libfuse implementation I found (fractal-fuse) also does it. Qemu patches for fuse-io-uring are not merged yet, as far as I know. Moved up is the smp_load_acquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSE_INIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN. Also fixed is a stale comment that explains the handling of the FUSE_OVER_IO_URING flag in early RFC versions. If there should be a report from any library or application we probably need to revert this commit. Fixes: 3393ff964e0f ("fuse: block request allocation until io-uring init is complete") Signed-off-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit f940f3d3fd0bbd0d9d92a1457ecfc9cb48a8cf15 Author: Joanne Koong Date: Thu Jul 16 11:31:43 2026 -0700 fuse: use release/acquire for fch->initialized [ Upstream commit 4ef7c8cc9894fccc7aa5fdaf6b39faa45c58c23e ] fuse_chan_set_initialized() sets values for the connection state and then sets fch->initialized to true, but lockless readers read fch->initialized and if true, go to read the connection state values, without using any barriers. There are a few instances where this happens (fuse_uring_cmd() before dispatching register / commit-and-fetch cmds, fuse_dev_do_wriite() for handling notify retrieves, etc). To make this as simple as possible, use release/acquire semantics for writing/reading fch->initialized. Add the missing read barriers. This is not marked for stable as these are not realistically reachable on a well-behaved server, and buggy/malicious servers who trigger this path fail benignly rather than crash or deadlock the kernel. Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: 1f59015e9581 ("fuse: Fix the condition to enable over-io-uring") Signed-off-by: Sasha Levin commit 833963069adf86dcbdffd4e7d7b3171f95070b77 Author: Baokun Li Date: Wed Aug 19 17:07:28 2026 +0800 fuse: invalidate the correct range after O_APPEND direct write [ Upstream commit 26d7e1f5c407b5859122b5cd47d7ebbf4b4c1cd2 ] fuse_direct_write_iter() captures pos before generic_write_checks(), which moves ki_pos to EOF for O_APPEND writes: fuse_direct_write_iter() { pos = iocb->ki_pos; /* 0 (user-supplied) */ generic_write_checks(); /* ki_pos -> EOF */ fuse_direct_io(); /* writes at EOF, correct */ invalidate(pos, pos + res); /* [0, res) -- wrong */ } The post-write invalidation targets a stale range instead of the actual written range at EOF. This can cause data inconsistency when the file size is not page-aligned. The tail page straddling EOF has a valid portion before EOF that concurrent readers can fault back in during the DIO write window: Tail page (file size X not page-aligned): page_start X (EOF) page_end |--- valid data ----|-- stale --| CPU0 (O_APPEND DIO writer) CPU1 (buffered reader) -------------------------- ---------------------- invalidate [X, X+len) tail page evicted FUSE_WRITE in flight ... read [page_start, X) tail page re-faulted [X, page_end) = stale FUSE_WRITE completes i_size = X + len invalidate [0, len) <- WRONG tail page still cached read [X, X+len) hits stale tail page returns old data Fix by reading pos back from iocb->ki_pos after generic_write_checks(), as generic_file_direct_write() does. Also fix a typo in the comment ("may have" -> "may have competed"). Fixes: 2b0408d0284f ("fuse: invalidate page cache after DIO and async DIO writes") Signed-off-by: Baokun Li Reviewed-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit faef603939f26070dc9054389f1dfe43e82914fe Author: Geert Uytterhoeven Date: Thu Aug 20 12:00:23 2026 +0200 erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic [ Upstream commit ab74edaeb1ae7c7194e79007e6afdfe788111a3f ] When NR_CPUS is less than 16, or when SMP is disabled, the default value of 16 is invalid. While actual configuration picks up a sensible and valid default (NR_CPUS or 1), "make savedefconfig" will still write a line like CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1 to the defconfig file, even if that matches the sensible default. Avoid needlessly enlarging the defconfig files, and reduce churn for updating them, by specifying valid defaults depending on SMP and NR_CPUS. While at it, make the prompt depend on SMP, as there is no point in asking the user about the maximum number of decompression streams if there is only one valid answer. Fixes: c9b47e6b23114e93 ("erofs: cap LZMA stream pool size") Signed-off-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 31d299e7d55397683e1b3171d93e664dd63636a4 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 4c19c302cc577bd6b466f6d8e97971777392c2fa Author: Michael Kelley Date: Wed Aug 12 07:52:23 2026 -0700 Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition [ Upstream commit cee0d90bceae1dee3bcc70f8d6b2ceb5b87deb42 ] The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260721154943.A09BD1F00A3D@smtp.kernel.org/ Fixes: 7e279d78664aa ("Drivers: hv: vmbus: skip VMBus initialization if Linux is root") Signed-off-by: Michael Kelley Reviewed-by: Easwar Hariharan Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 55d87e888ca1fbddea01631975d4191f7e646289 Author: Giuseppe Piscitelli Date: Thu Aug 20 17:45:03 2026 +0200 net/sched: sch_cake: fix autorate reconfiguration throttling [ Upstream commit 7cbfb180945ce529608e4d4e24a6d483699fab1e ] CAKE's autorate-ingress path intends to limit shaper reconfiguration to once per 250 ms, but last_reconfig_time is only checked and never updated. Since the field stays zero, every qualifying capacity-estimate window can call cake_reconfigure(), causing avoidable rate churn and scheduler work under bursty traffic. Store the current timestamp when autorate actually reconfigures the qdisc so the guard enforces the intended interval. Fixes: 7298de9cd725 ("sch_cake: Add ingress mode") Signed-off-by: Giuseppe Piscitelli Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260820154503.892214-1-ooonea@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4384d152e10df1588044a5aff2b59a45285a6e74 Author: Jian Shen Date: Thu Aug 20 20:43:46 2026 +0800 net: hibmcge: fix page_pool DMA direction mismatch [ Upstream commit 11efd7963dac9b036a7c9a435ab0e621188910e8 ] The driver memsets the RX buffer page head to zero before submitting it to hardware, then calls dma_sync_single_for_device() with DMA_TO_DEVICE. This sync direction does not match the pool dma_dir which is DMA_FROM_DEVICE, violating the DMA API contract that the sync direction must match the mapping direction. On swiotlb platforms the mismatch can cause incorrect bounce-buffer behaviour, and CONFIG_DMA_API_DEBUG emits a warning. Switch the page_pool dma_dir to DMA_BIDIRECTIONAL so that the CPU-to-device memset sync becomes legal. Fixes: c30595917585 ("net: hibmcge: add support for pagepool on rx") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260820124346.4097115-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e5b1f6ee74aaab9e4edf3566ee6cd819982ac42 Author: Eric Dumazet Date: Thu Aug 20 08:06:25 2026 -0400 net_sched: sch_fq: fix pacing delay underflow with pacing offload [ Upstream commit 137b8ae233cabe7fc77cce86f5ba33bf1b369e26 ] When pacing offload is enabled (q->offload_horizon > 0), FQ can dequeue packets early (now < f->time_next_packet). In this case, the drift calculation (now - f->time_next_packet) underflows to a large unsigned value. min(len/2, now - f->time_next_packet) then evaluates to len/2, incorrectly halving the pacing delay for the next packet. Fix this by only applying drift compensation if now > f->time_next_packet. This bug was triggered when flow_max_rate was set on the qdisc or for non EDT packets (packets with a zero skb->tstamp). Fixes: f26080d47007 ("net_sched: sch_fq: add the ability to offload pacing") Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/netdev/CANn89iK6O7ujR9zCJzd04MNLQoDi3mA+HWsR-hgQWYzLS3gZfw@mail.gmail.com/ Signed-off-by: Eric Dumazet Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260820120706.1995449-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72895242ee741a68e564c922ebe8458c12109fde Author: Rong Zhang Date: Fri Aug 21 01:41:25 2026 +0800 net: page_pool: Remove zone/policy GFP flags when allocating XArray entries [ Upstream commit 039f248a6cc1f4dec895c001de2c600842022e58 ] Net drivers request GFP flags according to both the current context and the device constraints, but the XArray entry itself is by no mean used by the device. Passing though device constraints to XArray allocation is a bug and will be warned and fixed up by slab, e.g.: Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code! CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy) Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025 Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib] Call Trace: dump_stack_lvl+0x6e/0x90 kmalloc_fix_flags+0x4d/0x6a refill_objects+0x10a/0x330 __pcs_replace_empty_main+0x292/0x5c0 kmem_cache_alloc_lru_noprof+0x4c2/0x680 ? __xas_nomem+0x3a/0x120 __xas_nomem+0x3a/0x120 __xa_alloc+0xd4/0x190 page_pool_dma_map+0xef/0x400 __page_pool_alloc_netmems_slow+0xed/0x480 ? lock_release+0x280/0x490 page_pool_alloc_frag_netmem+0xe0/0x3a0 page_pool_alloc_frag+0xe/0x20 mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76] mt76_dma_rx_reset+0x1cf/0x230 [mt76] mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib] mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib] mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib] mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib] mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib] ? process_one_work+0x20e/0x600 process_one_work+0x230/0x600 ? process_one_work+0x256/0x600 worker_thread+0x1ec/0x3c0 ? rescuer_thread+0x610/0x610 kthread+0xf2/0x130 ? kthread_affine_node+0x140/0x140 ret_from_fork+0x2a5/0x380 ? kthread_affine_node+0x140/0x140 ret_from_fork_asm+0x11/0x20 Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32. Fix it by removing zone/policy GFP flags when allocating XArray entries. This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()"). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Rong Zhang Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d63522f9e5900b6ea8a82665f7ea94dba4bb2b2 Author: Jiawen Wu Date: Tue Aug 18 15:47:21 2026 +0800 net: libwx: fix concurrent bitmap overwrite in PTP setup [ Upstream commit f05516dd7b865666ea7d67e90d0edb588ae9ad18 ] In wx_ptp_set_timestamp_mode(), the driver copies the global `wx->flags` bitmap to a local variable, modifies the PTP-related bits, and then writes the entire bitmap back using memcpy(). This Read-Copy-Update pattern is unsafe and introduces a critical race condition. Other asynchronous contexts (such as Tx timeout routines or GPIO IRQ handlers) update individual bits in `wx->flags` concurrently using atomic bitops like set_bit() or clear_bit(). The memcpy() write-back can silently overwrite and drop these concurrent changes, potentially causing the driver to miss critical module reset or PCIe recovery requests. Fix this by removing the local bitmap copy. Instead, evaluate the intended PTP flag states locally and apply them directly to `wx->flags` using atomic set_bit() and clear_bit() operations only after the hardware is successfully configured. Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Signed-off-by: Jiawen Wu Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/6C7EC12D69217315+20260818074721.45536-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6dfa6dc37d746682471b17cbd1f81778dfd1ffa Author: Jiawen Wu Date: Tue Aug 18 10:30:26 2026 +0800 net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown [ Upstream commit 7bf29145d7a9564162c6b18f8d23760e141e2d15 ] In txgbe_misc_irq_thread_fn(), the driver unmasks the miscellaneous interrupt at the end of the handler using TXGBE_INTR_MISC(wx) (which resolves to BIT(wx->num_q_vectors)). While this is correct for MSI-X mode, it is incorrect for legacy INTx or single MSI modes. Due to hardware behavior, the WX_PX_MISC_IVAR register is completely ignored by the hardware when MSI-X is disabled. In non-MSI-X mode, the hardware forcibly merges all interrupt causes (both Queue and MISC) into a single bit: BIT(0) of the interrupt register. Unconditionally unmasking TXGBE_INTR_MISC(wx) (e.g., BIT(1)) in non-MSI-X mode means the actual MISC interrupt bit (BIT(0)) is not unmasked promptly at the end of the MISC thread. Instead, it remains masked until NAPI completes its polling and unmasks the shared BIT(0). This delays the assertion of subsequent MISC interrupts, preventing timely handling of events like link state changes. Fix this by explicitly checking `pdev->msix_enabled` and falling back to BIT(0) as the interrupt mask for the MISC cause when MSI-X is disabled. Additionally, unconditionally unmasking the interrupt at the end of the thread introduces a race condition during device teardown. Guarding the wx_intr_enable() call with a check for the WX_STATE_DOWN bit, to prevent re-arming the interrupt during device shutdown. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/56A53978B83EEDE9+20260818023026.6631-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 648d196ccc03ae3b04402ae71ffa44959a85e88f Author: Daniel Machon Date: Mon Aug 17 17:41:59 2026 +0200 net: sparx5: fix sleep in atomic context in MAC table access [ Upstream commit b62793a7baeea9cf20209c9fd2e333311aaf3b8d ] sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context. Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain. Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c Fixes: d6fce5141929 ("net: sparx5: add switching support") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-2-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 905754787762481e8cdc527b6800452c9ac5a449 Author: Daniel Machon Date: Mon Aug 17 17:41:58 2026 +0200 net: microchip: vcap: use port number instead of netdev name for debugfs [ Upstream commit b7adcc56fd3db4f5ddaf8c01069d26136d61e5c8 ] sparx5_vcap_init() runs before sparx5_register_netdevs() in probe, and its debugfs setup calls vcap_port_debugfs() for every port using netdev_name(ndev) as the debugfs file name. At that point the netdevs have only been allocated, not registered, so dev->name still holds the "eth%d" template and netdev_name() returns "(unnamed net_device)". Every port tries to create the same file under vcaps/, producing a flood of warnings at boot: debugfs: '(unnamed net_device)' already exists in 'vcaps' debugfs: '(unnamed net_device)' already exists in 'vcaps' ... Add vcap_port_debugfs_portno(), a variant of vcap_port_debugfs() that takes the port's stable hardware port number and uses "p%u" as the debugfs file name instead of netdev_name(ndev). This makes the file name independent of registration order; the file still stores and later dereferences the netdev itself, same as before. sparx5 already reports the same "p%d" string via ndo_get_phys_port_name(), so the debugfs name now matches that. Only sparx5 (and lan969x, which shares this code) is switched to the new function. lan966x keeps calling vcap_port_debugfs() unchanged, so this fix does not rename any of its existing debugfs files. Fixes: b8909aad5b8d ("net: sparx5: move netdev and notifier block registration to probe") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-1-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18c68c8f3d3ff0a4def1391021b439c4333a6c71 Author: Jamal Hadi Salim Date: Wed Aug 19 10:37:33 2026 -0400 net/sched: account classifier filter allocations to memcg [ Upstream commit 1beb81947eb486716af80db7a584f9e9fef7e003 ] Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging. Fixes: 0da974f4f303 ("[NET]: Conversions from kmalloc+memset to k(z|c)alloc.") Reported-by: vega@nebusec.ai Signed-off-by: Jamal Hadi Salim Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260819143733.57538-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 08988d1941e180f0ad30d91233cb64f3418ba23c Author: Wei Fang Date: Fri Aug 21 11:24:49 2026 +0800 ptp: netc: fix period truncation and potential divide-by-zero in PEROUT [ Upstream commit 777dbc9914b2f003f1d44af80c7a4a395c5961b2 ] The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Signed-off-by: Wei Fang Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260821032449.1235065-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98b4998733553b41c2a6a3072a1b3e1b20555bfa Author: Thomas Walsh Date: Thu Aug 20 18:05:44 2026 -0400 bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check [ Upstream commit a70859cf31214e546cb73da7142f190138dae9ab ] In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to enable PCIe TPH when setting up interrupts. If the NIC hardware or firmware capabilities do not support queue ops, attempting to enable TPH during bnxt_request_irq() is unnecessary. As a result a flood of "RX queue restart failed: err=-95" messages is seen upon boot. Older NICs (pre-Thor / BCM57414) do not support TPH or queue management. TPH requires queue management to restart the queue. NICs that support queue management (with updated FW) all support TPH. Gate the call to pcie_enable_tph() and setting of bp->tph_mode behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized on devices capable of supporting queue ops. This prevents a guaranteed -EOPNOTSUPP error from occurring due to NULL operations. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Suggested-by: Michal Schmidt Signed-off-by: Thomas Walsh Reviewed-by: Michael Chan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260820220544.1240879-1-thwalsh@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b17907ef665bc76a495a8f909f74656d3f32b7a2 Author: Guenter Roeck Date: Thu Aug 20 21:45:12 2026 -0700 bnxt_en: Fix call to hardware monitoring event handler [ Upstream commit 622d698df4239fef3e0eb51fe59f4198f957f28a ] The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem. Fixes: a19b4801457b0 ("bnxt_en: Event handler for Thermal event") Signed-off-by: Guenter Roeck Reviewed-by: Kalesh AP Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260821044512.663941-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1cd4b0a184db658d53ffd24e997ab397d9a07b9d Author: Julian Braha Date: Fri Aug 21 18:54:10 2026 +0100 ASoC: fix unmet dependencies on PPC_BESTCOMM and SND_SOC_AC97_BUS [ Upstream commit 72cc574aa3791aa4f05d247b4e884cdbd135819a ] SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA both select SND_SOC_MPC5200_AC97 without ensuring its dependency on PPC_BESTCOMM is met. This causes unmet dependencies such as: WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97 Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_BESTCOMM [=n] Selected by [m]: - SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y] In v1, Rosen pointed out that the import of "mpc5200_dma.h" is actually unnecessary, and Arnd suggested that the 'select' of SND_SOC_MPC5200_AC97 be changed to 'depends on'. This resolves all 3 unmet dependencies. These unmet dependency bugs were detected by kconfirm, a static analysis tool for Kconfig. Fixes: a9262c4fd404 ("ASoC: Support for AC97 on Phytec pmc030 base board.") Fixes: 6ffee43ecf8b ("ASoC: Fabric bindings for STAC9766 on the Efika") Suggested-by: Arnd Bergmann Suggested-by: Rosen Penev Signed-off-by: Julian Braha Link: https://patch.msgid.link/20260821175410.179631-1-julianbraha@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5d542be0c4921cfcc3f5873f37606f22bbca90b8 Author: Cosmo Chou Date: Sat Jul 18 03:37:05 2026 +0800 rtc: pcf85363: Add error checking to regmap calls in probe() [ Upstream commit 78acddfde75177a27000f076e3e828743e38877e ] The probe() function ignores errors returned by regmap operations. If an I2C transport error occurs (e.g., -ENXIO), the driver continues probing and may register a non-functional RTC device. Propagate errors from all unchecked regmap calls in probe() using dev_err_probe(). Fixes: fd9a6a13949a ("rtc: pcf85363: add support for the quartz-load-femtofarads property") Signed-off-by: Cosmo Chou Link: https://lore.kernel.org/linux-rtc/20260716125142.1801599-1-chou.cosmo@gmail.com/ Link: https://patch.msgid.link/20260717193705.2003175-1-chou.cosmo@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit bbc975cfb07a146843fde1126c43441e76177539 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 a973622da0c62c34043ddbbf382cd761b03e5136 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 f31f3c042e024aef437cda42f0424ae8d4594b6c Author: Jérémy Jean Date: Thu Aug 20 20:53:29 2026 +0000 NFSv4.1: zero referring call lists before decoding [ Upstream commit 8fa4804fe62ca4155a2d8fc2789d630376cbf2fc ] decode_cb_sequence_args() allocates csa_rclists with kmalloc_objs(), so each referring_call_list starts uninitialized. decode_rc_list() assigns rcl_refcalls only when rcl_nrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4_callback_sequence() later passes stale slab contents to kfree(). Allocate csa_rclists with kzalloc_objs() so every rcl_refcalls member is NULL from the beginning, including valid empty referring call lists. Fixes: 4aece6a19cf7 ("nfs41: cb_sequence xdr implementation") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ecc8bac11a101e5f6989a14b92e17b51f9761630 Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:56 2026 +0300 vxlan: fix reading neigh ha [ Upstream commit b824059a673b2283e78c7aae2c7d257aad7f0e1d ] Currently arp/neigh_reduce read neigh ha directly which can lead to partial reads while the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address similar to route_shortcircuit which already does the right thing. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260818150756.890025-3-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 291c9e137b7c74e8a512cded4845352da4c4adda Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:55 2026 +0300 net: bridge: arp/nd proxy: fix reading neigh ha [ Upstream commit 57549ab9079122991dfa0f8248ca00e101e8e69b ] Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address. Fixes: 057658cb33fb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports") Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260818150756.890025-2-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ff429dd6725fa6c1e17a4ed0be8ab675f67a98b 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 e25a602c45c76a7130878db72bcf6f76df04bf85 Author: Mahanta Jambigi Date: Tue Aug 18 09:31:07 2026 +0200 net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition [ Upstream commit 036322025d6e440cb75fc6fecbba9a16b271a2ae ] When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: if (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { lgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; smc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); ... } A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op. Fixes: b4ba4652b3f8 ("net/smc: extend LLC layer for SMC-Rv2") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073107.466506-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2479738ba765857c32654bd4cec958cf365af45 Author: Li, Yifan Date: Fri Aug 14 11:10:08 2026 +0800 powercap: intel_rapl: Sign-extend the PMU delta on counter wraparound [ Upstream commit a8b842366f8ff469fe0fc700ba53770ded847ea9 ] The RAPL PMU misreports energy when the hardware energy counter overflows and wraps back to zero. perf event counts are defined to increase monotonically, but a single wraparound makes the PMU event count jump backwards by nearly the full counter range, and consumers that take the difference of two reads in unsigned arithmetic then underflow and report an absurd value. On a Panther Lake system (energy unit 61.035 uJ, counter range 262144 J) the package counter wraps every ~2.9 hours at 25 W, and turbostat prints one bogus sample per wraparound, per domain: PkgTmp PkgWatt CorWatt GFXWatt RAMWatt SysWatt 44 24.97 16.30 3.90 1.87 2145386370.35 43 2145240612.10 16.13 4.02 1.91 40.46 The RAPL energy counters are 32-bit wide on every register interface: MSR, MMIO and TPMI all describe ENERGY_COUNTER with a GENMASK(31, 0) mask. rapl_read_data_raw() applies that mask, so event_read_counter() returns the counter zero-extended in a u64. rapl_event_update() then computes delta = new_raw_count - prev_raw_count; without reducing the result modulo 2^32. While the counter does not wrap this is correct, but once the hardware counter wraps, new_raw_count < prev_raw_count and delta becomes (true_delta - 2^32), a large negative value. Declaring delta as s64 only makes that value representable; it does not correct it. That bogus delta is scaled and added to event->count, which is where the backwards jump comes from. Fix it the way arch/x86/events/rapl.c has done since the RAPL PMU was first introduced: shift both values up so that the 64-bit subtraction reduces modulo 2^32, then shift the difference back down with an arithmetic shift to sign-extend it. This is correct as long as at most one wraparound happens between two updates, which the existing overflow hrtimer already guarantees: its period is half of the counter range at the 200 W reference used in rapl_package_add_pmu_locked(). The problem has been present since the powercap RAPL PMU was added, but only affected TPMI RAPL until commit 748d6ba43afd ("powercap: intel_rapl: Enable MSR-based RAPL PMU support") routed MSR RAPL through the same PMU, which exposed it on client platforms such as Panther Lake. Fixes: 575024a8aa7c ("powercap: intel_rapl: Introduce APIs for PMU support") Reported-by: Jyoti, Anand B Signed-off-by: Li, Yifan Signed-off-by: Gao Jianfeng Tested-by: Jyoti, Anand B Acked-by: Srinivas Pandruvada Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://patch.msgid.link/20260814031008.750911-1-yifan2.li@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d98b92f3d57976ae185238946ec5ea0be32195aa Author: Jamal Hadi Salim Date: Tue Aug 18 05:59:27 2026 -0400 net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue [ Upstream commit 4c660ee8c809637909f4f7eb1017f7b9401c75c4 ] gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM. Fixes: a3eb95f891d6 ("net_sched: gred: add TCA_GRED_LIMIT attribute") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260818095927.15901-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc4e67c9399c74f40adff36b1d046fe9f04e2faa Author: Mina Almasry Date: Fri Aug 14 19:13:31 2026 +0000 net: tcp: block mixing readable and unreadable frags [ Upstream commit d9c56501c72fdac937e8b770f31655c46832f1a5 ] Protect tcp_sendmsg_locked() from mistakenly mixing readable and unreadable page fragments in the same SKB. Check that the devmem binding matches the existing SKB's readability. If a mismatch is detected, avoid collapsing and create a new segment. Fixes: bd61848900bff ("net: devmem: Implement TX path") Suggested-by: Eric Dumazet Cc: Pavel Begunkov Cc: Stanislav Fomichev Cc: Bobby Eshleman Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260814191336.187243-2-almasrymina@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7109bb63667a53e4542ad845476f97d0c8b28a61 Author: Eric Dumazet Date: Tue Aug 18 15:12:13 2026 +0000 inetpeer: randomize RB-tree node comparison using SipHash [ Upstream commit 2ee66e9487172fcd189bc52a767c30dad7141c09 ] The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk. Fixes: b145425f269a ("inetpeer: remove AVL implementation in favor of RB tree") Reported-by: Michael Blunt Suggested-by: Michael Blunt Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260818151213.3953963-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a674afaae4136c71943aa3e35d433676fd40e8f Author: Eric Dumazet Date: Tue Aug 18 17:27:55 2026 +0000 ip6mr: do not clone dst in ip6mr_cache_report() [ Upstream commit 235b42b5860189eb8c27c36435ad932cae65a734 ] IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period. If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free. Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry. Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in ip6mr_cache_unresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6_route_output(). Fixes: 67f415dd2906 ("ipv6: convert rx data path to not take refcnt on dst") Reported-by: Zero Day Initiative Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260818172755.4083692-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 684773c4d26f7f2211beb31fb90629216f8a61f5 Author: Pengpeng Hou Date: Sun Aug 16 13:21:09 2026 +0800 net: qlcnic: validate unified ROM sections before loading [ Upstream commit 5e8076e4e4124dae75a3e080ddc20404700d7585 ] The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields. Fixes: af19b49152bd ("qlcnic: Qlogic ethernet driver for CNA devices") Signed-off-by: Pengpeng Hou Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816052109.4607-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35a6026eadcb83238f80a79cc109361558322d83 Author: Tetsuo Handa Date: Mon Aug 17 23:08:15 2026 +0900 net: add missing ref_tracker_dir_exit() to net_passive_dec() [ Upstream commit f85dc137aabf357bf3d9fe4c9712121039d83798 ] I found that trying to read /sys/kernel/debug/ref_tracker/* causes NULL pointer dereference crash when alloc_netdev_mqs() via unshare() returned NULL, for commit 9ba74e6c9e9d ("net: add networking namespace refcount tracker") added ref_tracker_dir_exit(&net->refcnt_tracker) to only __put_net() path whereas commit 65b584f53611 ("ref_tracker: automatically register a file in debugfs for a ref_tracker_dir") added ref_tracker_dir_debugfs() to ref_tracker_dir_init() path. Since preinit_net() calls ref_tracker_dir_init(&net->refcnt_tracker) and ref_tracker_dir_init(&net->notrefcnt_tracker), we need to make sure that both ref_tracker_dir_exit(&net->refcnt_tracker) and ref_tracker_dir_exit(&net->notrefcnt_tracker) are called before net_passive_dec() schedules for kmem_cache_free() via net_complete_free(). ref_tracker_dir_exit(&net->refcnt_tracker) is called via put_net() when ns_ref_put() returned true. But put_net() is not called when copy_net_ns() fails. Therefore, call ref_tracker_dir_exit() from net_passive_dec() if put_net() is not yet called. Link: https://sashiko.dev/#/patchset/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08%40I-love.SAKURA.ne.jp Fixes: 9ba74e6c9e9d ("net: add networking namespace refcount tracker") Reviewed-by: Eric Dumazet Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/64254d80-9248-466c-8108-95f43bd71117@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f82b5dbb2fef65b52a62d5ffe05e0483c4385a83 Author: Cen Zhang (Microsoft) Date: Sun Aug 16 21:32:37 2026 -0400 ipv6: avoid divide by zero in rt6_multipath_rebalance [ Upstream commit d2c26c2911dd1a363c488add4fb63eb5f0f28f87 ] rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios. Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260817013237.2797-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit db038ac4dca0fa626199e9c297eddd8362be0550 Author: Eric Dumazet Date: Mon Aug 17 08:25:11 2026 +0000 netdevsim: update queue NAPI association on queue reset [ Upstream commit 07e98a4d5e9c292eae97c9cc5ab0937384e48492 ] In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown. Fixes: 5bc8e8dbef27 ("netdevsim: add queue management API support") Reported-by: syzbot+483a6efbc4882c1201ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a82c3d4.f7a79266.2f965f.0024.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260817082511.2300402-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f5d53818ba923558267dc34fb3c97f5b91fc7d78 Author: Ruoyu Wang Date: Sat Aug 15 23:17:37 2026 +0800 net: ipa: balance runtime PM reference on remove error [ Upstream commit 6b9eaa61ff2df63c6eb35d5cd025e2cef0861d76 ] ipa_remove() takes a runtime PM reference before accessing IPA hardware during teardown. If a concurrent modem start or stop keeps ipa_modem_stop() busy across both attempts, the callback intentionally returns without releasing the remaining resources because proceeding with teardown could crash. That return also skips the matching pm_runtime_put_noidle(), leaving the callback's usage-count reference held. Drop only this runtime PM reference before returning. pm_runtime_put_noidle() does not request an idle transition, so the hardware and resources retained on this exceptional path remain untouched while the usage count stays balanced. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 923a6b698447 ("net: ipa: get clock in ipa_probe()") Signed-off-by: Ruoyu Wang Reviewed-by: Alex Elder Link: https://patch.msgid.link/20260815151737.3758320-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 976e92931c28eac94e6712444cc37ed65c188518 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 d52c695b6980b715d0a7d555875bed8038f82689 Author: Or Har-Toov Date: Sun Aug 16 09:50:15 2026 +0300 net/mlx5: E-Switch, preserve max tx speed on vport state modification [ Upstream commit ad0ae7aefa7a6ede28a549d8dac87456d87ef6d4 ] When modifying vport state, the firmware interprets a zero in the max tx speed field as an intentional reset, which can overwrite previously set values. This patch attempts to fix this by querying the current max tx speed from firmware before modifying the vport state and passing it back in the modification command. If the query fails, fall back to the cached agg_max_tx_speed value to avoid inadvertently resetting the speed. Fixes: 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to vports") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a9a3ccdc35e16b5902b7087b08adf72e7dd4471 Author: Or Har-Toov Date: Sun Aug 16 09:50:14 2026 +0300 net/mlx5: Move vport DOWN state check out of mlx5_query_vport_max_tx_speed() [ Upstream commit 20f11b5cfa429ba3a2b8ef463d47e820687b4d2e ] mlx5_query_vport_max_tx_speed() was introduced to serve the query_port_speed path, which uses max_tx_speed == 0 when port is down. This is incorrect for callers that need the actual configured speed regardless of vport state, such as modify-vport-state helpers that must preserve the speed across state transitions. Move this logic to the caller function in the verb flow and let mlx5_query_vport_max_tx_speed() return the raw firmware value unconditionally. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19dd112279167e02b8af1e248ed58799a0a1ccf9 Author: Mark Bloch Date: Sun Aug 16 09:50:13 2026 +0300 net/mlx5: E-Switch, use state lock for vport state changes [ Upstream commit ff0f9b7aa1c756e24a8023eaf684e93774c64194 ] Protect vport admin state modifications and vport iteration with the eswitch state_lock mutex to ensure proper serialization of concurrent vport state changes. Currently, calls to mlx5_modify_vport_admin_state() and loops iterating over eswitch vports can race with each other, potentially leading to inconsistent vport state. Fix this by acquiring esw->state_lock Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Mark Bloch Reviewed-by: Shay Drori Reviewed-by: Or Har-Toov Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21c0a41260e4b799a89ef34ae1b67261cbbcdfb1 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 a5ce5b5aacd01f65ad440f5055c941db861e6b47 Author: Victor Nogueira Date: Sun Aug 16 17:13:27 2026 -0300 net/sched: add get_fill_size callbacks for actions missing them [ Upstream commit 8e2efb3f45a5c6f7c8f68685c1c4709040aa2fa0 ] Several tc actions - act_police, act_bpf, act_pedit, act_ife, act_sample, act_ct, act_ctinfo and act_tunnel_key among them - provide no get_fill_size() callback, so tcf_action_fill_size() falls back to tcf_action_shared_attrs_size() which does not account for the action-specific netlink attributes emitted inside TCA_ACT_OPTIONS by their dump functions. When an RTM_NEWACTION request with NLM_F_ECHO (or an RTNLGRP_TC listener) creates several actions, tcf_add_notify_msg() allocates the echo skb from this underestimated size. When this happens, the act_api code fails to add all of the fields to the netlink message and, thus, fails to send it. Issue is that, when that happens, this failure doesn't stop the action instances from being added. So any user watching these events will be under the false impression that no actions were created at all. For example, act_pedit overruns with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present. To fix this, add the missing get_fill_size callbacks returning the worst-case size of each action's dump attributes, following the pattern used by act_gact/act_skbedit/act_vlan. Also widen the TCA_GACT_TM accounting in tcf_action_shared_attrs_size() to nla_total_size_64bit(), since actions dump their tcf_t with nla_put_64bit(), which may be preceded by an NLA_PAD attribute. Note: We only provided fixes for the actions we reproduced this bug with as of today. We can send a separate hardening patch for the remaining actions to net-next later. The other pre-existing issues, pointed out by Clashiko [1], will be fixed in upcoming patches. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816201327.2435335-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 434849b21ef56b09d16e6366b2a230002f363e45 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 8341bd3ff126d85bc8c4ed52eedcaa5b1a65f194 Author: Cen Zhang (Microsoft) Date: Thu Aug 13 17:53:28 2026 -0400 xsk: fix NULL pointer dereference in __xsk_rcv() [ Upstream commit e37b2abca80473e106176e41712a369fd2f72117 ] In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop. Fixes: 804627751b42 ("xsk: add support for AF_XDP multi-buffer on Rx path") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Simon Horman Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260813215328.99311-1-blbllhy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e50df85ac835fc0deb9fcbe0146a758df94cf0a4 Author: Rustam Adilov Date: Thu Aug 20 21:20:17 2026 +0500 irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel() [ Upstream commit 58b34b72b64bfbfc5f8ad4d8f229942aff76597e ] When CONFIG_SWAP_IO_SPACE is enabled, readl() performs a swap from little endian device to big endian CPU and vice versa for writel(). This is incorrect for Realtek Interrupt controller as that is a big endian device and so the LE to BE conversions are unwanted. Fix this by converting the MMIO accesses to readl_be() and writel_be(). Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Rustam Adilov Signed-off-by: Thomas Gleixner Tested-by: Carlo Szelinsky Link: https://patch.msgid.link/20260820162017.28507-1-adilov@disroot.org Signed-off-by: Sasha Levin commit 12f903cfacb48956fa4003aebd72ead51ee86e69 Author: Markus Stockhausen Date: Fri Jun 5 23:16:43 2026 +0200 irqchip/irq-realtek-rtl: Add mask for interrupt handling [ Upstream commit 2a3fa7f31f43580edcba5ee9f97473801aa3deec ] When using multiple domains for the Interrupt controller, each one must know which hardware interrupts it serves. Add a mask that is filled during setup and apply it during interrupt handling. Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-5-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 7dd58ec1bbd41e695ebb4dc858ced8c2e1501002 Author: Markus Stockhausen Date: Fri Jun 5 23:16:42 2026 +0200 irqchip/irq-realtek-rtl: Add interrupt data structure [ Upstream commit 2568f6926c667e0b4ecf523cb4015acefc40409a ] To prepare for multiple parent interrupt domains add an intermediate data structure. For now this will only host the link to the domain. Additionally adapt a deviating variable name to driver standard "hw_irq". Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-4-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 1f0b4680d3b5a8c9b9dbb4d3b566802f0706b95a Author: Markus Stockhausen Date: Fri Jun 5 23:16:41 2026 +0200 irqchip/irq-realtek-rtl: Split out parent setup code [ Upstream commit d36c1d1657113fcf442c50e074593d7b712bada1 ] The parent interrupt setup will be extended to support multiple parents. To prepare for that, relocate the code into a separate helper. Although it still works only for a single interrupt prepare the coding so it can be easily extended with a loop for multi parent support. For this reduce the line lengths so that the upcoming indentation still leaves the width below 100 characters. Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-3-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 6c94e5f95258b4113de3e4e1abb57c828bb79841 Author: Namjae Jeon Date: Thu Aug 20 16:43:15 2026 +0900 smb: server: remove unused DES crypto header [ Upstream commit c5e640fe346177372ff4a51a45b01fcd48c29207 ] The DES crypto header is no longer used after the removal of NTLMv1 authentication. Remove it now that the server no longer selects CRYPTO_LIB_DES. Fixes: ce812992f239 ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 93fb16a86d5dbea2eefd1b3a365abc7226fb47cf Author: Thomas Huth Date: Thu Aug 20 08:58:15 2026 +0200 smb: server: Remove obsolete "select CRYPTO_LIB_DES" from Kconfig file [ Upstream commit ed91d80242358ffdf127a34e3b7c9fc445c9e5d1 ] The DES encryption in the smb server code has been removed in 2021 with the removal of the insecure NTLMv1 authentication code. Thus we don't need this "select" statement here anymore. Fixes: ce812992f239f ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1e16e82581521a2fe20eda29bdc9e75286f7c950 Author: Runyu Xiao Date: Thu Aug 20 19:27:49 2026 +0800 ALSA: mtpav: shut down output timer before card teardown [ Upstream commit c73cb5b7c159246dd572277c668851a56e516019 ] snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state. snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer. A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned. Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820112749.9195-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 24d81b72992006f9c390f1fc85c7f991e6d06fd6 Author: Nitin Gote Date: Fri Aug 14 13:11:07 2026 +0530 drm/xe: don't WARN on kernel job timeout when device already wedged [ Upstream commit 13087ad7817e6e5f210064518bfc4d6d58a9c2f3 ] igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out. Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel. Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN. Fixes: 5a2f117a80c2 ("drm/xe: Do not wedge device on killed exec queues") Cc: Matthew Brost Signed-off-by: Nitin Gote Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 5969a3df8361a0e20379a308c2313d3e263123de Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:19 2026 +0200 spi: amlogic-spisg: Make sure clk_init_data is fully initialized [ Upstream commit b2702908ee23ef31bfcf241a2e07ace0eb76bd71 ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e46ef54fe4d9c191aaff03a50e7a508a45cf81e6 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 ea5a3c30710710c1dc5e483d3313309ec2e868f7 Author: Dennis Tighe Date: Thu Aug 20 19:28:39 2026 +0900 ntfs: validate usa_ofs before preserving the update sequence number [ Upstream commit 81684340963da2e898eabb8c1e274433d9375bc6 ] When ntfs_mft_record_alloc() reuses a free mft record it reads the old update sequence number straight from the on-disk record: usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs)); Here m points into the raw $MFT page-cache folio, which still holds unvalidated, MST-protected bytes: the folio is read by a plain iomap_read_folio() and neither post_read_mst_fixup() nor ntfs_mft_record_check() has run on it (both work on private copies). m->usa_ofs is therefore an untrusted u16, and a corrupted record can put it past the end of the record so the two-byte read lands outside the folio. Reading such a record while creating a file gives, under KASAN: BUG: KASAN: use-after-free in ntfs_mft_record_alloc+... Read of size 2 at addr ... ntfs_mft_record_alloc -> __ntfs_create -> ntfs_create -> path_openat Only preserve the old update sequence number when usa_ofs is even and in range, mirroring the check ntfs_mft_record_check() already applies; otherwise leave usn zero, which the existing restore below skips. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b42644e425fed4a5cd6c88372655da5c1b52c666 Author: Dennis Tighe Date: Wed Aug 19 23:32:58 2026 -0700 ntfs: fix off-by-one page overflow in ntfs_decompress() [ Upstream commit 98716c9fce21f6c8a9d71e08cf53e7504fa562f4 ] The per-token range check in ntfs_decompress() uses if (cb >= cb_sb_end || dp_addr > dp_sb_end) break; so dp_addr == dp_sb_end falls through to the symbol copy `*dp_addr++ = *cb++`, writing one byte past the destination page. Since NTFS_SB_SIZE == PAGE_SIZE the destination is a single page, so the byte lands in the adjacent page, and *dest_ofs is left one past the sub-block end (the later `*dest_ofs &= ~PAGE_MASK` then yields 1, not 0, so the page is never finalized and later sub-blocks keep writing further past it). A corrupted compressed $DATA attribute thus produces a bounded run of out-of-bounds writes when the file is read. Break as soon as dp_addr reaches dp_sb_end; a full sub-block still completes, as its final copy advances dp_addr to exactly dp_sb_end. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e52c8cd7e75440b8e2df007bbb3d85e203cc458a Author: Sebastian Andrzej Siewior Date: Thu Aug 13 09:38:55 2026 +0200 sched/topology: Add a cpus_read_lock to rebuild_sched_domains() [ Upstream commit 666a32836c8f9daf9b0067c49b04d5201fb8f3ba ] A read from /proc/sys/kernel/sched_rt_runtime_us leads to backtrace due to missing cpu_hotplug_lock with CONFIG_CPUSETS=n. The callchain is sched_rt_handler() -> partition_sched_domains() -> sched_cache_set() -> static_key_enable_cpuslocked(&sched_cache_present). sched_cache_set() itself is also invoked from sched_init_domains() which is early during the boot, holding just the sched_domains_mutex_lock(). Here is no warning because it happens before user space is running (and hotplug operations are not possible). There is also sched_cache_active_set() which acquires the hotplug lock before invoking any of the _cpuslocked() functions. This is only a problem with CONFIG_CPUSETS=n because in the =y case the other implementation of rebuild_sched_domains acquires the CPU-hotplug lock. Acquire CPU hotplug lock before in rebuild_sched_domains(), before partition_sched_domains() is invoked for the CONFIG_CPUSETS=n case. Fixes: a7660ce1590fc ("sched/cache: Fix has_multi_llcs iff at least one partition has multiple LLCs") Signed-off-by: Sebastian Andrzej Siewior Reivewed-by: Ridong Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: Waiman Long Reviewed-by: Valentin Schneider Reviewed-by: Shrikanth Hegde Reviewed-by: Aaron Tomlin Tested-by: Dietmar Eggemann Link: https://patch.msgid.link/20260813073855.ji2UrtVh@linutronix.de Signed-off-by: Sasha Levin commit 24b399f51812d727dc25d7814c4d7e0cca38201e Author: Haotian Zhang Date: Thu Aug 20 09:41:17 2026 +0800 ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup [ Upstream commit d736eba9c453fedce664fdf592c8b71ecff1932b ] snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive. Fixes: ca642da4b33d ("ALSA: ice1712: Allocate resources with device-managed APIs") Suggested-by: Takashi Iwai Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260820014117.14044-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ae344ed82795b3737a7151cdd9d99039b810a4f2 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:35 2026 +0200 irqchip/gic-v5: Defer default SPI and LPI IAFFID programming [ Upstream commit a1ee1a1ca75b674f503c74eb8b3ca77612ba3c0c ] SPI and LPI interrupts do not have an architected default value for their IAFFID (interrupt affinity ID) - the property that determines an IRQ affinity. Current code awkwardly tries to set a default IAFFID value corresponding to the logical cpu executing the gicv5_hwirq_init() function at SPI/LPI allocation time. There are two issues with this approach: - gicv5_hwirq_init() is called in preemptible context and current code uses smp_processor_id() to check the logical cpu executing the function. Whilst that's harmless, it can spit a splat on DEBUG_PREEMPT kernels - Setting the default SPI/LPI IAFFID to the one belonging to the cpu executing the IRQ allocation is a completely arbitrary choice It is saner to remove the SPI/LPI IAFFID set-up in the SPI/LPI domain IRQ allocation code and flag SPI/LPI irqchips as IRQCHIP_AFFINITY_PRE_STARTUP so that the SPI/LPI affinity is initialized by IRQ core to a sane value before an IRQ is started up using the respective irq_chip irq_set_affinity() callback. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-7-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 3958493a70ceddec79023ad0a8e6e56a881459cb Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:34 2026 +0200 irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocation [ Upstream commit 9dfcc2187282816d42b9f8aa2b689c732ebbcc01 ] In set-ups with a 2-level IST, L1 table entries are created dynamically when LPIs are allocated. The L1 allocation and mapping, implemented in gicv5_irs_iste_alloc() is carried out in preemtible context and can be carried out on any IRS in the system. Current code indexes the per_cpu_irs_data per cpu array using smp_processor_id() to retrieve the IRS that is local to the core executing gicv5_irs_iste_alloc(). Since that's preemptible context, the core executing that function can change on preemption. Given that every IRS in the system is equivalent to each core, this is not really an issue in that even if the thread is preempted and resumed on a different cpu, the table allocation and mapping to an IRS would work seamlessly regardless. On the other hand, smp_processor_id() spits a legitimate splat on DEBUG_PREEMPT kernels when used in preemtible context and this should be fixed. Given that all IRSes are equivalent from a core perspective in terms of IST initialization, always choose as a policy the IRS local to logical cpu 0, preventing the smp_processor_id() splat. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-6-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 7c10ec4987b783660f245c7f0bdc7061ecbddeda Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:33 2026 +0200 irqchip/gic-v5: Release IRS iomem region on driver init failure [ Upstream commit dc2eae1620bdb4562aa43f1c34c8427308ab4436 ] In gicv5_irs_of_init(), an IRS is set-up using of_io_request_and_map() to request its memory region (corresponding to the configuration frame) and map the IRS configuration frame. On gicv5_irs_of_init() failure, the driver unmaps the IRS iomem region but does not release the requested memory region leaving it allocated in the iomem resource tree. Fix it by releasing the iomem region on gicv5_irs_of_init() probe failure. Likewise, on both OF and ACPI driver init failure, IRS iomem regions are requested but never released in gicv5_irs_remove(). Stash a copy of the IRS iomem region in a struct resource in struct gicv5_irs_chip_data and use it to release the requested region in gicv5_irs_remove() if the driver probe fails. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-5-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 7b7201493383e88e994893d619f6eead438466f2 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:32 2026 +0200 irqchip/gic-v5: Fix gicv5_init_common() error paths [ Upstream commit 183750b276c229c5253b3b11581f6cd8877b753e ] Current code fails to disable interrupts on gicv5_starting_cpu() failure and to set the handle_arch_irq pointer to NULL if gicv5_irs_enable() fails. Update the respective error paths to fix them. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-4-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 69f0c79f5b692192901fbe8bddafd230b90f5a52 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:31 2026 +0200 irqchip/gic-v5: Disable IRSes on probe failures [ Upstream commit 79b115c2a29204cb7e836b0df0b8c466be4b2250 ] GICv5 driver probe failures cause IRSes initialized by the kernel to be unmapped and their data structures to be destroyed but the current driver leaves the probed IRSes enabled, whereas they should be disabled. Disable IRSes on driver probe failures so that the IRSes are brought back to their quiescent HW state. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-3-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit f43bdac1ae4847932ead218cc13a3a74ab121fb7 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:30 2026 +0200 irqchip/gic-v5: Check for NULL LPI domain on domain teardown [ Upstream commit aa079dbf4c2598c2613a0e464efcb2c232753c51 ] In gicv5_free_lpi_domain() the LPI domain being freed can be NULL. Check it and return before trying to free it if it is. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-2-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 6caeb878f809bdf0aec2fdd96f3d41ef4b69fc69 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:29 2026 +0200 irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing [ Upstream commit 328affc639ce9873a7a0a3fd6b8339f19767529b ] In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value. Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-1-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit a7c0415209243962e4435c057a0b2a3a5dac647a Author: Sascha Bischoff Date: Tue Aug 11 15:27:31 2026 +0000 irqchip/gic-v5: Synchronize CPU interface disable [ Upstream commit ac6db0e0bee18cd4385418c752a007e1aba4ec14 ] The write disabling the GICv5 CPU interface is only guaranteed to take effect after a context synchronization event. Without one, execution can return from gicv5_cpu_disable_interrupts() while an interrupt is still able to be taken. Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are disabled before the function returns. No corresponding ISB is added when enabling the interface, as interrupt delivery is asynchronous and there is no obvious benefit to waiting for it. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Lorenzo Pieralisi Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6 Link: https://patch.msgid.link/20260811152630.942023-3-sascha.bischoff@arm.com Signed-off-by: Sasha Levin commit 54937af6f4a0d44c2852a203d457902f3264c906 Author: Sascha Bischoff Date: Tue Aug 11 15:27:00 2026 +0000 irqchip/gic-v5: Clear per-CPU IRS data on teardown [ Upstream commit 3dfc0ab5fefd052c6028c4632b1fad8bdaf7967e ] IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory. On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Lorenzo Pieralisi Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=2 Link: https://patch.msgid.link/20260811152630.942023-2-sascha.bischoff@arm.com Signed-off-by: Sasha Levin commit 69212cccf4f9092bf946ec1548bdf9180cb93aa3 Author: Michael Pesa Date: Tue Jul 21 22:02:43 2026 -0700 irqchip/ast2700-intc: Disable all interrupt merge banks on probe [ Upstream commit 34b7e953d19a39515f8fc6c0820ebf243ea6b026 ] The INTC0 interrupt-merge (INTM) space has 50 sources at 10 per bank, i.e. INTC0_INTM_NUM / INTM_IRQS_PER_BANK = 5 banks. This is reflected everywhere the banks are indexed: the aspeed_intc0_intm_routes[] table has 5 valid entries, and the mask/unmask/eoi paths compute the bank as (hwirq - INTM_BASE) / INTM_IRQS_PER_BANK, spanning banks 0-4. However, INTC0_INTM_BANK_NUM is hardcoded to 3, so aspeed_intc0_disable_intm() only clears IER for banks 0-2 at probe. Banks 3 and 4 are left in whatever state the firmware configured them , which can leave interrupts enabled before a handler is installed. Derive the bank count from the source count so the probe-time disable covers every bank. Fixes: 07825e41519a ("irqchip/ast2700-intc: Add AST2700-A2 support") Signed-off-by: Michael Pesa Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260722050243.298355-1-michael.pesa@icloud.com Signed-off-by: Sasha Levin commit 5ecfa72e74c6e2a765fa5bc1da574e5beae588f2 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:16 2026 +0200 clk: visconti: Make sure clk_init_data is fully initialized [ Upstream commit 39c0e6c844a14945040cca4ccf6997792ab764c4 ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c1c6d311fa830b807bfe7f3153785026d94c2d6e Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:15 2026 +0200 clk: ti: Make sure clk_init_data is fully initialized [ Upstream commit 3ae1674975d48fb6d343d03ff7961abd6904af1a ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. _register_mux() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter is uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name") Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Mathieu Dubois-Briand Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6234b08fbc4b6659e393b33e8a0cf57c9fdf7115 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 56ae1f0b08400449bbad35ff7b6337064e37f4fb Author: Karl Mehltretter Date: Sat Aug 8 14:36:08 2026 +0200 lib/interval_tree: fix allocation warning messages [ Upstream commit d9c0fd5533fb23bc445bd581feb140e966195936 ] WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Link: https://lore.kernel.org/20260808123608.73613-1-kmehltretter@gmail.com Fixes: 82114e45131f ("lib/interval_tree: add test case for interval_tree_iter_xxx() helpers") Assisted-by: Claude:claude-fable-5 coccinelle Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Morton Reviewed-by: Wei Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 63337be8f5c43e445770b0b384cf2f3161cdc7eb Author: Linkai Gong Date: Fri Jul 31 16:04:58 2026 +0800 rtc: gamecube: check return value of devm_rtc_register_device() [ Upstream commit ca45cfa74370644d371b552bef57938c19e3c80c ] gamecube_rtc_probe() ignored the return value of devm_rtc_register_device() and always returned success. Propagate the error so probe fails when RTC registration fails. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Linkai Gong Link: https://patch.msgid.link/20260731080458.417532-1-gonglinkai@kylinos.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c80e3c69cf19716e5cea1855e9126ed202c9004a Author: Ruoyu Wang Date: Thu Aug 13 23:31:55 2026 +0800 i2c: ocores: Disable clock on failed resume [ Upstream commit 43eb13f13385a1e7251978a1977ac61b99edef01 ] ocores_i2c_resume() enables the controller clock before reinitializing the hardware. If the clock rate changed while the device was suspended, ocores_init() may reject the resulting prescaler. The callback then returns an error with the clock still enabled, while the controller itself remains disabled. Disable and unprepare the clock when ocores_init() fails so the failed resume path balances the successful clk_prepare_enable() call. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: e961a094afe0 ("i2c: ocores: add common clock support") Signed-off-by: Ruoyu Wang Reviewed-by: Max Filippov Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813153155.3953577-1-ruoyuw560@gmail.com Signed-off-by: Sasha Levin commit f2f0da11648616e47419dca93610f6c0d70ec00b Author: Ryan Chen Date: Wed Aug 19 09:09:19 2026 +0800 irqchip/ast2700-intc: Avoid allocating in the irq_domain activate() callback [ Upstream commit b76eee9c2157223aa4aac42ceebb563288e078aa ] The interrupt core calls the irq_domain_activate() callback from __setup_irq() with desc->lock held and interrupts disabled. Both aspeed_intc1_irq_domain_activate() and aspeed_intc0_resolve_route() test a compatible string with fwnode_device_is_compatible(). fwnode_device_is_compatible() invokes fwnode_property_match_string(), which allocates with GFP_KERNEL. That's obviously not possible with interrupts disabled and a raw spinlock held. Both call sites are only ever handed OF nodes, so use of_device_is_compatible() instead: it walks the property in place and does not allocate. Fixes: 07825e41519a ("irqchip/ast2700-intc: Add AST2700-A2 support") Reported-by: Andrew Jeffery Signed-off-by: Ryan Chen Signed-off-by: Thomas Gleixner Tested-by: Andrew Jeffery Link: https://patch.msgid.link/20260819-fix-ast2700-intc-atomic-alloc-v1-1-d92a02e2a239@aspeedtech.com Signed-off-by: Sasha Levin commit dbecbe23dc606c4af68b4591a41124186f5c1802 Author: Biju Das Date: Tue Aug 18 12:09:33 2026 +0100 irqchip/renesas-rzg2l: Fix loss of interrupt [ Upstream commit 50b10bd0c2d721ad38abd1abe3acdefb6caa0944 ] rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved. Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260818110937.5816-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit 3f00d8a5e16c0420104c523385026f87a2bf0d45 Author: Pengpeng Hou Date: Wed Jun 24 13:55:24 2026 +0800 rtc: zynqmp: Return optional clock lookup errors [ Upstream commit 5904c4109554582ce8ded6a4dcfede48b21dbe4d ] devm_clk_get_optional() returns NULL when the optional clock is absent, but returns an ERR_PTR when the clock provider lookup fails. Probe currently keeps the ERR_PTR and then passes it to clk_get_rate(). Return the lookup error instead. A truly absent optional clock still reaches the existing calibration fallback through clk_get_rate(NULL). Signed-off-by: Pengpeng Hou Fixes: 07dcc6f9c762 ("rtc: zynqmp: Add calibration set and get support") Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260624055524.38522-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit a24926c5130378048680489e94e82f7539fb540b Author: Frank Sorenson Date: Fri Jul 31 12:12:31 2026 -0500 cifs: remove dead size-update blocks in cifs_setattr_unix/nounix [ Upstream commit 60be95527bc8d1b33dca25d2a849268cca11d139 ] Commit 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") introduced cifs_file_set_size(), which calls netfs_resize_file() and cifs_setsize() on success. cifs_setsize() calls i_size_write(), updating i_size to the new value. The subsequent blocks in both cifs_setattr_unix() and cifs_setattr_nounix(): if ((attrs->ia_valid & ATTR_SIZE) && attrs->ia_size != i_size_read(inode)) { truncate_setsize(inode, attrs->ia_size); netfs_resize_file(&cifsInode->netfs, attrs->ia_size, true); fscache_resize_cookie(cifs_inode_cookie(inode), attrs->ia_size); } are therefore unreachable on the success path: attrs->ia_size == i_size_read(inode) always holds after cifs_file_set_size() succeeds. On the failure path, execution jumps to out/cifs_setattr_exit before reaching these blocks. truncate_setsize() and netfs_resize_file() are redundant with what cifs_file_set_size() already did; fscache_resize_cookie() was moved there by commit fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()"). Remove both dead blocks. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Signed-off-by: Frank Sorenson Reviewed-by: Huiwen He Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 7ec4098359b9a558d91aaf2cd1e95a068196cbbe Author: Christopher Lusk Date: Wed Jul 29 15:20:02 2026 -0400 smb: client: set replay flag on the read send-error retry path [ Upstream commit 45f84cf25a0879a4d4e3ec3079982537be57c564 ] smb2_async_readv() and smb2_async_writev() end with the same send-error block: if the error is replayable and smb2_should_replay() agrees, tell netfs to retry the subrequest. The write path also sets wdata->replay. The read path does not set rdata->replay. smb2_should_replay() is not a pure predicate. It consumes the retry budget and computes the exponential back-off, doubling cur_sleep up to CIFS_MAX_SLEEP. That back-off is only applied where the replay flag is tested at the top of the reissued request: if (rdata->replay) { /* Back-off before retry */ if (rdata->cur_sleep) msleep(rdata->cur_sleep); smb2_set_replay(server, &rqst); } So on the read path the back-off is recomputed on every send-error retry and then discarded, and SMB2_FLAGS_REPLAY_OPERATION is not set on the reissued request. netfs does not pace the retry either. netfs_reissue_read() calls ->issue_read() directly, and fs/netfs/read_retry.c contains no delay of its own, so read send-error retries reissue immediately while the equivalent write retries back off. The read response callback already sets rdata->replay under the same conditions, so the read path does use the replay mechanism. Only this send-error path omits it. Where the back-off belongs was settled while the commit below was under review. David Howells asked whether netfslib should be doing the back-off [1], and objected to sleeping inside the response callback because that runs in the cifsd thread and would stall the socket [2]. The sleep was therefore taken out of smb2_should_replay() and moved to just before the replay in smb2_async_readv() and smb2_async_writev() [3]. Setting the flag here preserves that arrangement: the sleep still happens at the top of the reissued request, not in a callback. Set rdata->replay here, matching smb2_async_writev(). Fixes: 2c1238a7477a ("cifs: make retry logic in read/write path consistent with other paths") Link: https://lore.kernel.org/all/1652858.1769038134@warthog.procyon.org.uk/ [1] Link: https://lore.kernel.org/all/1653031.1769038583@warthog.procyon.org.uk/ [2] Link: https://lore.kernel.org/all/CANT5p=pXP3+CywpmK-on2uTvxO3S=31_B85_UDR7RoK1dQVtMA@mail.gmail.com/ [3] Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-5 Signed-off-by: Christopher Lusk Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 73f6bdb0380486ab37fe12cd74de20abfaf5d3ae Author: Christopher Lusk Date: Wed Jul 29 18:00:17 2026 -0400 smb: client: fix request buffer leak in smb2_new_read_req() [ Upstream commit deb6468f4164640e4dc875f008aa449cf55987a5 ] smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, (void **) &req, total_len); if (rc) return rc; if (server == NULL) return -ECONNABORTED; [...] rdata->mr = smbd_register_mr(server->smbd_conn, &rdata->subreq.io_iter, true, need_invalidate); if (!rdata->mr) return -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: wdata->mr = smbd_register_mr(...); if (!wdata->mr) { rc = -EAGAIN; goto async_writev_out; } Commit b7972092199f ("cifs: smbd: Retry on memory registration failure") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv(). Fixes: bd3dcc6a22a9 ("CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration") Link: https://sashiko.dev/#/patchset/20260729192002.876156-1-clusk%40northecho.dev Link: https://lore.kernel.org/all/20260729192002.876156-1-clusk@northecho.dev/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Christopher Lusk Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 12f124ec61c7477955a67fc5b6cb53c7478cc093 Author: ChenXiaoSong Date: Fri Aug 7 08:58:06 2026 +0000 smb/client: return EOPNOTSUPP for unsupported O_TMPFILE [ Upstream commit a2f9fb451c68adf2b3f7cae1bb66fb5801769ac6 ] Some SMB servers return STATUS_OBJECT_NAME_NOT_FOUND or STATUS_DELETE_PENDING when creating an O_TMPFILE. The SMB client maps them to ENOENT. The ENOENT error is supposed to be returned when the path (a target directory in this case) does not exist, while a lack of support of O_TMPFILE by the target file system should be indicated by EOPNOTSUPP. Reported-by: Mikhail Stefantsev Fixes: 3e7d63037a2b ("smb: client: add support for O_TMPFILE") Closes: https://lore.kernel.org/linux-cifs/75fb5359-b268-492d-8d4a-504d1af60f2a@app.fastmail.com/ Signed-off-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 9a4d2ef7e72b98d5582520b56dd83260c02cf7a6 Author: Surendra Singh Chouhan Date: Fri Jul 24 19:28:03 2026 +0530 rtc: spacemit: handle regmap_test_bits() error return [ Upstream commit 092755367e1a5fcf0f5405e9425e86907199dfce ] p1_rtc_read_time() called if (!regmap_test_bits(regmap, RTC_CTRL, RTC_EN)) to check if the RTC was enabled. regmap_test_bits() returns 1 if the bit is set, 0 if not set, and a negative error code (e.g. -EIO) if reading the control register fails. Using !regmap_test_bits(...) evaluates a negative error code as boolean false, causing I2C/regmap read failures to be ignored and incorrectly proceeding to read time registers from a failing device. Fix this by capturing the return value of regmap_test_bits() and returning the error code if negative, or -EINVAL if the RTC is disabled. Fixes: a6de182daa2b ("rtc: spacemit: support the SpacemiT P1 RTC") Reviewed-by: Alex Elder Signed-off-by: Surendra Singh Chouhan Link: https://patch.msgid.link/20260724135803.81223-1-kr494167@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6218c0533a72235ec9c5f41b812c63d963bd4a3e 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 afbf69d1d691c06d093d7c3f17168ecb608c4977 Author: GuoHan Zhao Date: Tue Jul 14 10:43:52 2026 +0800 virtio: rtc: time out alarm requests [ Upstream commit 68e00d9212929805b40dcb9166755610f4f4acee ] RTC class operations run with rtc_device.ops_lock held. The virtio RTC alarm requests currently wait without a timeout for the device to return their requestq buffers. On surprise removal, virtio-pci marks the virtqueues broken before unregistering the virtio device. If an alarm request is waiting when the device stops responding, viortc_remove() blocks in viortc_class_stop() while trying to acquire ops_lock. The request cannot complete and device removal hangs until the waiting task is signalled. Use the same 60-second timeout as clock read requests for alarm reads, alarm programming, and alarm interrupt enable requests. The existing message reference counting keeps a timed-out request alive until a late response or device teardown. Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: GuoHan Zhao Reviewed-by: Peter Hilber Signed-off-by: Michael S. Tsirkin Message-ID: <20260714024352.71307-1-zhaoguohan@kylinos.cn> Signed-off-by: Sasha Levin commit c678d04ac9e5a64c2559c43bce273e845fbd09eb 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 89b4d033a4b531d8aff55283e26d4ec3e4d945b2 Author: Li RongQing Date: Mon Jun 29 11:35:38 2026 +0800 virtio_pci: fix wrong queue index for admin vq in intx path [ Upstream commit dc3f1eef9ab678c396baf5df12aba61db061aa8c ] In vp_find_vqs_intx(), the admin vq was set up using the local queue_idx counter instead of avq->vq_index (the actual queue index obtained from the device). This differs from vp_find_vqs_msix() which correctly uses avq->vq_index. Using the wrong index causes the admin virtqueue to be mapped to an incorrect hardware queue. Fix it by using avq->vq_index consistent with the msix path. Fixes: af22bbe1f4a5 ("virtio: create admin queues alongside other virtqueues") Signed-off-by: Li RongQing Message-ID: <20260629033538.2476-1-lirongqing@baidu.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 43a8e02dc826dd3dcc0f1f6d0281fb11ad093da1 Author: Yufeng Wang Date: Fri Jun 26 15:04:38 2026 +0800 vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY [ Upstream commit 92a7b138f2453bf067628de0c5ec563cc8ad16d5 ] The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts at argp, which is the beginning of the features array, overwriting the data just written by copy_to_user(). It should start after the copied elements at argp + copied * sizeof(u64) to only zero the trailing unused space. Use size_mul() for both the offset and length calculations so the arithmetic stays consistent with the surrounding code and remains overflow-safe. Fixes: 333c515d1896 ("vhost-net: allow configuring extended features") Signed-off-by: Yufeng Wang Acked-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-ID: <20260626070438.59149-1-r4o5m6e8o@163.com> Signed-off-by: Sasha Levin commit bdef50a8226fc04899ef6815dd08a002247d47d5 Author: Denis V. Lunev Date: Wed Jun 24 16:08:45 2026 +0200 virtio_balloon: quiesce balloon work before device shutdown [ Upstream commit 7e17eef04600c399c7e0f5ce765da5cf9d40d8e1 ] Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet. Add a .shutdown handler that quiesces the balloon via the shared virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued. Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-4-den@openvz.org> Signed-off-by: Sasha Levin commit 1ac4c32198b83f93ee72ad793f6353f8e8c90ea5 Author: Denis V. Lunev Date: Wed Jun 24 16:08:44 2026 +0200 virtio_balloon: factor out virtballoon_quiesce() [ Upstream commit 29536a923a9412812eb3e378258019b54538a220 ] virtballoon_remove() stops all of the balloon's asynchronous work (the free page reporting worker, the inflate/deflate and stats workers, the OOM notifier and the free page shrinker) before tearing the device down. A following change needs the same teardown from a .shutdown handler, so move it into a virtballoon_quiesce() helper. No functional change. Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-3-den@openvz.org> Stable-dep-of: 7e17eef04600 ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin commit fcbba617b38cb368519681bda6426e2c09cf172f Author: Denis V. Lunev Date: Wed Jun 24 16:08:43 2026 +0200 virtio: add virtio_device_shutdown() helper [ Upstream commit 0d8aebe089b4ba887e792884cf041ce9f1040ff4 ] The generic virtio bus .shutdown handler, virtio_dev_shutdown(), breaks and resets a device once it has established that the driver has no .shutdown of its own. A driver that does implement .shutdown, to quiesce its own activity first, still needs the same break and reset afterwards and would otherwise have to open code it. Factor the break + synchronize_cbs + reset sequence out of virtio_dev_shutdown() into an exported virtio_device_shutdown() helper so such drivers can reuse it instead of duplicating the core logic. No functional change. Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-2-den@openvz.org> Stable-dep-of: 7e17eef04600 ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin commit ca6f3fa599cb764518df595368b743f856fdb516 Author: Linfeng Sun Date: Sat Jun 20 18:09:59 2026 +0800 vdpa_sim: fix cleanup after worker creation failure [ Upstream commit bd670e5dfd2b01fd9692f61fa1456434c54026a4 ] vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance. Fixes: 76acfa7bc54f ("vdpa_sim: use kthread worker") Assisted-by: OpenAI-Codex:GPT-5 Reviewed-by: Eugenio Pérez Signed-off-by: Linfeng Sun  Message-ID: <20260620100959.2070316-1-slf@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 2ee4d24c88c488a34a6ef6618d7ac2d6b379b7a2 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 14dca701e72a13518d3aa3f968bccdb994b961be Author: Baolin Liu Date: Tue Aug 18 16:27:40 2026 +0800 ntfs: do not update ctime when setxattr fails [ Upstream commit 60038154b40e03fdfade1eb975f0305c4c887d5e ] ntfs_setxattr() updates ctime and marks the inode dirty even when the operation fails. A failed setxattr(2) must not change file metadata. Update ctime only on success. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 0400e0d50eb3be19c98323faa322b652e4ae3f99 Author: Hyeontae Lee Date: Wed Aug 19 15:09:09 2026 +0900 ntfs: serialize resident iomap reads with mrec_lock [ Upstream commit d9e00c457d4ab8ab59c6e4b8554c921260e4e16c ] ntfs_read_iomap_begin_resident() walks the MFT record through ntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer under that lock. map_mft_record() only takes a reference and does not serialize, so the reader can observe torn attribute length and offset fields while a writer is relocating the records. KCSAN reports the race between the mmap read fault path and both link() and unlink(): BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520 read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000 value changed: 0x00000250 -> 0x000001f0 The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed. Keep base_ni->mrec_lock from the resident read iomap lookup through iomap_end(). This protects both the attribute walk and the subsequent copy from iomap->inline_data, which points into the MFT record. The non-resident path is left alone: ntfs_lookup() already holds the directory inode's mrec_lock when it reads an index folio through read_mapping_folio(), and taking the lock in the shared wrapper deadlocks there with recursive locking on mrec_lock. The comment above the read_mapping_folio() call in fs/ntfs/dir.c notes the same hazard. The seek path uses the same lookup helper but does not dereference iomap->inline_data. Release the lock before returning from that path, whereas the regular read path records base_ni in iomap->private and releases the lock from its iomap_end() callback. Tested with a reproducer that faults in a 16-byte resident file while another thread runs link()/unlink() on it. Before: 40 KCSAN reports in about one second. After: no reports in 180 seconds over 206,090 read iterations and 423,540 link/unlink cycles. A PROVE_LOCKING build shows no lockdep splat with the same reproducer running for 60 seconds. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Link: https://lore.kernel.org/all/20260725042421.109599-1-wonju345@naver.com/ Signed-off-by: Hyeontae Lee Co-developed-by: Namjae Jeon Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9d1b68f3dd11a386521ed2241af94d0e14c62070 Author: Joanne Koong Date: Wed Jul 29 12:27:24 2026 -0700 ntfs: convert iomap ops to ->iomap_next() [ Upstream commit 7a7bf7551624f8e7e1877f1b6ca088499b5ad25e ] Convert ntfs iomap_ops to the new ->iomap_next() callback. Each callback is generated with the DEFINE_IOMAP_ITER_NEXT()/DEFINE_IOMAP_ITER_NEXT_END() macros, which wrap the iomap_iter_next() helper to finish the previous mapping if needed and produce the next one. No functional changes are intended. Acked-by: Namjae Jeon Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20260729192737.3190206-10-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: d9e00c457d4a ("ntfs: serialize resident iomap reads with mrec_lock") Signed-off-by: Sasha Levin commit 95dc8483f2d70927798056db5692e3280dc1dcb5 Author: Joanne Koong Date: Wed Jul 29 12:27:20 2026 -0700 iomap: add ->iomap_next() [ Upstream commit 26dfed9c7a289089b76cff9ab9e4c66b6f90e872 ] Have one ->iomap_next() callback instead of ->iomap_begin() and ->iomap_end(). ->iomap_next() finishes the previous mapping if needed, and produces the next mapping. Collapsing to a single callback lets a performance-critical caller inline its iteration loop and pass its ->iomap_next() function as a compile-time constant, so the compiler can devirtualize that callback into a direct call instead of an indirect call through a function pointer. iomap_iter() uses ->iomap_next() when the filesystem provides that callback and otherwise falls back to the ->iomap_begin()/->iomap_end() path, so filesystems can be converted one at a time. Suggested-by: Christoph Hellwig Suggested-by: Matthew Wilcox (Oracle) Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20260729192737.3190206-6-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: d9e00c457d4a ("ntfs: serialize resident iomap reads with mrec_lock") Signed-off-by: Sasha Levin commit 8a255824aa0003104dfa822a2c3943042218f884 Author: Joanne Koong Date: Wed Jul 29 12:27:17 2026 -0700 iomap: split iomap_iter() logic into iomap_iter_next() [ Upstream commit 19eb9f6ab5ce1d15c7f5e48ca16804a6d7740084 ] In preparation for changing iomap to use an in-iter (->iomap_next()) model, move the iomap_iter() logic out into the new iomap_iter_next() helper function. iomap_iter_next() is added as an inlined helper so it can be called directly by ->iomap_next() implementations where the begin()/end() callbacks can be direct calls. The DEFINE_IOMAP_ITER_NEXT() and DEFINE_IOMAP_ITER_NEXT_END() macros are also provided to generate the boilerplate ->iomap_next() wrapper functions that simply forward to iomap_iter_next() with the appropriate begin/end callbacks. DEFINE_IOMAP_ITER_NEXT() is for the common case where there is no end() callback. DEFINE_IOMAP_ITER_NEXT_END() is for the case where there is an explicit end() callback. No functional change intended. The one would-be behavioral difference is that on the iomap_end() error path (ret < 0 && !advanced), the old code returned with iter.status left as the caller's last value whereas the new code zeroes it, but this is not observable in practice as there are no in-tree callers that read iter.status after the iteration loop. Reviewed-by: Darrick J. Wong Reviewed-by: Fengnan Chang Reviewed-by: Christoph Hellwig Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20260729192737.3190206-3-joannelkoong@gmail.com Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: d9e00c457d4a ("ntfs: serialize resident iomap reads with mrec_lock") Signed-off-by: Sasha Levin commit 95d7098561e519d0e6aad63ab6cf695f711e2fa9 Author: Namjae Jeon Date: Mon Aug 10 23:23:17 2026 +0900 ntfs: allow index root relocation [ Upstream commit 9badcfb91bc3bd5edb530fbcdd16f25d66640f33 ] Allow a resident attribute record to move to an extent MFT record when the base record needs room for an attribute list. Retry the root conversion after creating the list, but do not relocate a root that is already external. Roll the root back to the base record if persisting the attribute list fails, and free extent MFT records left empty by relocation or rollback. Also preserve bitmap allocation errors in index operations. Fixes: af0db57d4293 ("ntfs: update inode operations") Reported-by: yi <691464208@qq.com> Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 86f46508016bc1f2bffb3a52dc2664f942fb9802 Author: Pisit Preechapramoth Date: Tue Jul 28 21:58:58 2026 +0900 ntfs: reject unprivileged writes to reserved $LX* xattrs [ Upstream commit ea6a67ef64451d2da298f15baa35865b4bb6372a ] Reject setxattr of the reserved $LXUID, $LXGID, $LXMOD and $LXDEV names from userspace unless the caller has CAP_SYS_ADMIN. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Pisit Preechapramoth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 25a70f2ea77efc604ac1c2f9f595513c597d5c5e Author: Namjae Jeon Date: Mon Jul 27 18:07:15 2026 +0900 ntfs: respect per-file chmod mode over mount masks [ Upstream commit 4d730a4dd78caa7bf29dda36fa5340a0237a8689 ] fmask and dmask provide the default permissions for files without WSL metadata. Once chmod stores a mode in $LXMOD, however, that per-file mode must take precedence so selected files can retain permissions such as execute across remounts. Record whether $LXMOD was found while loading an inode and apply the mount masks only when it is absent. Do not remask the in-memory mode after setattr persists it. Continue loading $LXMOD even when optional $LXUID or $LXGID metadata is missing, since chmod may create only $LXMOD. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6028b94f28d9abfec0154157cc1effe15712be45 Author: Namjae Jeon Date: Sat Jul 25 12:00:00 2026 +0900 ntfs: apply Windows name checks only with windows_names [ Upstream commit 71feaa7686fb9cc08fc81c8a09d120b6204b51a0 ] The windows_names mount option is documented to reject names containing characters forbidden by Windows. However, ntfs_check_bad_windows_name() unconditionally rejects those characters before checking the mount option. Move the character validation after the option check so a default NTFS mount accepts POSIX names such as names containing ':'. Mounts using windows_names retain the existing Windows-compatible validation, including reserved device names and trailing spaces or dots. Fixes: af0db57d4293 ("ntfs: update inode operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 825dec5120933e90c54e30e31ccfa6c3449043a8 Author: Alexandro Calo Date: Fri Jul 17 12:14:51 2026 +0200 ntfs: Fix index_root heap OOB write in ntfs_ir_to_ib() [ Upstream commit dc09bf79b76f9a7157e225f449655f3f62f96c9c ] ntfs_ir_to_ib copies all entries from index_root into a freshly allocated index_block_size-byte buffer without verifying that the entries fit in the available space. The entries in index_root may be larger than the usable entry space in the index block. This can cause OOB writes past the end of the allocation. The validator ntfs_index_root_inconsistent() checks that entries are self-consistent within the IR value, but never cross-checks them against index_block_size. There is no bounds check in ntfs_ir_to_ib() before the memcpy. Fixing this at the sink in ntfs_ir_to_ib() since ntfs_index_root_inconsistent() validates the logical consistency of index_root as a structure and a root with large entries is a structurally valid root. The bug is a size conflict of ntfs_ir_to_ib(). Also, the validator is called once per inode load in ntfs_read_locked_inode() while ntfs_ir_to_ib() is only called during a reparent, a check there adds no overhead to the common path. Moreover, even a future call path that bypasses the validator would still be protected. With NULL as first parameter of ntfs_error(), the volume error flag is never set by this call, so the device name will be absent from the error message. In any case, that the caller, ntfs_ir_reparent(), prints an error message that includes the device name on NULL returns. I think this is the best solution available without adding 'struct super_block *sb' as a parameter to ntfs_ir_to_ib(). This heap out-of-bounds write is triggered by a crafted filesystem image, which is not in the kernel threat model, anyway, fixing memory errors would be nice to keep things secure. Fixes: 0a8ac0c1fa0b ("ntfs: update directory operations") Signed-off-by: Alexandro Calo Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 950e2ecc7aec21af24b05bc661a097a81c670409 Author: Namjae Jeon Date: Mon Jun 15 21:07:19 2026 +0900 ntfs: fix kmap_local_page() usage in compress [ Upstream commit 6e03fbd5f772ad24ea64f7632e4d0d73184787ca ] Several compressed I/O paths discard the address returned by kmap_local_page() and later access or unmap the page using page_address(). This is invalid for highmem pages, and local mappings must also be unmapped using the address returned by kmap_local_page(). Map each destination page in ntfs_decompress() only while producing the current sub-block. Use memcpy_from_page(), memcpy_to_page(), and memzero_page() for the other page accesses. Remove unnecessary local mappings from ntfs_write_cb(), where pages are accessed through the vmap() mapping. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Reported-by: Matthew Wilcox Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 825f4476ea60babbd4b4a24dd5eb4bd8d45b4d4e Author: Matthew Wilcox (Oracle) Date: Wed Jul 15 10:38:03 2026 +0900 ntfs: Remove references to page->__folio_index [ Upstream commit f6ce4cbcc53cf258ae0c8f77106f2eab40a1e412 ] Pages don't have indexes, folios have indexes. Correct this in ntfs_read_compressed_block() and also remove a use of page->mapping while I'm in here. Also convert the calls to unlock_page() and flush_dcache_page(). Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Matthew Wilcox (Oracle) Cc: Christoph Hellwig Cc: Hyunchul Lee Cc: Namjae Jeon Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 20224191755b0561e033473396d2772b80fd80eb Author: Matthew Wilcox (Oracle) Date: Wed Jul 15 10:38:02 2026 +0900 ntfs: Use zero_user_segment() in handle_bounds_compressed_page() [ Upstream commit 8a81803f87504ffd735f2a77f1299eadf2cbdf32 ] This fixes handle_bounds_compressed_page() on highmem memory as page_address() does not work on memory which has been kmap_local(), only on kmap() memory. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit cfa877fdae270d88fe992728a24a8f6f7adbe33e Author: Matthew Wilcox (Oracle) Date: Wed Jul 15 10:38:01 2026 +0900 ntfs: Remove use of __folio_index in handle_bounds_compressed_page() [ Upstream commit a3976da121aef2b9bf0709e0fd257b2a7ae2749c ] Nobody is supposed to use page->__folio_index. Use page_offset() instead, and simplify by working exclusively in loff_t instead of mixing up loff_t and pgoff_t. Link: https://lore.kernel.org/all/20260608210618.3437216-3-willy@infradead.org/ Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Matthew Wilcox (Oracle) Co-developed-by: Hyunchul Lee Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c13cd1124ec8b586859c52e985966d456caf627f Author: Matthew Wilcox (Oracle) Date: Wed Jul 15 10:38:00 2026 +0900 ntfs: Inline zero_partial_compressed_page() [ Upstream commit f98d80d51777e2c8a26efec9b86541b3b5a154ae ] zero_partial_compressed_page() has one caller and the next commit will make changes to it that make it inelegant to split across two functions. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e366735ed2a8a3dd255a106ef42de2a959c2db4b Author: Namjae Jeon Date: Tue Jul 14 14:50:34 2026 +0900 ntfs: rewrite EA stream before updating metadata [ Upstream commit 41e1cf4ec10d2338f9a206af0300c34ca63160c7 ] Updating an EA removes the old record and appends its replacement. Build the complete $EA stream in memory and rewrite it from offset zero, rather than committing a compacted stream followed by a separate append. generic/642 shows that the append path can leave an invalid record layout on disk, including when a new EA entry is added. When removing an EA, write the compacted stream before updating $EA_INFORMATION and restore the original pair if the metadata update fails. When the final EA entry is removed the $EA/$EA_INFORMATION pair is torn down. If removing $EA_INFORMATION fails after $EA has already been removed, the original $EA is restored so the two attributes stay consistent. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 62f39201c0ccd9d28533b87c41a0998592f18caf Author: Namjae Jeon Date: Tue Jul 14 14:50:01 2026 +0900 ntfs: remove empty EA attribute pair [ Upstream commit 772e4c8f25559e3b5c6c526253b3f771a4a4c02c ] Removing the final xattr leaves an empty $EA stream. An empty $EA attribute paired with $EA_INFORMATION is not a valid EA chain and ntfsck reports it as corrupt. Remove both attributes when the final EA entry is deleted. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 98af5b4ae138537acf7e457aaa045a1be5e6da7a Author: Namjae Jeon Date: Tue Jul 14 14:49:51 2026 +0900 ntfs: validate final EA attribute size [ Upstream commit 650a2751c9ae179fe0d8e5b5194a2b1c0d09412c ] A replacement first removes the existing EA record, then adds the replacement. Check the size of that final $EA stream before mutating the current stream. This avoids committing the shortened $EA stream or $EA_INFORMATION before discovering that the replacement exceeds the AttrDef size limit. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9fb0fed1b918d43a71d2787589d3f2ca321a5d64 Author: Besar Wicaksono Date: Thu Aug 13 17:01:55 2026 +0000 perf vendor events arm64: Fix Tegra410 Olympus event 0x0197 [ Upstream commit 9453bc6a69ef43755f1c28d5688cacdd69fa16bd ] The name and description for NVIDIA Tegra410 Olympus implementation-defined event 0x0197 incorrectly indicate a TXREQ limit between one quarter and one half. Correct them to describe a TXREQ limit below one half. Fixes: 86ff690f45cc ("perf vendor events arm64: Add Tegra410 Olympus PMU events") Signed-off-by: Besar Wicaksono Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b3ba86c6c5996ae8fe5ee656d6eec0fbf884f6c8 Author: Saurav Sachidanand Date: Thu Aug 13 17:01:54 2026 +0000 perf vendor events arm64: fix swapped MetricGroup for Tegra410 L1 prefetcher metrics [ Upstream commit 2d85e13c5526eee5f4d5670472a949f1489707ed ] The L1D prefetcher metrics (l1d_cache_rw_miss_ratio, l1d_demand_accesses, etc.) were incorrectly assigned to MetricGroup "L1I_Prefetcher_Effectiveness" and vice versa. This causes 'perf stat --metric-group L1D_Prefetcher_Effectiveness' to display L1I metrics, which is misleading. Swap the MetricGroup assignments so L1D metrics are in the L1D group and L1I metrics are in the L1I group. Fixes: 86ff690f45cc ("perf vendor events arm64: Add Tegra410 Olympus PMU events") Signed-off-by: Saurav Sachidanand Reviewed-by: Besar Wicaksono Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4af8e0f7838d40d6635e0c0609681c7d45af72b2 Author: Jian-Ming Liao Date: Tue Aug 18 18:41:04 2026 +0800 i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode [ Upstream commit 308ecb824db329a8e22dd0b10f2a3411a6fbbde3 ] In PIO mode initialization, STAT_IBI_STATUS_THLD was missing from pio->enabled_irqs. As a result, the host controller interrupt signal for IBI threshold was never enabled when transfer starts, preventing IBI status descriptors from being properly processed in PIO mode. Include STAT_IBI_STATUS_THLD in pio->enabled_irqs so that the IBI threshold interrupt is activated alongside error interrupts upon the first transfer. Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver") Co-developed-by: Patrick Yen Signed-off-by: Patrick Yen Signed-off-by: Jian-Ming Liao Reviewed-by: Frank Li Link: https://patch.msgid.link/20260818104106.763772-2-Jm_Liao@asmedia.com.tw Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 63ab05e8f9654aa100d366c0236399fda6ffaab1 Author: Tetsuo Handa Date: Sat Aug 15 15:50:13 2026 +0900 net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() [ Upstream commit 0b1c2af8a22c35cb099c735c2f63ea3ba757557d ] sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 ("net: add net device refcount tracker infrastructure") added ref_tracker_dir_exit() to only free_netdev() path. Closes: https://sashiko.dev/#/patchset/56c707e7-1fb0-43ec-b8fb-cf6f451e513e%40I-love.SAKURA.ne.jp Fixes: 4d92b95ff2f9 ("net: add net device refcount tracker infrastructure") Signed-off-by: Tetsuo Handa Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba5429c8c43e51d7b530d6feb2363209321e286e 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 1058c4379959c9aaecd9ab9b780dfdc604ec985b Author: Nikolay Kulikov Date: Mon Aug 10 22:10:02 2026 +0300 mlxbf-bootctl: fix the build error with FIELD_PREP() [ Upstream commit 46b14c6f11f558362391e308f4f184ee867ef58f ] rsh_log_store() calls the FIELD_PREP() macro without including the required header file, resulting a build error: CC drivers/platform/mellanox/mlxbf-bootctl.o drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’: drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration] 429 | data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG); | ^~~~~~~~~~ Fix this by including the file. Fixes: e9d1b2d0f7d0 ("mlxbf-bootctl: Add sysfs file for BlueField boot log") Signed-off-by: Nikolay Kulikov Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 1b0a3d915320f1600e5ff43f8bc21b73118480b8 Author: Hemanth Selam Date: Wed Aug 12 14:30:12 2026 +0530 platform/x86/amd/hsmp: Reject negative power cap writes in hwmon [ Upstream commit 3921bb8635ff2836622df1cdf3194d4f3c1835a4 ] hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works Fixes: 92c025db52bb ("platform/x86/amd/hsmp: Report power via hwmon sensors") Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 8a7499b8fd34438c1b11964e0e7ef5bd590fec92 Author: Guangshuo Li Date: Wed Jul 8 17:09:37 2026 +0800 platform/x86: hp-bioscfg: fix password encoding bounds check [ Upstream commit e213939ed9e6e6badf7aa48c4c8dd9a9cdf00615 ] The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values]. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0cc59397bbf94798b33d80579313ab7d6b8aad7c 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 491b368a0c6e5f28b615a50b0d384f5c25fde2a7 Author: Nguyen Dinh Phi Date: Fri Aug 14 01:30:18 2026 +0800 vsock: don't check the listener's sk_err in vsock_accept() [ Upstream commit b8c899cf5e7be29840a172c183dedd8d3e7a0287 ] Syzbot reported an issue which can be reproduced with these steps: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT}) connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 accept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 Suggested-by: Michal Luczaj Signed-off-by: Nguyen Dinh Phi Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260813173024.2362935-2-phind.uet@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cfcc833cb43b49edfae80803b3d86fb4f00d8694 Author: HyeongJun An Date: Fri Aug 14 22:25:35 2026 +0900 platform/x86: dell-wmi-sysman: Fix instance ID bounds [ Upstream commit 5ab078e3241da0beec2022254b5811a8a52cff84 ] The get_instance_id() macro walks the per-type attribute array with 'i <= instances_count'. Each array is allocated with exactly instances_count entries, so the valid range is [0, instances_count) and the last iteration reads one element past the end. On a name miss that out-of-bounds attribute_name is handed to strcmp(), which reads on until it finds a NUL byte. Every kobject in these ksets is built from an entry that was populated, so a miss does not look reachable from sysfs today. The bound is wrong either way and the read is out of bounds. The matching macro in hp-bioscfg carried the same off-by-one and was corrected by commit 25150715e0b0 ("platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro"). That macro takes a kobject pointer out of the out-of-bounds element and dereferences it, so it could fault. This one reads a char array. Use '<' to match the allocation. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit eddb191cc8d689f7bf6372366e61fc1b6a85bde3 Author: Mahanta Jambigi Date: Thu Aug 13 09:43:15 2026 +0200 net/smc: hash socket only after full initialisation in smc_sk_init() [ Upstream commit 8acf691d8017012e1476c30e7381513c1e929c94 ] smc_sk_init() calls sk->sk_prot->hash(sk) before several fields are fully initialised: clcsock_release_lock, the saved clcsk_* callbacks, use_fallback/fallback_rsn, and conn.close_work. Once hash() returns the socket is visible to concurrent hash walkers, which can then observe uninitialised state. Move hash(sk) to the end of smc_sk_init() so the socket is published only after it is fully constructed. Fixes: d0e35656d834 ("net/smc: refactoring initialization of smc sock") Reviewed-by: Hidayath Khan Reviewed-by: Sidraya Jayagond Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260813074315.554926-1-mjambigi@linux.ibm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b4ce1c461a49a2d3ef5f19abaae74a5f35e7b90a 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 f26400b325bdc2868e40612c4804c82cf8ba6275 Author: Baul Lee Date: Sat Aug 15 00:35:47 2026 +0900 vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() [ Upstream commit bc2dc66a6693a78f8c1e6ca2dbebd50f16e2c366 ] vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entries and the removed entries are (S, G) entries. It is therefore still linked and its next pointer reflects the removals. [1] BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588 Write of size 8 at addr dead000000000122 by task ip/327 CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 #2 PREEMPT Call trace: vxlan_mdb_entry_put.part.0+0x328/0x588 vxlan_mdb_flush+0x1d8/0x25c vxlan_mdb_fini+0x8c/0x100 vxlan_uninit+0x1c/0x7c unregister_netdevice_many_notify+0x954/0xd4c rtnl_dellink+0x210/0x530 rtnetlink_rcv_msg+0x434/0x4d0 netlink_rcv_skb+0xc4/0x204 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x548 netlink_sendmsg+0x29c/0x560 ____sys_sendmsg+0x390/0x3ec ___sys_sendmsg+0x114/0x188 __sys_sendmsg+0xf0/0x178 __arm64_sys_sendmsg+0x48/0x60 invoke_syscall.constprop.0+0x58/0x180 el0_svc_common.constprop.0+0x74/0x140 do_el0_svc+0x30/0x40 el0_svc+0x38/0x98 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Signed-off-by: Baul Lee Reviewed-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260814153547.29567-1-baul.lee@xbow.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 44764dc4b9f9b33c46e42c09909c8a8a7a2a4639 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 509f4a09bae7f03c87f67f053648874a5e177867 Author: Baokun Li Date: Sat Aug 8 12:13:39 2026 +0800 fuse: check for NULL root inode in fuse_fill_super_submount [ Upstream commit 928f659a3e3650978a5b4829cc982324f72b474b ] fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function. Fixes: 1866d779d5d2 ("fuse: Allow fuse_fill_super_common() for submounts") Signed-off-by: Baokun Li Reviewed-by: Jingbo Xu Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 710bbbbb66c7bb351b5f374692e0487d282a5a10 Author: Daniel Baluta Date: Mon Aug 17 15:35:41 2026 +0300 soc: qcom: ubwc: Fix missing include [ Upstream commit c6441becf4d064bb1dcbccbd3e2276833804cff5 ] When CONFIG_QCOM_UBWC_CONFIG=n, compiler needs to know the definition of ERR_PTR otherwise there will be a compilation error: In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7: ./include/linux/soc/qcom/ubwc.h: In function ‘qcom_ubwc_config_get_data’: ./include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of function ‘ERR_PTR’ [-Wimplicit-function-declaration] Fix this by including Fixes: 1924272b9ce1 ("soc: qcom: Add UBWC config provider") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Daniel Baluta Tested-by: Nathan Chancellor # build Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 236d65ecf377712928e9339e9fc8a8f7d015e13e Author: Baokun Li Date: Tue Aug 11 12:53:50 2026 +0800 fuse: reject a duplicate fd= mount option [ Upstream commit ed976994939f05ffbb6e9e5482adc788e679c0ea ] fuse_opt_fd() stored the fuse device in ctx->fud and bumped its refcount unconditionally: ctx->fud = fuse_dev_grab(file); If fd= is given twice (two fsconfig FSCONFIG_SET_FD calls), the second call overwrites ctx->fud and grabs the new device, while the reference taken on the first device is never released - a permanent refcount leak that pins the first fuse_dev until reboot. Reject a second fd= outright. ctx is zeroed on allocation, so a non-NULL ctx->fud reliably means the option was already processed. Fixes: d42eb23b2ef9 ("fuse: don't require /dev/fuse fd to be kept open during mount") Signed-off-by: Baokun Li Reviewed-by: Jingbo Xu Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit c8a109c9e23a2c7fd548473dde728b2cb8188146 Author: Weiming Shi Date: Wed Jun 24 21:00:38 2026 -0700 fs/ntfs3: validate ef->size covers the record's name and value [ Upstream commit c22f91d82cb9a29d22bdffdce6c803467984ad0c ] When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it. Fixes: 0e8235d28f3a ("fs/ntfs3: Check fields while reading") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 53e56f7aa1d0f950a8bc2e4cdb3ba9fe45967531 Author: Konstantin Komarov Date: Tue Aug 4 15:01:43 2026 +0200 fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() [ Upstream commit de603b9d377fab57a5e6432fa84a9f36b32c1636 ] read_log_rec_buf() copies a log record into a caller buffer starting at u32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. "tail = log->page_size - off" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei Signed-off-by: Weiming Shi [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c40f3f24839f8404325a2099e26c2a04786ae309 Author: Baokun Li Date: Fri Aug 14 21:40:15 2026 +0800 cuse: wait for pending RCU callbacks on module exit [ Upstream commit 4deb3edead0c0e172cc7349e8855d741d3c5e162 ] Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed. Fixes: 053fc4f755ad ("fuse: fix UAF in rcu pathwalks") Signed-off-by: Baokun Li Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 0dffaa477c2d5735d92af3e43fb9deed4a0b3061 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 adb27c5665bd26e04feb23bd2f962f25518bb0f6 Author: Maximilian Immanuel Brandtner Date: Thu Aug 13 14:09:44 2026 +0200 tls: fix RX desync on overlapping skbs [ Upstream commit 9466ef3ec972bee926731a766f73533dec590065 ] The TCP receive queue can hold adjacent skbs whose sequence ranges overlap. The tls fast-path reads the record header with skb_copy_bits() by byte offset, which assumes skbs do not overlap, so a header split across the overlap is misread and the connection aborts (-EMSGSIZE/-EINVAL). tls_strp_check_queue_ok() detects such overlaps but only ran after the header was parsed, never covering the header itself. Observed with parallel kTLS connections on: - ConnectX-7 + IPsec crypto offload + GRO - VirtIO (8 queues) + GRO Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Maximilian Immanuel Brandtner Link: https://patch.msgid.link/20260813121337.3300688-1-maxbr@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38ce7de7215ad4684cd8ba6e2ecd96edd8e893e9 Author: Ruoyu Wang Date: Thu Aug 13 23:31:31 2026 +0800 net: dsa: mv88e6xxx: Fix PCS link check on CMODE read error [ Upstream commit 7b196e27ad58e612ad1c04b347d0c2135045aa14 ] mv88e6352_pcs_link_check() ignores errors returned by port_get_cmode(). If the port status register read fails, mv88e6352_port_get_cmode() returns without setting cmode. The link check then compares an uninitialized value and may incorrectly treat the PCS as active. Save the return value and fail the link check after releasing the register lock. marvell_c22_pcs_get_state() initializes the reported link state to down before calling the check, so a read failure is handled safely until a later poll succeeds. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85764555442f ("net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs") Signed-off-by: Ruoyu Wang Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260813153131.3952970-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad32e564c62ebf5ba76dd60a22af52c69d54d17b Author: Xiang Mei Date: Wed Aug 12 14:53:41 2026 -0700 vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes [ Upstream commit 984f831dda31b3a18f47454cf64989f65402879e ] The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width. Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260812215341.763123-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1908bff0faaa94d55be72da65879cad632e8236 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 454c59ef2dd0bbfdb41ca0522ae3085eb3977acb Author: Pablo Neira Ayuso Date: Wed Aug 12 10:03:38 2026 +0200 netfilter: ctnetlink: do not expose expectation DEAD flag [ Upstream commit 322371b09058ad10d0282a0e7ec8eaa764e6aaac ] Expose expectation flags included in the NF_CT_EXPECT_MASK bitmask only. The DEAD flag is internal, do not expose it. Fixes: b8b09dc2bf35 ("netfilter: nf_conntrack_expect: use conntrack GC to reap expectations") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6a31c661ba1e18fdcbeeccf98b56cde9e7089ee2 Author: Florian Westphal Date: Fri Aug 7 02:28:08 2026 +0200 netfilter: ipset: remove need to allocate memory on delete operations [ Upstream commit e80456d79ec83b00a6bd44c377684b1632ccc3c7 ] Allocating mem via GFP_ATOMIC on delete is problematic, delete operations should always succeed. Do in-place substitution: When /cidr reaches 0 count (no more elements in the range), move ranges stored later in the array forward and keep the count 0 ones at the end. INIT_CIDR() can then check count == 0 without a need to search next element in the array. To avoid problems on weakly ordered architectures, pack the structure so it is only 32bit wide, then use READ/WRITE_ONCE to store both cidr and count. atomically. Also update comments to mention the possible presence of ignored 0-count-0-cidr structures at the end and need for seqcount. seqcount is used to restart. This avoids bogus range misses. Given: [0]: /29 [1]: /24 cpu1 reads slot 0. then, right after, cpu2 removes /29. count drops to 0, so it updates array to: [0], /24, [1], /0 (count 0). cpu1 then skips /28: slot 0 was already visited, but slot 1 already replaced. Note that mtype_add() doesn't check mtype_add_cidr() return value. Doing this here is useless noise as this code is extensively rewritten in the rhashtable replacement patch. Assisted-by: Claude:claude-sonnet-5 Fixes: 8e5fd2a55e24 ("netfilter: ipset: rework cidr bookkeeping") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 44ff26872e241386b3af3d5f0d399a233a0e13f4 Author: Chao Yu Date: Wed Aug 12 12:20:08 2026 +0000 f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode [ Upstream commit 0a1703eba23707e3b2edfa2a2329352e7abc0ffa ] pinfile fallocate() conflicts w/ mode=fragment:{block,segment} mount option, result in fragment blocks in pinfile, it violate semantics of pinfile introduced in commit f5a53edcf01e ("f2fs: support aligned pinned file"). mkfs.f2fs -f /dev/vdb mount -t f2fs -o mode=fragment:block /dev/vdb /mnt/f2fs/ dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=3900 sync touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile f2fs_io fallocate 0 0 $((1024*1024*16)) /mnt/f2fs/pinfile sync f2fs_io fiemap 0 $((1024*1024*16)) /mnt/f2fs/pinfile [Before] fallocate failed: No space left on device Fiemap: offset = 0 len = 16777216 logical addr. physical addr. length flags 0 0000000000000000 00000000d7200000 0000000000004000 00001000 1 0000000000004000 00000000d7207000 0000000000001000 00001000 2 0000000000005000 00000000d720c000 0000000000002000 00001000 3 0000000000007000 00000000d7211000 0000000000001000 00001000 4 0000000000008000 00000000d7214000 0000000000001000 00001000 5 0000000000009000 00000000d7218000 0000000000001000 00001000 6 000000000000a000 00000000d721d000 0000000000001000 00001000 7 000000000000b000 00000000d721f000 0000000000004000 00001000 ... 96 00000000000f1000 00000000d73e9000 0000000000004000 00001000 97 00000000000f5000 00000000d73f1000 0000000000003000 00001000 98 00000000000f8000 00000000d73f5000 0000000000004000 00001000 99 00000000000fc000 00000000d73fa000 0000000000001000 00001000 100 00000000000fd000 00000000d73ff000 0000000000001000 00001001 [After] fallocated a file: i_size=16777216, i_blocks=32808 Fiemap: offset = 0 len = 16777216 logical addr. physical addr. length flags 0 0000000000000000 0000000018a00000 0000000000400000 00001000 1 0000000000400000 0000000019000000 0000000000400000 00001000 2 0000000000800000 0000000032400000 0000000000200000 00001000 3 0000000000a00000 0000000038000000 0000000000200000 00001000 4 0000000000c00000 0000000039c00000 0000000000200000 00001000 5 0000000000e00000 0000000044c00000 0000000000200000 00001001 Let's ignore mode=fragment:{block,segment} mount option while fallocate() on pinfile. Fixes: 6691d940b0e0 ("f2fs: introduce fragment allocation mode mount option") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 87abc928271cb85de83ce3c5e813297ed8288a0d Author: Chao Yu Date: Wed Aug 12 12:20:07 2026 +0000 f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk} [ Upstream commit 6da62bbde487d4678702ef004a911cd1c7a5c746 ] No logic changes. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 0a1703eba237 ("f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode") Signed-off-by: Sasha Levin commit 8344c9233c8f77017174d9e280c5a26034d068b6 Author: Anton Protopopov Date: Mon Aug 10 12:07:25 2026 +0000 virtio_net: Fix resize of the RX ring [ Upstream commit d09c98a6da215bce2173a292e4b95c8de6ea5d51 ] When a AF_XDP socket is attached, the virtnet_rx_resize should resize the rq->xsk_buffs XSK buffer array. Otherwise, when the size grows, the virtnet_rx_resume() causes a write past the end of the array. This is easily reproducable with ethtool -G ens3 rx 32 ./xdpsock -i eth0 -q 0 -r -z & ethtool -G eth0 rx 256 Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") Signed-off-by: Anton Protopopov Link: https://patch.msgid.link/20260810120728.47445-1-a.s.protopopov@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 49b01f2939abc676a6f9a118f07a10110ee5f683 Author: Xin Xie Date: Sat Aug 8 13:08:14 2026 +0200 net: hsr: free learned nodes on device setup failure [ Upstream commit 7f16289b91eb316f170a6bd22d32e6c632f6a5b6 ] hsr_dev_finalize() can fail after a lower-device RX handler has already been registered (slave A is added before the failable slave B and interlink adds). RX handlers run in softirq regardless of the master's state, so frames received in that window can learn dynamic nodes into node_db, and the error unwind never releases them. Free both owned dynamic databases in the unwind, mirroring hsr_dellink(). proxy_node_db is provably empty on every current error exit (only interlink RX feeds it, and the interlink add is the last failable step) and is freed for symmetry. The order is safe: hsr_del_port() unregisters each RX handler with synchronize_net() before hsr_del_nodes() runs, which removes remaining entries with list_del_rcu() and defers their release with call_rcu() for readers already under RCU. Fixes: 81ba6afd6e64 ("net/hsr: Switch from dev_add_pack() to netdev_rx_handler_register()") Signed-off-by: Xin Xie Link: https://patch.msgid.link/20260808110814.1637-1-xiexinet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 23fc79697224cb692daf800b9d36d0d8123a10da 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 93462180871bb047e1db6f3c7bf5d06989647ac1 Author: Vladimir Oltean Date: Wed Aug 12 23:11:21 2026 +0300 net: dsa: b53: fix error propagation from b53_fdb_dump() [ Upstream commit 4f1d06cf8aaa9d2cb18e5ee8835aff6177256bc6 ] The blamed commit replaced "return ret" statements in b53_fdb_dump() with "break;" which jumps to the mutex_unlock() -> return 0 section. This is notably problematic because it swallows errors from the b53_fdb_copy() -> cb() path, and this will result in FDB dump truncation when the netlink skb overflows - see commit 21b52fed928e ("net: dsa: sja1105: fix broken backpressure in .port_fdb_dump"). Let's go back to "return ret". We don't need to preinitialize "ret" with 0, because the "do {} while" block guarantees we cannot reach the end of the function without at least once calling b53_arl_search_wait(), which will have initialized ret to some valid value. Fixes: f7eb4a1c0864 ("net: dsa: b53: serialize access to the ARL table") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260812201121.2012356-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f392affef3c9ce64dfdde794df0579e0a7793440 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 fdbf04e3e01a872d0ef2149f846f1a3e3cb54f5b Author: Petr Oros Date: Thu Aug 13 16:08:17 2026 +0200 dpll: fix NULL deref in dpll_device_ops() during teardown race [ Upstream commit 33f016b23a219fe034213849b51436b8e79df251 ] When the last owner of a dpll device unregisters while a foreign driver still holds a pin on it via dpll_pin_on_pin_register(), the dpll object stays alive with an empty registration list. A pin notification queued before the unregister (e.g. ice reacting to zl3073x_i2c removal) then walks pin->dpll_refs into dpll_device_ops(), which trips the WARN_ON and dereferences the missing registration. dpll_lock cannot help because the notification work was queued before the unregistering driver took the lock. Treat the empty registration list as a legitimate transient state. Make dpll_priv() and dpll_device_ops() return NULL in that case and make every pin netlink path that resolves a device from a pin skip such dplls. dpll_cmd_pin_get_one() picks a ref with a live registration and returns -ENODEV when there is none, the pin dumpit skips such a pin instead of aborting the dump, dpll_msg_add_pin_dplls() and the frequency, esync, reference sync and phase adjust set paths skip dead refs, and dpll_pin_parent_device_set() validates the parent with dpll_device_get_by_id(). dpll_pin_register() is the last caller that dereferenced the device ops without a check, so move its frequency monitor validation under dpll_lock and tolerate a missing registration there as well. The empty registration list is equivalent to a cleared DPLL_REGISTERED mark, both transitions happen under dpll_lock in dpll_device_register() and dpll_device_unregister(). A pin notification for a pin whose dplls are all gone is now dropped with -ENODEV instead of crashing, all callers in the core ignore that return value. WARNING: drivers/dpll/dpll_core.c:1092 at dpll_device_ops+0x24/0x40, CPU#83: kworker/u576:3/23471 Modules linked in: ... ice ... zl3073x_i2c(-) ... zl3073x ... Workqueue: ice_dpll_wq ice_dpll_pin_notify_work [ice] RIP: 0010:dpll_device_ops+0x24/0x40 Call Trace: dpll_cmd_pin_get_one+0x336/0x520 dpll_pin_event_send+0x82/0x140 dpll_pin_on_pin_unregister+0xbb/0x160 ice_dpll_pin_notify_work+0x1bc/0x1f0 [ice] process_one_work+0x19e/0x370 worker_thread+0x1a6/0x310 kthread+0xe4/0x120 ret_from_fork+0x1a1/0x270 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Petr Oros Tested-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260813140817.1051388-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 122d0db84b11cf3e349e7fa2e581904db4ea7711 Author: Prabu Thayalan Date: Tue Aug 11 12:50:39 2026 -0700 ionic: fix completion descriptor access with 2x desc size [ Upstream commit 5da6ec6f06f235166bd084466b3386c638e26675 ] The old ionic_rx_service() and ionic_tx_service() used array indexing to access completion descriptors: comp = &((struct ionic_rxq_comp *)cq->base)[cq->tail_idx]; This assumes the stride is sizeof(struct ionic_rxq_comp) = 16 bytes. However, when the IONIC_Q_F_2X_CQ_DESC flag is set, the actual completion descriptor size is 32 bytes (2 * sizeof(comp)), and the completion itself is located at the end of that 32-byte slot. Array indexing with a 16-byte stride would access the wrong offset. Use pointer arithmetic that accounts for the actual descriptor size from cq->desc_size: comp = cq->base + cq->desc_size * cq->tail_idx + cq->desc_size - sizeof(*comp); This correctly calculates the completion location regardless of descriptor size. For the common case where desc_size equals sizeof(*comp), use array indexing in a likely() fast path to avoid performance regression. Fixes: 65e548f6b0ff ("ionic: remove the cq_info to save more memory") Signed-off-by: Prabu Thayalan Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811195039.1315045-3-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 242d2d8bfc09f9862c04ef80afd49f71e917b92b Author: Eric Joyner Date: Tue Aug 11 12:50:38 2026 -0700 ionic: add missing dma_rmb() after the completion publish check [ Upstream commit 621f44af8c5b373de2b2e19a4a8db9e45c3c659a ] Each completion service routine tests a device-written publish flag and then reads the rest of the descriptor with nothing ordering those loads. A control dependency does not order loads, so a weakly ordered CPU may satisfy the payload reads from a cache line state observed before the flag became valid. Add the barrier to all four completion paths. Fixes: 1d062b7b6f64 ("ionic: Add basic adminq support") Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Fixes: 77ceb68e29cc ("ionic: Add notifyq support") Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811195039.1315045-2-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ed5e2a3c306d51bf550cbf99ba5e0b7564e0e41 Author: Wei Fang Date: Tue Aug 11 16:36:14 2026 +0800 ptp: netc: skip PEROUT disable if channel is not enabled [ Upstream commit 273480bb836e515353f30a1e70b21a2382de666e ] When userspace calls ioctl(PTP_PEROUT_REQUEST) with period = 0 to disable a PEROUT channel that is not enabled, the driver incorrectly enters the disable path. Since the channel's struct netc_pp was previously zeroed, pp->alarm_id evaluates to 0, causing priv->fs_alarm_bitmap &= ~BIT(0) to silently revoke the alarm 0 allocation from whichever channel is actively using it. This can cause two channels conflict over the same hardware alarm configuration and corrupt their periodic output signals. Therefore, guard the disable path with a check on pp->enabled and return early if the channel is not enabled. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Reported-by: Sashiko Closes: https://sashiko.dev/#/message/20260809031908.46EBF1F00A3A%40smtp.kernel.org Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260811083614.3589967-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 851f2f82483dda560ad3951cd99bef76c909da94 Author: Dan Carpenter Date: Thu Aug 13 10:09:47 2026 +0300 drm/xe: tests: fix error message in xe_migrate_sanity_test() [ Upstream commit 3d318fe4e99a627aa3c2980699e2e9f13ad18516 ] This is supposed to print the error code but there is a copy and paste bug so it prints "bo" instead of "err". Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1tu0z3T-qX1ogn@stanley.mountain Signed-off-by: Rodrigo Vivi (cherry picked from commit 28a4198c52a1468fc1b620a9837557ea1dc1766d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 96c3959770386b2913c62005f0d0c3151e0c01c3 Author: Fan Gong Date: Tue Aug 11 19:43:59 2026 +0800 hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed [ Upstream commit d0c2bed6927cbfa2cb51f240b4812bf6916bce0e ] Previously, hinic3_send_one_skb() cached the skb fragment count before calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to skb_checksum_help() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults. Furthermore, the old code ignored the return value of skb_checksum_help(), transmitting corrupted packets with incomplete checksums upon failure. Fix this by: 1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skb_checksum_help() errors and returning HINIC3_TX_OFFLOAD_INVALID to properly drop the skb. Fixes: 17fcb3dc12bb ("hinic3: module initialization and tx/rx logic") Co-developed-by: Teng Peisen Signed-off-by: Teng Peisen Co-developed-by: Wu Di Signed-off-by: Wu Di Signed-off-by: Fan Gong Reviewed-by: Simon Horman Link: https://patch.msgid.link/78d8c61cab588240948eaddcb437d59add9f77ae.1786448013.git.tengpeisen@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcd89fdf033bad067dde914010790f540f8db6d5 Author: Karl Mehltretter Date: Wed Aug 12 08:07:30 2026 +0200 octeontx2-af: initialize lmac_bmap in rvu_mcs_set_lmac_bmap() [ Upstream commit 4b92a3710d4a1d850ed6421c773e735cdca69b07 ] rvu_mcs_set_lmac_bmap() declares lmac_bmap without initializing it and only sets bits for valid lmacs with set_bit(), which ORs into the word without clearing it first. Bits for invalid or skipped ports keep whatever was on the stack, and the garbage is stored into mcs->hw->lmac_bmap. Initialize lmac_bmap to 0 so only valid lmacs are marked. Found with Clang's -Wconditional-uninitialized. Fixes: ca7f49ff8846 ("octeontx2-af: cn10k: Introduce driver for macsec block.") Signed-off-by: Karl Mehltretter Reviewed-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260812060730.6181-1-kmehltretter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 677b4c6e8c27c9fb7408871771cf2cf1bbfeb428 Author: bui duc phuc Date: Wed Jul 8 10:05:12 2026 +0700 can: m_can: Use of_property_present() for wakeup-source [ Upstream commit 966506838a4a8f51abcac8db67e6c2980f366134 ] The 'wakeup-source' property is declared as a phandle-array in both YAML bindings and Device Tree source files. However, the driver currently uses of_property_read_bool() to check for its existence. According to the function's documentation, usage on non-boolean property types is deprecated. Switch to of_property_present() to comply with the recommended API for checking the presence of a property. Fixes: 04d5826b074e ("can: m_can: Map WoL to device_set_wakeup_enable") Reviewed-by: Kendall Willis Acked-by: Markus Schneider-Pargmann Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260708030512.8570-1-phucduc.bui@gmail.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 03022dd874070768a7099f18b1944c633641315f Author: Jiayuan Chen Date: Wed Aug 12 14:36:11 2026 +0800 bpf, xdp: move offload check into dev_xdp_install() [ Upstream commit ad27ed7d2309419a129078d781504f486b1b469a ] bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: "ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach(). Fixes: 026a4c28e1db3 ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link") Signed-off-by: Jiayuan Chen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33bcf2dd2fd6135c723155885fc860a4482e3dc5 Author: Mario Rugiero Date: Sat Aug 15 20:22:29 2026 -0300 regulator: tps65185: wait for the IC to wake before the first I2C access [ Upstream commit 44f7b876b7c6c7b3a219b7a810d3d9548df21540 ] The probe drives WAKEUP high with GPIOD_OUT_HIGH, enables the input supply, and then issues a regmap_update_bits() on INT_EN2 with no wait anywhere in between. The TPS65185 data sheet (TI SLVSAQ8G, February 2011, revised September 2017), section 7.6 "Timing Requirements: Data Transmission", Figure 2 "Power-Up and Power-Down Timing Diagram", footnote 1, requires 1.8 ms minimum between the WAKEUP rising edge and the IC being ready to accept an I2C transaction. The driver calls no delay function anywhere, and nothing on that path is guaranteed to take that long. On an RK3026 board the first transfer was NAKed: tps65185 0-0068: error -ENXIO: failed to enable temp irq -ENXIO here is rk3x_i2c reporting REG_INT_NAKRCV. Probe failed, so vposneg never registered and its consumer deferred indefinitely. Wait after the supply rather than at the gpiod_get(). Figure 2 times that 1.8 ms from a WAKEUP edge with VIN already up, whereas this driver asserts WAKEUP before enabling vin-supply; the data sheet does not describe that order, so on a board whose vin-supply is a switched regulator that was off, a wait placed at the gpiod_get() could elapse before the part had power. Waiting from whichever of the two comes last satisfies the specified case and is the conservative choice in the other. It also goes above the interrupt request rather than immediately before the INT_EN2 write, because that write is not necessarily the first transfer: tps65185_irq_thread() reads INT1 and INT2, and it is requested with IRQF_TRIGGER_LOW, so it can run as soon as the handler is installed. Tested on an ONYX BOOX C67ML (RK3026): the chip now probes, all three regulators register and the EPD controller comes up. Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver") Signed-off-by: Mario Rugiero Link: https://patch.msgid.link/20260815232229.68474-1-mrugiero@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit df9c1cd0c6e8a0d3b93ce78b69d73f1f0f9f183a Author: Mathieu Dubois-Briand Date: Mon Jul 27 09:41:40 2026 +0200 clk: ti: mux: resolve parent clocks by DT index, not by name [ Upstream commit 667f420c09f1417c9f07798e32432c901915209d ] Resolve parent clocks by their index into the device tree "clocks" property rather than matching names as strings. Name-based matching is fragile because a clock's "clock-output-names" value in its provider node can differ from the name used to reference it in a consumer node, and because names must be globally unique across all clock providers. On AM335x, this caused broken clock trees where some clocks failed to enable because their parents could not be found. Replace of_clk_parent_fill() with a clk_parent_data array that sets .index to the array position. Fixes: ec7aa25fa483 ("ARM: dts: Use clock-output-names for am3") Signed-off-by: Mathieu Dubois-Briand Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 647157fecb42b72d930e7b7d0bfbc5f2db9a858a Author: Onur Özkan Date: Sat Aug 1 14:16:34 2026 +0300 clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() [ Upstream commit 0d4d262c1664365e17e0a5ba2ab79f4db484b44e ] devm_clk_get_optional_enabled_with_rate() registers its cleanup action before setting the clock rate. If setting the rate fails, it attempts to disable and unprepare a clock that was never enabled. This issue was spotted while reviewing "rust: clk: add devres-managed clks" [1]. Register the cleanup action only after successfully preparing and enabling the clock. [1]: https://lore.kernel.org/rust-for-linux/20260706-clk-type-state-v5-3-67c5f326a16c@collabora.com Fixes: 9934a1bd45b2 ("clk: provide devm_clk_get_optional_enabled_with_rate()") Signed-off-by: Onur Özkan Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7582a485870a90b9cce429c5f7fc283dbee59c11 Author: Michael Nemanov Date: Thu Aug 6 13:13:58 2026 +0000 nfs: fix ENXIO on O_CREAT open of existing symlink over NFSv3 [ Upstream commit 10f307e525a1783570a39eb9ac146d45f4f16b3e ] When open(2) is called with O_CREAT on a path that already exists as a symlink, over an NFSv3 mount with a cold dcache, the kernel returns ENXIO instead of following the symlink to its target. Reproducer script (MNT is an NFSv3 mount, kernel is 7.1-rc6): MNT=/mnt/export ln -sf /tmp/target $MNT/mylink echo 3 | sudo tee /proc/sys/vm/drop_caches # cold dcache python3 - <<'EOF' import os fd = os.open('/mnt/export/mylink', os.O_WRONLY | os.O_CREAT | os.O_APPEND, 0o666) os.close(fd) EOF Expected: success (follow symlink, open target) Actual: OSError: [Errno 6] No such device or address The bug does not trigger when the dcache is warm (e.g. after a prior stat(2)), because lookup_open() then finds a positive dentry and skips atomic_open entirely, leaving symlink resolution to the VFS. Root cause: nfs_atomic_open_v23(), registered as inode->i_op->atomic_open for NFSv3, handles O_CREAT by sending a CREATE UNCHECKED RPC. As implemented in nfsd3_create_file() (fs/nfsd/nfs3proc.c) and as required by RFC 1813 (3.3.8), when the name already exists as a non-regular file the server returns NFS3_OK with the existing object's file handle rather than NFS3ERR_EXIST causing nfs_do_create() to return 0 with the dentry now pointing to a symlink. The code then unconditionally calls finish_open(), which dispatches through inode->i_fop->open(). Symlink inodes never have i_fop set — the VFS initialises it to &no_open_fops because POSIX requires open(2) to follow symlinks, never open them directly. no_open() returns -ENXIO. Fix: After nfs_do_create() succeeds, verify the returned inode is a regular file before calling finish_open(). If the object is not regular, return finish_no_open(file, NULL) so the VFS follows the symlink through the normal open path. NULL is passed because nfs_do_create() instantiates the inode on the dentry already owned by the caller; passing dentry back would cause atomic_open() to dput() it a second time. !S_ISREG() is used rather than S_ISLNK() to cover any other non-regular types a server might return. Changes in v2: - Pass NULL to finish_no_open() per Trond's feedback. Fixes: 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.") Link: https://lore.kernel.org/linux-nfs/20260614122911.3485467-1-michael.nemanov@vastdata.com/ (v1) Signed-off-by: Michael Nemanov Tested-by: Michael Nemanov [trond.myklebust@hammerspace.com: use d_is_reg() to catch negative dentries] Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d179ff22cd8514f966966fd9ad425dcbb98e1ada Author: Zhansong Gao Date: Thu Jul 23 04:00:59 2026 +0800 NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() [ Upstream commit 468e458ffde907ba19acd2102ca1fbb8f6fbede2 ] When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease(). Fixes: e93a5e9306a5 ("NFSv4: Add support for application leases underpinned by a delegation") Signed-off-by: Zhansong Gao Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 436a214514e24103159aea455147d58b44a8a585 Author: Jeuk Kim Date: Wed Jul 8 16:44:32 2026 +0900 NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers [ Upstream commit 2b03ebbf8d5e8f6af4ecd6c65375232dd1ec32cc ] flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so I/O to a v4.0 flexfiles DS oopses: - nfs4_init_ds_session() dereferences clp->cl_session->session_state while seeding the DS lease. It also only seeds cl_lease_time when NFS4_SESSION_INITING is set; without a session that never happens, so cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing every 5 seconds. Seed the lease whenever there is no session and return before touching session state. - ff_layout_async_handle_error_v4() dereferences clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the v4.0 transport slot table (clp->cl_slot_tbl) when there is no session. Fixes: a7878ca14008 ("nfs: flexfilelayout: remove v3-only data server limitation") Signed-off-by: Jeuk Kim Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c9c67f7107f74f61b7c8c81fbcea3803b5d0ad55 Author: Guangshuo Li Date: Sun Jul 5 00:42:17 2026 +0800 NFS: Fix delayed delegation return list handling [ Upstream commit 68c03755577ac90e31e38c7ec787301cf6be5331 ] The delayed delegation return handling added a separate delegations_delayed list to keep delegations whose return needs to be retried later. The delayed list is then spliced back to delegations_return by nfs_server_clear_delayed_delegations(), which also causes the state manager to retry the delegation return. However, nfs_end_delegation_return() still moves delayed delegations to delegations_return instead of delegations_delayed. As a result, the new delayed list is never populated, nfs_server_clear_delayed_delegations() always returns false, and NFS4CLNT_DELEGRETURN is not set again to drive a retry. Move delayed delegations to delegations_delayed so that the delayed return path can splice them back to delegations_return and schedule the retry as intended. Fixes: 4039fbedcbcb ("NFS: fix delayed delegation return handling") Signed-off-by: Guangshuo Li Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 23e4162405c456ce12c772d5882d306135e828ae Author: ZhangGuoDong Date: Thu Jun 25 11:20:38 2026 +0800 pnfs/blocklayout: Fix device leaks on parse failure [ Upstream commit c056f817e4200fb18079d5052c273a22f191ff0a ] bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: ZhangGuoDong Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 5891c03e150920618db0e9c4ea2d772abacdcfd1 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 a30e2a3353094cc09ae8874a92001133fbcb9ae2 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 2e8a725cdb645f32235277baa509b11d254c31ad 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 8e29e6c43f9de6e5322ee27132e551924dae0d56 Author: Andrii Nakryiko Date: Fri Aug 14 16:20:17 2026 -0700 selftests/bpf: Retry stat generation in cgroup_iter_memcg [ Upstream commit 3d9393ff98ca9a132c7a0778436f5ed856fb3dc6 ] Each cgroup_iter_memcg subtest touches 1024 pages and expects the matching memcg counter to be non-zero. On a host with many CPUs it reads zero instead: test_anon:FAIL:final anon mapped val: actual 0 <= expected 0 memcg stats are cached per-cpu and only become visible once the periodic flusher runs (FLUSH_TIME, 2s), or once pending updates cross MEMCG_CHARGE_BATCH * num_online_cpus(). That threshold is 512 pages at 8 CPUs but 8192 at 128, so a single pass no longer reaches it and bpf_mem_cgroup_flush_stats() returns without flushing anything. Retry the stat generation, sleeping in between, so that a flusher cycle is always covered. Sleep before dropping the mapping, so that a flusher cycle landing in the sleep observes the mapped state. nr_anon_mapped and nr_file_mapped are rmap gauges, and unmapping first would post a matching negative delta for the flusher to aggregate to a net zero. test_file asserts on both nr_file_pages and nr_file_mapped, which have different lifetimes, as page cache pages outlive the mapping. Retry while either one is still zero. Fixes: 6bce6ddbe634 ("bpf: selftests: selftests for memcg stat kfuncs") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260814232017.2839959-1-andrii@kernel.org Signed-off-by: Sasha Levin commit f075148f3eebbbf08e21d4565cd027634c5aafab Author: Ze Tan Date: Fri Aug 14 13:51:44 2026 +0000 smb/server: fix session counter on session removal [ Upstream commit 7de5cf9bcf96bf2ee2ea2ad1d35a7b950f71161a ] See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_counter_inc(KSMBD_COUNTER_SESSIONS) ksmbd_conn_handler_loop ksmbd_server_terminate_conn ksmbd_sessions_deregister hash_del(&sess->hlist) // do not decrement KSMBD_COUNTER_SESSIONS KSMBD_COUNTER_SESSIONS tracks sessions published in sessions_table, but session removal does not decrement it. The value therefore keeps growing after sessions are expired, rejected during registration, or removed on the last channel disconnect. Fixes: b38f99c1217a ("ksmbd: add procfs interface for runtime monitoring and statistics") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f31178bb91cdb03c2854ecdce6f2de7842cdc985 Author: Ze Tan Date: Fri Aug 14 13:51:43 2026 +0000 smb/server: update session counter under sessions table lock [ Upstream commit 492b24b5b651a72ee83a8d481f70246b36192832 ] KSMBD_COUNTER_SESSIONS tracks sessions published in sessions_table. Increment it while holding sessions_table_lock so publishing a session and updating the counter happen together. Fixes: b38f99c1217a ("ksmbd: add procfs interface for runtime monitoring and statistics") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 46bb82a539020e43e03c24c9e7428d3588dc90b8 Author: Ze Tan Date: Fri Aug 14 13:51:41 2026 +0000 smb/server: warn if ksmbd_proc_create() fails [ Upstream commit 9a74739026fb71d1197183a067eef657bb5fba77 ] Print a warning if the sessions procfs entry cannot be created. Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Stable-dep-of: 492b24b5b651 ("smb/server: update session counter under sessions table lock") Signed-off-by: Sasha Levin commit c949ea4edccfc03d692c7c49d55999a3ccc7d68d Author: Namjae Jeon Date: Sun Jun 28 15:41:18 2026 +0900 ksmbd: add procfs monitoring for active shares [ Upstream commit 1248f400e0997b6e881454488baaf91f8e1828d5 ] There is no kernel-side view of the share configurations currently cached by active tree connections. Add a shares proc entry that reports each active share name, type, tree-connection count, create masks, and descriptive configuration flags. Maintain a per-share tree-connection counter with the existing global counter so the value can be read without walking every session. Signed-off-by: Namjae Jeon Stable-dep-of: 492b24b5b651 ("smb/server: update session counter under sessions table lock") Signed-off-by: Sasha Levin commit 55c677619084f9c9fa4146d933cc8ccafc924c87 Author: Ze Tan Date: Fri Aug 14 13:51:42 2026 +0000 smb/server: fix session leak in ksmbd_session_register() [ Upstream commit 99b25b046e47e4904373cfeb445c5483f1633d88 ] See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails. Fixes: f5c779b7ddbd ("ksmbd: fix racy issue from session setup and logoff") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8e4f75e979c1d9a51b0a48ac33d0cfd5f039ec67 Author: Hang Nan <2122295973@qq.com> Date: Mon Aug 17 09:52:45 2026 +0900 ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size [ Upstream commit 79decd88dd3f0d42e7fb0689b1a7853bfa302459 ] smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64 Fixes: 8f0541186e9a ("ksmbd: fix heap-based overflow in set_ntacl_dacl()") Signed-off-by: Hang Nan <2122295973@qq.com> Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ce92f3cc7ee48f2b6dee1f1e2b82151d39042699 Author: Namjae Jeon Date: Sun Aug 16 15:33:04 2026 +0900 ksmbd: handle encrypted compressed requests [ Upstream commit 6639b6928ba22dd6750ff3c6f6de77715cf46d50 ] SMB3 permits a message to be compressed before it is encrypted. After decrypting such a request, ksmbd must trim the AEAD tag using OriginalMessageSize, decompress the nested compression transform, and validate the resulting SMB2 PDU. Share the decompression helper between the connection receive path and the post-decryption work path so unencrypted and encrypted compressed requests follow the same validation. Fixes: a08de24c2b85 ("ksmbd: negotiate and decode SMB2 compression") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6f04e11d500b83b219e6271b78c5bb14265c3164 Author: Namjae Jeon Date: Sun Aug 16 13:46:36 2026 +0900 ksmbd: decrypt requests from expired encrypted sessions [ Upstream commit d8fc4fc7e57fc2bfd45699a10ee0df8ab9dccfa5 ] Previous-session replacement marks the old session expired but retains its SMB3 encryption key. An in-flight encrypted request can still arrive on that connection. Rejecting the expired session before decryption made ksmbd treat the request as a key failure and abort the transport, causing reconnect failures. Allow key lookup for expired sessions that have encryption enabled. Keep the session reference during validation so the normal STATUS_USER_SESSION_DELETED response is encrypted with the old key. The session remains expired and no command is executed. Fixes: fa9415d4024f ("ksmbd: mark SMB2_SESSION_EXPIRED to session when destroying previous session") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9d3ebd8216226a2499f8ea341f85436262ecfbde Author: Namjae Jeon Date: Thu Aug 13 17:05:49 2026 +0900 ksmbd: disconnect on SMB3 decryption failure [ Upstream commit 12a6680ce59bcd431730c9f049caddb017964c64 ] MS-SMB2 requires the server to disconnect a connection when an encrypted transform cannot be associated with a session or fails authenticated decryption. This includes an encrypted request that still carries a SessionId invalidated through PreviousSessionId. Move the connection to EXITING and shut down its transport when decrypt_req() fails. Add the missing TCP shutdown callback so a receive blocked in kernel_recvmsg() is released; SMB Direct already provides the corresponding callback. Plaintext requests using an invalidated SessionId do not take this path and continue to receive STATUS_USER_SESSION_DELETED. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 0875872718b98e8530fbc634e5aa7dbd3253b80d Author: Namjae Jeon Date: Thu Aug 13 09:01:00 2026 +0900 ksmbd: scope session state changes to bound connections [ Upstream commit c50e628122aed077695669e25b842e778511a43d ] ksmbd_all_conn_set_status() treats every connection whose transient binding flag is set as belonging to the target SessionId. A logoff or session replacement can consequently move an unrelated connection to NEED_RECONNECT or NEED_SETUP. Pass the target session itself and select connections using either the connection-local session xarray or the session's permanent channel list. Use the same association test while waiting for requests to drain. Serialize session-wide status changes under request_lock and do not overwrite EXITING or RELEASING. Protect the shutdown transition with the same lock so a concurrent session update cannot revive a closing connection. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Fixes: abcc506a9a71 ("ksmbd: fix racy issue from smb2 close and logoff with multichannel") Fixes: c444139cb747 ("ksmbd: rewrite stop_sessions() with restartable iteration") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b9f1aee32d385a8afb499136f8a21eadd2794a40 Author: Namjae Jeon Date: Thu Aug 13 09:00:00 2026 +0900 ksmbd: fix encrypted request lookup on bound channels [ Upstream commit 2cbd4a8bf460cdf414a2d7e4912c5bcfe3d0fdc2 ] An SMB3 multichannel binding registers the secondary connection in the session channel list, but does not insert the session into the secondary connection's session xarray. The decryption path only searches the connection-local xarray. As a result, every encrypted request received on a bound channel fails with "Could not get decryption key". Use the channel-aware session lookup for decryption. Also stop using the temporary conn->binding flag to decide whether the global lookup is allowed. Validate the permanent channel association under chann_lock instead. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 3fc762f881c98426154f5cb2088ddbe7661583fd Author: Namjae Jeon Date: Sun Jul 26 22:49:45 2026 +0900 ksmbd: expire SMB sessions when Kerberos tickets expire [ Upstream commit a47634cd729b42dfe372048b056d98ba4e128eaa ] Store the expiry time from the Kerberos authentication response in the session and reject requests after that time with STATUS_NETWORK_SESSION_EXPIRED. Allow an expired Kerberos session to be reauthenticated. Keep the old SMB signing key until its SESSION_SETUP response has been signed, then install the new session key and regenerate the SMB3 keys. Signed-off-by: Namjae Jeon Stable-dep-of: 2cbd4a8bf460 ("ksmbd: fix encrypted request lookup on bound channels") Signed-off-by: Sasha Levin commit 599dd43e4ba8b2c27f2ae2ec326233b5ffbdcd7e Author: Namjae Jeon Date: Sun Jul 5 00:13:18 2026 +0900 ksmbd: validate SMB2 write offsets [ Upstream commit df35438ba9d5687335a405418772b6cd30383687 ] An SMB2 WRITE request with a negative offset returns -EINVAL directly from smb2_write(). This bypasses the common error response path, leaving the client waiting until the request times out. ksmbd also allows nonempty writes at or beyond MAXFILESIZE as defined by [MS-FSA]. Writes beyond the limit must fail with STATUS_INVALID_PARAMETER. Writes ending at the limit fail with STATUS_DISK_FULL, while a zero-length write remains valid. Route negative offsets through the common error path and validate the end offset of nonempty writes against MAXFILESIZE. This fixes smb2.rw.invalid. Signed-off-by: Namjae Jeon Stable-dep-of: 2cbd4a8bf460 ("ksmbd: fix encrypted request lookup on bound channels") Signed-off-by: Sasha Levin commit 514a0b2bc949963497e66cacd433f65dc768a71d Author: Namjae Jeon Date: Fri Aug 14 11:18:38 2026 +0900 ksmbd: detach blocked lock requests before freeing [ Upstream commit 215e8816b1ac25176d911abb8704390413ccee4b ] A file_lock retained by ksmbd for byte-range lock bookkeeping can still be part of the VFS blocked-request graph. In particular, the VFS can chain a new waiter below an already blocked request through flc_blocked_requests. The ksmbd_file reference count does not cover that graph. Both __ksmbd_close_fd() and the cross-request unlock path free these retained file_lock objects directly. If a dependent waiter is still attached, locks_release_private() hits BUG_ON(!list_empty(&flc->flc_blocked_requests)). The same lifetime mismatch can leave a freed ksmbd_lock reachable through its request-local llist. Detach the file_lock from the blocked-request graph before freeing it in the close, cross-request unlock, and rollback paths. locks_delete_block() also wakes requests chained below the object. Remove llist when a completed lock is published so a globally visible ksmbd_lock no longer points into the submitting worker's stack. Fixes: d63528eb0d43 ("ksmbd: free ksmbd_lock when file is closed") Reported-by: Kyenghwan Hwang Tested-by: Kyenghwan Hwang Tested-by: ChenXiaoSong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d09af9a35ff7b77a950b507133d9092aadbfeff4 Author: Namjae Jeon Date: Wed Jul 29 21:25:35 2026 +0900 ksmbd: safely discard unregistered deferred locks [ Upstream commit 054bcca4cd9f00719b01f7108b51a2168fb94f15 ] When vfs_lock_file() defers a lock, smb2_lock() puts its ksmbd_lock on rollback_list before allocating and registering the asynchronous work. If either operation fails, rollback assumes that smb_lock->conn is initialized and dereferences NULL. The deferred file_lock also remains linked into the VFS blocked-lock state while it is freed. Keep the lock off rollback_list until async setup succeeds. On setup failures, explicitly unblock and wake the deferred lock before freeing it and its ksmbd wrapper. Signed-off-by: Namjae Jeon Stable-dep-of: 215e8816b1ac ("ksmbd: detach blocked lock requests before freeing") Signed-off-by: Sasha Levin commit 31a89af4f513d750fec196e2bb6195a7d4473e9f 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 d73441232f1f067eb659e94447b1353c16609711 Author: Andreas Schwab Date: Sat Aug 15 09:24:22 2026 +0200 m68k: nfcon: Do not call console_is_registered() in nfcon_device() [ Upstream commit 2f8e3cad53b5c36ab0ed5d3195bfc55c59ea61a5 ] Since 7c2af0f634f1 ("tty: tty_io: use console_list_lock for list synchronization") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered. Fixes: 7c2af0f634f1 ("tty: tty_io: use console_list_lock for list synchronization") Signed-off-by: Andreas Schwab Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/87ecfzsv6h.fsf@igel.home Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit daeb74f5f398e847d1d42906aec6610406a34fdc Author: Junseo Lim Date: Wed Aug 12 18:16:54 2026 +0900 bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks [ Upstream commit 84473a7e1813a2da7b759ab1d098a84998c8d3f5 ] _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME. Fixes: 859051dd165e ("bpf: Implement cgroup sockaddr hooks for unix sockets") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/bpf/20260812091654.244752-1-zirajs7@gmail.com Signed-off-by: Sasha Levin commit 7b6b6bbbfd13e09f80aa5bb14a6191268d8ad1d6 Author: Ojaswin Mujoo Date: Sun Aug 16 18:37:09 2026 +0530 erofs: fix unused pcluster_pools for higher page sizes [ Upstream commit 988c3c186c730590a71df8adc1424c5578ef8bae ] pcluster_pool[] hardcodes {1,4,16,64,128,Z_EROFS_PCLUSTER_MAX_PAGES+1}, but the assumption of Z_EROFS_PCLUSTER_MAX_PAGES == 256 is only right for 4k page sizes. For higher page sizes like 16k or 64k, This results in us ending up with clusters bigger than what we will ever use, since we only support upto 1MB of compressed data. For example, on 64k page size we will only ever use clusters with nrpages= 1, 4 and 17. This patch fixes the allocation for such higher pages sizes by adding some compile time checks. Below are the clusters created right after boot on a 64KB page size machine $cat /proc/slabinfo | grep pcluster | cut -d" " -f1: Before the patch: erofs_pcluster-1 erofs_pcluster-4 erofs_pcluster-16 erofs_pcluster-17 erofs_pcluster-64 erofs_pcluster-128 After the patch: erofs_pcluster-1 erofs_pcluster-4 erofs_pcluster-17 Fixes: 9f6cc76e6ff0 ("erofs: introduce physical cluster slab pools") Reported-by: Shirisha G Signed-off-by: Ojaswin Mujoo Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 179a5b2171573d94a25c9aa8e1c9f9ac352ad316 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 1bbdbf56d3586bc96c739d1516472c1d6c4695d9 Author: Josh Poimboeuf Date: Fri Aug 14 19:36:34 2026 -0700 objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES() [ Upstream commit d8a2860b4a366bfa8acb3d64da2c546ea26d2091 ] When a module function references a vmlinux symbol which is exported with EXPORT_SYMBOL_FOR_MODULES(), a patch to that function needs to use a klp reloc. Currently, livepatch fails to load such a module: livepatch: invalid access to vmlinux symbol 'get_task_policy' from module-specific livepatch relocation section livepatch: failed to initialize patch 'livepatch_test' for module 'testmod' (-22) livepatch: patch 'livepatch_test' failed for module 'testmod', refusing to load module 'testmod' klp diff puts all klp relocs in __klp_relocs., so post-link names the section .klp.rela.., which the kernel rejects for vmlinux symbols. Commit 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") changed the meaning of objname in the klp rela section name to be where the referenced symbol is referenced rather than where it lives. That premise only holds for symbols in a module: the relocs get applied when the patched module gets patched, and the module dependency guarantees the referenced module is loaded by then. A vmlinux symbol needs the opposite. It's always resolvable, and it has to be applied when the patch module loads, before the module loader initializes the patch module's special sections, which may reference it. That's why livepatch rejects vmlinux symbols in module-specific sections. Use "vmlinux" as the section objname when the referenced symbol lives in vmlinux. This moves such klp relocs from .klp.rela.kvm..text to .klp.rela.vmlinux..text. Fixes: 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") Reported-by: Dylan Hatch Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Song Liu Link: https://patch.msgid.link/f8e3b9fae109903a6aafb2a33310e4afdcebf58e.1786761327.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/CADBMgpz7iWC0=t=_gE-tfvv0mTPq4kg0qQ2zgPH8DVPE6eQ9Kw@mail.gmail.com Signed-off-by: Sasha Levin commit 0f8a4184c00ceb9aa30e3d123cd0ad6273cf7d8a Author: Gao Xiang Date: Fri Aug 14 16:14:37 2026 +0800 erofs: guard on-disk algorithm IDs against Z_EROFS_COMPRESSION_MAX [ Upstream commit 6847d4d1a24a686ca6c8a0f68501a984f9a0d059 ] All on-disk algorithm IDs should be validated against supported Z_EROFS_COMPRESSION_MAX. This includes a partial revert of a previous commit and also adds validation for encoded extents. Fixes: 131897c65e2b ("erofs: fix invalid algorithm for encoded extents") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 451027c642e752420e1a04237db9ce7b35cee595 Author: Gao Xiang Date: Fri Aug 14 14:59:46 2026 +0800 erofs: fix interlaced ztailpacking pclusters [ Upstream commit 862427ebb81d1f6abbf74d799790e1694b37b187 ] On-disk sizes of interlaced pclusters should be block-aligned, and ztailpacking interlaced pclusters should be invalid at all. Currently, mkfs.erofs won't generate any interlaced pcluster with ztailpacking enabled, so this doesn't affect any existing valid filesystems. However, crafted images can contain invalid interlaced ztailpacking pclusters, resulting in an out-of-bounds read from a kmap'd page and copying irrelevant kernel memory into userspace-visible page cache. Reported-by: Haiyang Huang Closes: https://lore.kernel.org/r/20260806065253.1083865-1-huanghaiyang83@gmail.com Fixes: fdffc091e6f9 ("erofs: support interlaced uncompressed data for compressed files") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit a1d26dfb32919088e3638dca01068df3c4507433 Author: Ilan Dudnik Date: Sat Aug 1 20:18:48 2026 +0300 ksmbd: defer publishing granted locks to prevent UAF/double-free race [ Upstream commit 29f74f0f2e6df3b393b7b66e810136d0c64e3c59 ] In smb2_lock(), mid-batch granted locks are published to connection-wide (conn->lock_list) and file-wide (fp->lock_list) lists immediately upon vfs_lock_file() success, while also remaining tracked on the stack-local rollback_list. If a subsequent element in the same SMB2_LOCK request array fails validation or execution, the thread jumps to out: and walks rollback_list to undo previously granted locks. However, because the granted lock was already published to conn->lock_list, a concurrent UNLOCK request on the same connection can find the lock object and kfree() it before the rollback loop executes. When the granting thread subsequently walks rollback_list, it dereferences and frees the already-freed ksmbd_lock structure, resulting in a Use-After-Free and Double-Free (on both ksmbd_lock and struct file_lock). Fix this by deferring the publication of granted locks to conn->lock_list and fp->lock_list until after the entire array of lock elements has been processed without error. Mid-batch grants remain tracked exclusively on the request-local rollback_list until the whole batch succeeds, eliminating the race window. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Ilan Dudnik Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a54df0ce7a985bc9aa10a738b51e8b9bee02a150 Author: Namjae Jeon Date: Wed Jul 29 21:24:54 2026 +0900 ksmbd: recognize replayed SMB2 lock sequences [ Upstream commit 5ce5227cd60b7213359e91837727ed1b6d457d49 ] A server returns success without processing a lock request when a valid LockSequenceArray entry contains the same sequence number. The current verifier only invalidates mismatched entries, so matching requests are submitted to the VFS again and recorded as duplicate locks. Make the verifier report matching sequences and skip lock processing for those replays. Also correct the field comment to describe the sequence and index bit layout used by the implementation and the protocol. Use the capabilities advertised by the server when deciding whether lock sequence verification applies to a multichannel connection. Signed-off-by: Namjae Jeon Stable-dep-of: 29f74f0f2e6d ("ksmbd: defer publishing granted locks to prevent UAF/double-free race") Signed-off-by: Sasha Levin commit 9e8faf91bb11ef6ffac823d30681cd7aedcab313 Author: ZhangGuoDong Date: Fri Jul 31 11:50:08 2026 +0000 smb/server: preserve error status in smb2_handle_negotiate() [ Upstream commit 73541bd2bab77e7e8e89b1edb5d342f4190dd4d0 ] smb2_handle_negotiate() records specific failures such as STATUS_INVALID_PARAMETER or STATUS_NOT_SUPPORTED. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7d2cd9269b570347e6e2dd24d4b3c1da868bc91d Author: ZhangGuoDong Date: Fri Jul 31 11:50:07 2026 +0000 smb/server: call ksmbd_proc_cleanup() on module init failure [ Upstream commit f43cbe3b58ce989ce420c3bc875d48e7754c8aba ] When a later initializer fails, the unwind chain releases resources created after procfs and then jumps directly to class_unregister(). Returning an error from module_init() leaves the proc tree and its per-CPU counters allocated. Fixes: b38f99c1217a ("ksmbd: add procfs interface for runtime monitoring and statistics") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fb4ba2bdfc1de8866e7c8e00df99f4b03ff42f09 Author: ZhangGuoDong Date: Fri Jul 31 11:50:06 2026 +0000 smb/server: abort initialization when proc setup fails [ Upstream commit db97f3763727d652112ae70038d4e17b3ce277bb ] ksmbd_server_init() calls ksmbd_proc_init() before creating the remaining proc entries and server subsystems. ksmbd_proc_init() tears down partial state on a procfs or percpu_counter allocation failure, but returns void, so ksmbd_server_init() continues as if the counters were usable. Once userspace starts the server, server_ctrl_handle_init() calls ksmbd_proc_reset(), which reaches percpu_counter_set() with a NULL per-CPU counters pointer on SMP systems. The later ksmbd_proc_create() calls also receive a NULL parent and may create entries in the /proc root; ksmbd_proc_cleanup() cannot remove those entries because ksmbd_proc_fs is NULL. Fixes: b38f99c1217a ("ksmbd: add procfs interface for runtime monitoring and statistics") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a2eb72b4d53bb9d8d6c00f3f794eaccb4b1ce5ed Author: ZhangGuoDong Date: Fri Jul 31 11:50:05 2026 +0000 smb/server: fix invalid pointer dereference in ksmbd_stop_durable_scavenger() [ Upstream commit bef46b604732d83f8da29f782868de4d25bf972c ] See the procedure below: ksmbd_launch_ksmbd_durable_scavenger durable_scavenger_running = true server_conf.dh_task = kthread_run() // fail, dh_task is an ERR_PTR() server_ctrl_handle_reset ksmbd_stop_durable_scavenger kthread_stop(server_conf.dh_task) // invalid pointer Fixes: d484d621d40f ("ksmbd: add durable scavenger timer") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7065d3648b1a48d2c49da3d6364dd3c4d503b10c Author: ZhangGuoDong Date: Fri Jul 31 11:50:03 2026 +0000 smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() [ Upstream commit d2ccf905f47d2344270749f4dfa905afcd3edeb0 ] See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 5f97bac88bfb333f426f01c118b8235e75af8d96 Author: Namjae Jeon Date: Tue Jul 28 22:17:14 2026 +0900 ksmbd: serialize oplock close with pending break ownership [ Upstream commit b0148dc5625dbfd50596ac63c7487c12e8a8ab03 ] close may abort an in-flight oplock break while another breaker already holds an opinfo reference. Releasing pending_break wakes that waiter, but without serializing the close transition with bit acquisition it can become a new break owner through the test_and_set_bit() fast path. It can then overwrite OPLOCK_CLOSING with OPLOCK_ACK_WAIT and continue a break for a dying opinfo. Make OPLOCK_CLOSING terminal once the opinfo is removed from the inode list. Serialize that transition, pending_break acquisition, and OPLOCK_ACK_WAIT setup with an opinfo state lock. A breaker which loses the race releases its ownership and returns -ENOENT. Explicitly wake pending_break waiters during close so they can observe the terminal state. Also prevent ACK and timeout paths from replacing OPLOCK_CLOSING with OPLOCK_STATE_NONE. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Co-developed-by: Yunseong Kim Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c2b867861a48f0438afa6ce01f75e414df5431ad Author: Namjae Jeon Date: Sun Jul 19 00:36:32 2026 +0900 ksmbd: add SMB3 request replay support [ Upstream commit bb8bf7eb13b518b379356a0c5dee8a23d6ee37ac ] SMB3 clients can replay selected requests after a channel disconnect by setting SMB2_FLAGS_REPLAY_OPERATION. The command sequence window rejects duplicate MessageIds on one connection, but it does not validate requests resent on another channel with a new MessageId. Add the state and validation required to replay durable CREATE and file-handle operations: - track each open ChannelSequence, outstanding request counts, and lock sequence entries. - retain a request-owned open reference until the common response path completes ChannelSequence accounting. - replay DurableHandleReqV2 CREATE requests by CreateGuid, validating the durable state, SecurityContext, session, lease key, and persistent flag. - publish CreateGuid and SecurityContext before an oplock or lease break can defer CREATE, rejecting replays of that pending CREATE with STATUS_FILE_NOT_AVAILABLE. - retain the original CREATE action and replay completed CreateGuid requests, including requests that did not receive a durable-handle grant, without modifying the existing open. - make replayed oplock and lease break acknowledgements idempotent. And - preserve SMB2_FLAGS_REPLAY_OPERATION in responses. Return STATUS_FILE_NOT_AVAILABLE when ChannelSequence validation rejects a replayed WRITE, IOCTL, or SET_INFO request. Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit 50be5e96c381ae995b7de3869eecdc84476be7f2 Author: Namjae Jeon Date: Mon Jul 13 10:09:27 2026 +0900 ksmbd: retain connection for pending notify work [ Upstream commit f495154703cbcc0050cfd53469bd56965791616b ] Deferred CHANGE_NOTIFY work keeps an async message ID after the original request work is released. A durable handle can outlive its connection, so the connection teardown can destroy its async IDA before the handle close releases the pending notify work. Give the synthetic deferred work a connection reference. Release it after the async ID in ksmbd_free_work_struct(). This keeps the async IDA alive until the deferred work is released, even when the original connection has already left the connection list. During server shutdown there is no client to receive a cleanup response. Skip the write and only release the pending work. Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit a34f809167a462ef9b415e6a6a7b59ed0e5a34df Author: Gael Blivet Date: Thu Jul 9 02:06:10 2026 +0200 ksmbd: defer CHANGE_NOTIFY completion instead of STATUS_NOT_IMPLEMENTED [ Upstream commit 152036e875e8cfe41dc70328f7e499ccc5142d6c ] smb2_notify() currently returns STATUS_NOT_IMPLEMENTED synchronously for every CHANGE_NOTIFY request. Genuine SMB2 servers never complete a CHANGE_NOTIFY spontaneously -- it's satisfied only by a real directory change or with STATUS_NOTIFY_CLEANUP when the watched handle is closed. macOS smbfs.kext depends on this deferred-completion contract: receiving STATUS_NOT_IMPLEMENTED instead makes it hard-freeze on unmount, since it never sees the cleanup it's waiting for. Add a notify_pendings list on struct ksmbd_file (protected by the existing f_lock) and a notify_entry list_head on struct ksmbd_work to link onto it. smb2_notify() now replies STATUS_PENDING immediately and queues a deferred STATUS_NOTIFY_CLEANUP response on the watched handle; __ksmbd_close_fd() drains and sends any pending notifications when the handle is actually closed. The drain splices the list out under fp->f_lock first, then processes the detached copy without the lock -- smb2_notify() on another connection can be adding to the same list at the same time a close happens on this one, and ksmbd_conn_write() can sleep (it takes the connection's write mutex), so it must not be called while the spinlock is held. Also handle the FileId=FFFF...FFFF share-root sentinel that macOS backupd sends to watch for changes without holding an open handle -- without an immediate STATUS_PENDING/STATUS_NOTIFY_CLEANUP reply here, backupd aborts Time Machine setup with STATUS_FILE_CLOSED. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit bbeefd3e96645ea4951520aea66a010ce87927af Author: Gael Blivet Date: Thu Jul 9 14:59:56 2026 +0900 ksmbd: add AAPL kAAPL_SERVER_QUERY create context support [ Upstream commit 8f1b796ff1135f5660e1889973359331c61b78a0 ] macOS clients (Finder, and specifically Time Machine's backupd) send an "AAPL" SMB2 create context on CREATE to negotiate AAPL-specific server capabilities (server_caps/vol_caps/model string). Without a response to this context, macOS Time Machine over SMB does not work at all. Add the AAPL create context structs (create_aapl_rsp, aapl_server_query_req) and create_aapl_rsp_buf(), which builds the kAAPL_SERVER_QUERY response mirroring the layout observed from macOS's own smbd, including the model string workaround: omitting the model string when the client requested it causes smbfs.kext to enter a broken disconnect path requiring a full macOS reboot to recover from. Command codes and bitmap values reuse the existing SMB2_CRTCTX_AAPL_* constants in fs/smb/common/smb2pdu.h. Wire format confirmed against AAPL's published public client kernel source (public client behavior reference) -- every field here and every SMB2_CRTCTX_AAPL_* constant matches exactly. Hook the request parsing and response into smb2_open()'s existing create-context handling, following the same DataOffset+DataLength bounds-checking convention already used by every other context parser in this file. The AAPL model string is configurable via the existing netlink startup path (server_conf.aapl_model, default "Xserve"). This is scoped to shares with the new KSMBD_SHARE_FLAG_TIME_MACHINE flag only, not enabled globally -- AAPL's AAPL extension is undocumented, so containing its blast radius to shares that explicitly opt in limits risk to ordinary SMB shares. conn->aapl_readdir_attr is set here when the client also advertises READDIR_ATTR support, but the actual inline-FinderInfo wire format (the feature that flag gates) is not implemented yet -- follow-up commit. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit 8a765fb56ca7664c5cb3f73788ee1335785ef21d Author: Gael Blivet Date: Thu Jul 9 02:01:06 2026 +0200 ksmbd: fix durable handle v2 default timeout units (60 -> 60000) [ Upstream commit c1d7bbfc5e081875053723d1a69eb2cf341eaaf1 ] When a client's Durable Handle Request V2 sets Timeout=0 ("let the server choose"), fp->durable_timeout was set to 60. Every other use of this field is in milliseconds: DURABLE_HANDLE_MAX_TIMEOUT (300000) in smb2pdu.h, the nonzero branch immediately above (min_t(unsigned int, dh_info.timeout, DURABLE_HANDLE_MAX_TIMEOUT), where dh_info.timeout is the wire value and already milliseconds per spec), and the scavenger in vfs_cache.c, which adds it directly to jiffies_to_msecs(jiffies). 60 is off by 1000x: the handle becomes scavenger-eligible 60 milliseconds after close instead of 60 seconds. A client requesting Timeout=0 is relying entirely on the server's default to cover the gap between a dropped connection and its reconnect -- 60ms is not enough time for even a fast network blip to be detected and reconnected, so any real disruption loses the race and a subsequent DH2C reconnect fails with a durable-handle lookup miss instead of succeeding. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit ac5104f4bd9a9ec8b30d63391e596f300fb0e266 Author: Namjae Jeon Date: Sun Jul 5 15:20:06 2026 +0900 ksmbd: support access-based directory enumeration [ Upstream commit e5f42cb7577221080e4db0498d71e6db7e67f1a5 ] SMB shares can advertise access-based directory enumeration. ksmbd does not currently provide a share option or filter inaccessible directory entries. Add a hide-unreadable share flag and advertise SMB2_SHAREFLAG_ACCESS_BASED_DIRECTORY_ENUM when it is enabled. During QUERY_DIRECTORY, omit entries unless the connected user has FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES access according to the Windows ACL. Keep the existing implicit access allowances for normal CREATE permission checks while using strict access-mask matching for directory enumeration. Signed-off-by: Namjae Jeon Stable-dep-of: b0148dc5625d ("ksmbd: serialize oplock close with pending break ownership") Signed-off-by: Sasha Levin commit 8e2ebc77678832e981adc008d25cd8f67d08ebc4 Author: Namjae Jeon Date: Fri Jul 24 11:17:30 2026 +0900 ksmbd: free preauth sessions on connection teardown [ Upstream commit 06c7b1d731bc105a8644f1b70165ba8b9416cbab ] SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect. Reported-by: Runa Takemoto Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8084b5c719670d84cecba8fb1524c4dfd3f45e79 Author: Namjae Jeon Date: Fri Jul 17 12:31:00 2026 +0900 ksmbd: do not advertise unimplemented CA support [ Upstream commit eebdd3f1157e35a50df5ff2d3d9a305901df3254 ] ksmbd durable handles are currently in-memory state. There is no persistent open recovery, cluster ownership epoch, fencing, or failover implementation behind the continuous-availability share flag. Do not advertise SMB2 persistent-handle or continuous-availability capabilities until those guarantees exist. A client requesting DH2Q then falls back to the existing durable V2 behavior rather than being promised a persistent handle that cannot survive a server failure. Signed-off-by: Namjae Jeon Stable-dep-of: 06c7b1d731bc ("ksmbd: free preauth sessions on connection teardown") Signed-off-by: Sasha Levin commit c494fcf8e89e3c970e13d78ebe62bf5d8f2b1c52 Author: Yunseong Kim Date: Wed Jul 22 22:31:06 2026 +0200 ksmbd: validate ipc response length before dereferencing its fields [ Upstream commit e9b33376bd07bca4175f7bcc2d6034ef250f8181 ] ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3697.947706] netlink_unicast+0x937/0xb70 [ 3697.947993] netlink_sendmsg+0x977/0xc10 [ 3697.948268] __sock_sendmsg+0x264/0x2d0 [ 3697.948536] __sys_sendto+0x4de/0x690 [ 3697.948789] __x64_sys_sendto+0x173/0x380 [ 3697.949069] do_syscall_64+0x13d/0x420 [ 3697.949328] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 3697.949662] [ 3697.949779] The buggy address belongs to the object at ffff888105f95908 [ 3697.949779] which belongs to the cache kmalloc-8 of size 8 [ 3697.950550] The buggy address is located 0 bytes to the right of [ 3697.950550] allocated 8-byte region [ffff888105f95908, ffff888105f95910) [ 3697.951455] [ 3697.951574] The buggy address belongs to the physical page: [ 3697.951958] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888105f951b8 pfn:0x105f95 [ 3697.952571] flags: 0x100000000000200(workingset|node=0|zone=2) [ 3697.952973] page_type: f5(slab) [ 3697.953198] raw: 0100000000000200 ffff888100042640 ffffea0004063610 ffff888100040588 [ 3697.953707] raw: ffff888105f951b8 00000000001c000e 00000000f5000000 0000000000000000 [ 3697.954240] page dumped because: kasan: bad access detected [ 3697.954616] [ 3697.954734] Memory state around the buggy address: [ 3697.955063] ffff888105f95800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fa [ 3697.955534] ffff888105f95880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.956006] >ffff888105f95900: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.956477] ^ [ 3697.956728] ffff888105f95980: fc fc fc fa fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.957202] ffff888105f95a00: fc fc fc fc fc fa fc fc fc fc fc fc fc fc fc fc [ 3697.957671] ================================================================== The final "entry->msg_sz != msg_sz" comparison cannot help: the offending read has already happened by the time it runs. Every case in the switch shares this pattern. Floor entry->msg_sz against the base struct of each event type before dereferencing any of its length fields. On failure ipc_msg_send_request() already frees the response and returns NULL, so callers stay safe. The malformed message originates from the ksmbd.mountd daemon over genl netlink rather than a remote SMB client, so triggering it requires a buggy or compromised daemon; it is still an out-of-bounds read the validator is meant to prevent. Fixes: d6a6aa81eac2 ("ksmbd: validate response sizes in ipc_validate_msg()") Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8ea83ef0c40ec4463695e22bc9ae43e29bcfede7 Author: Yunseong Kim Date: Wed Aug 5 02:46:58 2026 +0200 smb: smbdirect: release pending child sockets outside the handler lock [ Upstream commit db82fbe4bb68e68e4aef00ef5b79f92991d8ef8e ] smbdirect_socket_destroy() releases the listener's pending/ready child sockets while still holding the listener's handler lock, the &id_priv->handler_mutex taken via rdma_lock_handler(), not sc->listen.lock, and before the listener's own rdma_destroy_id(). That ordering has one real consequence and one cosmetic one. The real one: smbdirect_socket_release() drops the child's last reference, which destroys the child's cm_id. Doing that before the listener's rdma_destroy_id() lets _cma_cancel_listens(), running from the listener's _destroy_id(), walk an already freed child id_priv, which KASAN catches as a slab-use-after-free during listener shutdown: [ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469/0x1560 [ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652 [ 4758.913262] Call Trace: [ 4758.913267] [ 4758.913299] __mutex_lock+0x1469/0x1560 [ 4758.913408] _cma_cancel_listens+0x312/0x3b0 [ 4758.913413] _destroy_id+0x363/0xee0 [ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440 [ 4758.913443] smbdirect_socket_release+0x124/0x230 [ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190 [ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0 [ 4758.913463] kill_server_store+0x1fb/0x2b0 [ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0 [ 4758.913507] vfs_write+0x5e7/0xc70 [ 4758.913528] ksys_write+0x12a/0x210 [ 4758.913541] do_syscall_64+0x135/0x460 [ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f The cosmetic one: releasing a child recurses into smbdirect_socket_destroy(), which takes the child's own rdma_lock_handler() lock nested under the listener's. The listener's and the child's cm_id are always different instances, so this cannot deadlock for real; the CM core itself nests a new connection id's handler_mutex under the listening id's in cma_ib_req_handler(). But lockdep only sees one lock class, reports possible recursive locking, and then disables itself, hiding real locking bugs for the rest of the run: [ 2424.579653] WARNING: possible recursive locking detected [ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted [ 2424.582548] -------------------------------------------- [ 2424.584500] ksmbd.control/8854 is trying to acquire lock: [ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.590590] [ 2424.590590] but task is already holding lock: [ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.594178] [ 2424.594178] other info that might help us debug this: [ 2424.596634] Possible unsafe locking scenario: [ 2424.596634] [ 2424.598841] CPU0 [ 2424.599765] ---- [ 2424.600695] lock(&id_priv->handler_mutex); [ 2424.601836] lock(&id_priv->handler_mutex); [ 2424.602590] [ 2424.602590] *** DEADLOCK *** [ 2424.602590] [ 2424.604512] May be due to missing lock nesting notation Splice the pending/ready children onto a local list under the listener's listen.lock, while the handler lock is held so a concurrent CM CONNECT_REQUEST cannot add more, but defer the actual smbdirect_socket_release() calls until after the listener's cm_id has been destroyed and its handler lock dropped. The children are independent sockets whose teardown needs neither the listener's handler lock nor its cm_id. Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Signed-off-by: Yunseong Kim Reviewed-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c4de57fd85459bb8a5092672e70473e7eb06d6ca Author: Yunseong Kim Date: Wed Aug 5 02:46:56 2026 +0200 smb: smbdirect: avoid recursive listen.lock during cleanup [ Upstream commit 76fa42c004eb95a983bed8fd0e6e0e8428c751a5 ] __smbdirect_socket_schedule_cleanup() and smbdirect_socket_cleanup_work() take sc->listen.lock and walk the listener's pending list, recursing into smbdirect_socket_schedule_cleanup() for each child, and every child takes its own listen.lock inside that walk. This cannot deadlock for real: the nesting is strictly listener into child, a child never listens, so the outer and the inner lock are always different instances. lockdep only tracks lock classes, though; it sees the same class acquired twice and reports a possible recursive locking deadlock. This change therefore works around a lockdep limitation rather than fixing a real hang, but the report is still worth avoiding: lockdep disables itself after the first splat and then hides real locking bugs for the rest of the run. Only a socket that was a listener owns a populated listen.ready/pending list; a child has empty lists and nothing to do in these blocks. Guard both of them with sc->listen.backlog != -1, the "was a listener" marker that smbdirect_socket_destroy() already uses: listen.backlog leaves its initial -1 exactly once, when smbdirect_socket_listen() succeeds. The alternative !sc->accept.listener test reads as "not a listener" while meaning the opposite, and it is also true for an accepted child, whose accept.listener has been cleared on hand-over. With the guard the walk only runs for a listener and never nests a child's listen.lock under it; a pending child stays on its listener's list for the free path (smbdirect_socket_destroy) to reap. [ 741.705044] WARNING: possible recursive locking detected [ 741.705403] 7.1.0-next-20260623+ #75 Not tainted [ 741.705695] -------------------------------------------- [ 741.706022] ksmbd.control/18502 is trying to acquire lock: [ 741.706379] ffff888108d612f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.707008] [ 741.707008] but task is already holding lock: [ 741.707396] ffff8881087642f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.708025] [ 741.708025] other info that might help us debug this: [ 741.708448] Possible unsafe locking scenario: [ 741.708448] [ 741.708845] CPU0 [ 741.709016] ---- [ 741.709186] lock(&sc->listen.lock); [ 741.709453] lock(&sc->listen.lock); [ 741.709705] [ 741.709705] *** DEADLOCK *** [ 741.709705] [ 741.710095] May be due to missing lock nesting notation [ 741.710095] [ 741.710663] 6 locks held by ksmbd.control/18502: [ 741.710975] #0: ffff888109e51420 (sb_writers#7){.+.+}-{0:0}, at: vfs_write+0x1e7/0xc70 [ 741.711561] #1: ffff888126ec3880 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x1be/0x4d0 [ 741.712147] #2: ffff888102af17b0 (kn->active#45){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x205/0x4d0 [ 741.712803] #3: ffffffff85ad1e00 (ctrl_lock){+.+.}-{4:4}, at: kill_server_store+0x1e0/0x2b0 [ 741.713381] #4: ffffffff85ad41a0 (init_lock){+.+.}-{4:4}, at: ksmbd_conn_transport_destroy+0x5b/0x3c0 [ 741.713995] #5: ffff8881087642f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.714736] [ 741.714736] stack backtrace: [ 741.715038] CPU: 4 UID: 0 PID: 18502 Comm: ksmbd.control Not tainted 7.1.0-next-20260623+ #75 PREEMPT(lazy) [ 741.715043] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 741.715046] Call Trace: [ 741.715049] [ 741.715052] dump_stack_lvl+0x77/0xa0 [ 741.715058] print_deadlock_bug+0x279/0x290 [ 741.715065] __lock_acquire+0x272a/0x2e30 [ 741.715070] ? stack_trace_save+0xae/0x100 [ 741.715075] ? smb_direct_logging_vaprintf+0x1a0/0x230 [ 741.715079] ? __pfx_smb_direct_logging_vaprintf+0x10/0x10 [ 741.715082] ? __timer_delete+0x58/0x320 [ 741.715087] lock_acquire+0xd3/0x270 [ 741.715091] ? __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.715095] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 741.715099] _raw_spin_lock_irqsave+0x42/0x60 [ 741.715105] ? __smbdirect_socket_schedule_cleanup+0x719/0xd70 Note the two addresses above: ffff888108d612f8 is the child's lock, ffff8881087642f8 the listener's, always distinct objects. Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Signed-off-by: Yunseong Kim Reviewed-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 959813a3752b459ed77b0b3eaf30b9f4c6204260 Author: Yunseong Kim Date: Tue Jul 21 02:05:19 2026 +0200 smb: smbdirect: destroy QP before mem pools on accept failure [ Upstream commit 383a9480f5f40bc46454cce27ccfad532cedad9c ] On the rdma_accept_failed error path of smbdirect_accept_connect_request(), the receive io posted just above is owned by the QP (recv_io is set to NULL after a successful post). The error path fell through to smbdirect_connection_destroy_mem_pools() before smbdirect_connection_destroy_qp(), so the mem pools and the recv_io slab cache were destroyed while that recv_io was still outstanding on the QP. The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what runs the recv completion that returns the recv_io to the free list, so destroying the pools first leaves the object outstanding at kmem_cache_destroy() time ("Slab cache still has objects") and later frees it into an already-destroyed mempool (mempool_free_bulk NULL-pointer dereference). Give rdma_accept_failed its own teardown that drains the QP first, then destroys the mem pools, and returns. The remaining labels (post_recv_io_failed onward) run before the recv_io was ever posted, so they keep the mem-pools-then-qp order. The outstanding recv_io at kmem_cache_destroy() time: [ 3487.344647] ============================================================================= [ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown() [ 3487.356078] ----------------------------------------------------------------------------- [ 3487.356078] [ 3487.356738] Object 0xffff8881511c3440 @offset=13376 [ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempool_alloc_noprof+0x18c/0x290 [ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780 [ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80 [ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.362779] cma_cm_event_handler+0x9c/0x230 [ 3487.363096] cma_ib_req_handler+0x2682/0x45d0 [ 3487.363414] cm_process_work+0x56/0x3d0 [ 3487.363676] cm_work_handler+0x8a0e/0xd000 [ 3487.367496] process_scheduled_works+0xa07/0x13a0 [ 3487.367859] worker_thread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] ret_from_fork+0x3a8/0x7a0 [ 3487.368704] ret_from_fork_asm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2) [ 3487.372840] ------------[ cut here ]------------ [ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254 [ 3487.373759] Modules linked in: [ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3487.374778] Tainted: [B]=BAD_PAGE [ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] Workqueue: ib_cm cm_work_handler [ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30 [ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093 [ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80 [ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080 [ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410 [ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210 [ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300 [ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3487.390440] PKRU: 55555554 [ 3487.390641] Call Trace: [ 3487.390826] [ 3487.391209] __kmem_cache_shutdown+0x1aa/0x2b0 [ 3487.392062] ? smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.393565] kmem_cache_destroy+0x9d/0x180 [ 3487.398663] smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.403534] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ 3487.407562] smbdirect_accept_connect_request+0x95c/0x1b80 [ 3487.412391] ? __pfx_smbdirect_accept_connect_request+0x10/0x10 [ 3487.416753] ? do_raw_spin_lock+0x130/0x300 [ 3487.420623] ? smbdirect_socket_set_initial_parameters+0x28b/0x6a0 [ 3487.424322] ? lock_acquire+0x4c/0x270 [ 3487.424409] ksmbd: can't change a file to a directory [ 3487.426321] ? trace_irq_enable+0x36/0x120 [ 3487.429144] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.432606] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3487.433595] ? trace_cm_event_handler+0x51/0x170 [ 3487.435183] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3487.435646] ? cma_listen_handler+0xf6/0x150 [ 3487.435975] cma_cm_event_handler+0x9c/0x230 [ 3487.436288] cma_ib_req_handler+0x2682/0x45d0 [ 3487.439039] ? __pfx_cma_ib_req_handler+0x10/0x10 [ 3487.439540] ? __pfx_roce_resolve_route_from_path+0x10/0x10 [ 3487.439972] ? stack_depot_save_flags+0x34/0x840 [ 3487.440374] ? __xas_nomem+0xa9/0x410 [ 3487.443356] ? xas_clear_mark+0x26c/0x4a0 [ 3487.443673] cm_process_work+0x56/0x3d0 [ 3487.443969] ? _raw_spin_unlock_irq+0x28/0x50 [ 3487.444317] cm_work_handler+0x8a0e/0xd000 [ 3487.444624] ? __pfx_cm_work_handler+0x10/0x10 [ 3487.444971] ? pwq_dec_nr_in_flight+0xa73/0xdf0 [ 3487.445344] ? __pfx_pwq_dec_nr_in_flight+0x10/0x10 [ 3487.445737] ? lock_acquire+0x4c/0x270 [ 3487.448833] ? process_scheduled_works+0x995/0x13a0 [ 3487.449230] ? process_scheduled_works+0x995/0x13a0 [ 3487.449588] process_scheduled_works+0xa07/0x13a0 [ 3487.449938] ? __pfx_process_scheduled_works+0x10/0x10 [ 3487.450334] ? do_raw_spin_lock+0x130/0x300 [ 3487.450639] ? assign_work+0x3bb/0x5c0 [ 3487.450916] worker_thread+0x7c9/0xc80 [ 3487.451211] kthread+0x341/0x430 [ 3487.451453] ? __pfx_worker_thread+0x10/0x10 [ 3487.451756] ? __pfx_kthread+0x10/0x10 [ 3487.454814] ret_from_fork+0x3a8/0x7a0 [ 3487.455114] ? __pfx_ret_from_fork+0x10/0x10 [ 3487.455450] ? __switch_to+0xb76/0x1110 [ 3487.455772] ? __pfx_kthread+0x10/0x10 [ 3487.456081] ret_from_fork_asm+0x1a/0x30 [ 3487.456384] [ 3487.456549] irq event stamp: 0 [ 3487.456767] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 3487.460124] hardirqs last disabled at (0): [] copy_process+0xa08/0x3a10 [ 3487.460726] softirqs last enabled at (0): [] copy_process+0xa08/0x3a10 [ 3487.461328] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 3487.461778] ---[ end trace 0000000000000000 ]--- [ 3487.543875] ksmbd: can't change a file to a directory [ 3487.599675] ksmbd: can't change a file to a directory [ 3487.626694] ksmbd: can't change a file to a directory [ 3487.824687] ksmbd: can't change a file to a directory [ 3487.871840] ksmbd: can't change a file to a directory [ 3487.986207] ------------[ cut here ]------------ [ 3487.987157] kmem_cache_destroy smbdirect_recv_io_cache_ffff88811ba99000: Slab cache still has objects when called from smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.987183] WARNING: mm/slab_common.c:572 at kmem_cache_destroy+0x15c/0x180, CPU#6: kworker/6:84/22254 [ 3487.999821] Modules linked in: [ 3488.001902] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B W 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3488.008289] Tainted: [B]=BAD_PAGE, [W]=WARN [ 3488.010459] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3488.014502] Workqueue: ib_cm cm_work_handler [ 3488.017790] RIP: 0010:kmem_cache_destroy+0x16a/0x180 [ 3488.020662] Code: fd ff 48 8b 3d 2f c0 9c 06 48 89 de 5b 41 5e 5d e9 5b a3 0e 00 48 8d 3d a4 07 12 04 48 8b 53 58 48 c7 c6 91 9d 3e 85 4c 89 f1 <67> 48 0f b9 3a e9 33 ff ff ff 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3488.028077] RSP: 0018:ffff888220fc70b8 EFLAGS: 00010202 [ 3488.032038] RAX: 0000000000000001 RBX: ffff88810955e640 RCX: ffffffff822bc079 [ 3488.035742] RDX: ffff88812404ec40 RSI: ffffffff853e9d91 RDI: ffffffff85f7ac50 [ 3488.037830] RBP: 0000000000000001 R08: ffff8883aef3e843 R09: 1ffff11075de7d08 [ 3488.041076] R10: dffffc0000000000 R11: ffffed1075de7d09 R12: 1ffff11024fa6c3c [ 3488.045376] R13: ffff888127d361e8 R14: ffffffff822bc079 R15: ffff88811ba99538 [ 3488.049073] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3488.052515] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3488.054934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3488.058529] PKRU: 55555554 [ 3488.060542] Call Trace: [ 3488.061595] [ 3488.062006] smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3488.066041] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ 3488.068620] smbdirect_accept_connect_request+0x95c/0x1b80 [ 3488.071594] ? __pfx_smbdirect_accept_connect_request+0x10/0x10 [ 3488.073218] ksmbd: not allow base filename in rename [ 3488.074751] ? do_raw_spin_lock+0x130/0x300 [ 3488.076792] ksmbd: can't change a file to a directory [ 3488.077942] ? smbdirect_socket_set_initial_parameters+0x28b/0x6a0 [ 3488.080143] ? lock_acquire+0x4c/0x270 [ 3488.080747] ? trace_irq_enable+0x36/0x120 [ 3488.081400] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3488.085089] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3488.089333] ? trace_cm_event_handler+0x51/0x170 [ 3488.092637] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3488.095741] ? cma_listen_handler+0xf6/0x150 [ 3488.099638] cma_cm_event_handler+0x9c/0x230 [ 3488.101552] cma_ib_req_handler+0x2682/0x45d0 [ 3488.104571] ? __pfx_cma_ib_req_handler+0x10/0x10 [ 3488.106790] ? __pfx_roce_resolve_route_from_path+0x10/0x10 [ 3488.109799] ? stack_depot_save_flags+0x34/0x840 [ 3488.112174] ? __xas_nomem+0xa9/0x410 [ 3488.114217] ? xas_clear_mark+0x26c/0x4a0 [ 3488.116854] cm_process_work+0x56/0x3d0 [ 3488.118179] ? _raw_spin_unlock_irq+0x28/0x50 [ 3488.120034] cm_work_handler+0x8a0e/0xd000 [ 3488.121677] ? __pfx_cm_work_handler+0x10/0x10 [ 3488.123682] ? pwq_dec_nr_in_flight+0xa73/0xdf0 [ 3488.126928] ? __pfx_pwq_dec_nr_in_flight+0x10/0x10 [ 3488.129390] ? lock_acquire+0x4c/0x270 [ 3488.131432] ? process_scheduled_works+0x995/0x13a0 [ 3488.132694] ksmbd: can't change a file to a directory [ 3488.136702] ? process_scheduled_works+0x995/0x13a0 [ 3488.140060] process_scheduled_works+0xa07/0x13a0 [ 3488.143379] ? __pfx_process_scheduled_works+0x10/0x10 [ 3488.147221] ? do_raw_spin_lock+0x130/0x300 [ 3488.150790] ? assign_work+0x3bb/0x5c0 [ 3488.154259] worker_thread+0x7c9/0xc80 [ 3488.155730] kthread+0x341/0x430 [ 3488.158309] ? __pfx_worker_thread+0x10/0x10 [ 3488.160865] ? __pfx_kthread+0x10/0x10 [ 3488.164384] ret_from_fork+0x3a8/0x7a0 [ 3488.167020] ? __pfx_ret_from_fork+0x10/0x10 [ 3488.170050] ? __switch_to+0xb76/0x1110 [ 3488.171809] ? __pfx_kthread+0x10/0x10 [ 3488.174955] ret_from_fork_asm+0x1a/0x30 [ 3488.175605] [ 3488.176206] irq event stamp: 0 [ 3488.179360] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 3488.186521] hardirqs last disabled at (0): [] copy_process+0xa08/0x3a10 [ 3488.191889] softirqs last enabled at (0): [] copy_process+0xa08/0x3a10 [ 3488.196853] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 3488.200870] ---[ end trace 0000000000000000 ]--- Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: eb3ed1e9048c ("smb: smbdirect: introduce smbdirect_accept_connect_request()") Signed-off-by: Yunseong Kim Acked-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8a953b1a47fffb71e70767bc1e914401e3c2f27f Author: Yunseong Kim Date: Tue Jul 21 02:05:17 2026 +0200 smb: smbdirect: free completion queues with ib_free_cq() [ Upstream commit fe2c0cacbcff9d56c03b296f68f22151c4223b04 ] smbdirect_connection_destroy_qp() creates the send and receive completion queues with ib_alloc_cq_any(), which for IB_POLL_WORKQUEUE arms an internal completion handler that runs ib_cq_poll_work() on a workqueue. Tearing those CQs down with ib_destroy_cq() frees them without first cancelling that poll work. If the provider posts a completion late -- for example Soft-RoCE (rxe) posting an RNR error from rxe_receiver() after rdma_destroy_qp() -- the handler re-queues ib_cq_poll_work() on the already-freed CQ, and a follow-on access faults in rxe_req_notify_cq(). Use ib_free_cq(), which cancel_work_sync()es the poll work before freeing the CQ, so no completion handler can run against a freed queue. [ 1236.599526] ================================================================== [ 1236.602142] BUG: KASAN: slab-use-after-free in ib_cq_poll_work+0xd0/0x1a0 [ 1236.605524] Read of size 8 at addr ffff888111865800 by task kworker/4:1H/82 [ 1236.609017] [ 1236.609270] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Not tainted 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy) [ 1236.609287] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 1236.609498] Workqueue: ib-comp-wq ib_cq_poll_work [ 1236.609525] Call Trace: [ 1236.609536] [ 1236.609545] __dump_stack+0x21/0x60 [ 1236.609562] dump_stack_lvl+0xc2/0x100 [ 1236.609573] print_address_description+0x77/0x200 [ 1236.609587] ? ib_cq_poll_work+0xd0/0x1a0 [ 1236.609597] print_report+0x58/0x70 [ 1236.609607] kasan_report+0x117/0x150 [ 1236.609623] ? ib_cq_poll_work+0xd0/0x1a0 [ 1236.609636] ? process_scheduled_works+0x954/0x1600 [ 1236.609650] ib_cq_poll_work+0xd0/0x1a0 [ 1236.609662] ? process_scheduled_works+0x954/0x1600 [ 1236.609674] process_scheduled_works+0xc22/0x1600 [ 1236.609698] ? __pfx_process_scheduled_works+0x10/0x10 [ 1236.609713] ? __pfx_assign_work+0x10/0x10 [ 1236.609726] ? lock_is_held_type+0x7b/0x110 [ 1236.609741] worker_thread+0x975/0xee0 [ 1236.609757] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 1236.609775] ? __kthread_parkme+0x21e/0x260 [ 1236.609789] kthread+0x3a6/0x490 [ 1236.609800] ? __pfx_worker_thread+0x10/0x10 [ 1236.609809] ? __pfx_kthread+0x10/0x10 [ 1236.609820] ret_from_fork+0x55a/0xa20 [ 1236.609835] ? __pfx_ret_from_fork+0x10/0x10 [ 1236.609850] ? __pfx_kthread+0x10/0x10 [ 1236.609861] ret_from_fork_asm+0x1a/0x30 [ 1236.609880] [ 1236.609886] [ 1236.661292] Allocated by task 5076: [ 1236.662640] kasan_save_track+0x3e/0x80 [ 1236.663842] __kasan_kmalloc+0x72/0x90 [ 1236.664763] __kmalloc_noprof+0x2b0/0x5d0 [ 1236.665356] __ib_alloc_cq+0x284/0x1000 [ 1236.666573] __ib_alloc_cq_any+0x23e/0x340 [ 1236.668654] smbdirect_connection_create_qp+0x6f7/0x1070 [ 1236.669757] smbdirect_accept_connect_request+0x500/0x1ca0 [ 1236.672625] smbdirect_listen_rdma_event_handler+0x1655/0x1c50 [ 1236.673930] cma_listen_handler+0x1bf/0x260 [ 1236.674923] cma_cm_event_handler+0x128/0x380 [ 1236.676926] cma_ib_req_handler+0x2d3d/0x4de0 [ 1236.678368] cm_process_work+0xb0/0x530 [ 1236.680454] cm_queue_work_unlock+0xb1/0x230 [ 1236.681673] cm_work_handler+0x969f/0xdca0 [ 1236.682704] process_scheduled_works+0xc22/0x1600 [ 1236.683447] worker_thread+0x975/0xee0 [ 1236.685901] kthread+0x3a6/0x490 [ 1236.688164] ret_from_fork+0x55a/0xa20 [ 1236.689522] ret_from_fork_asm+0x1a/0x30 [ 1236.690073] [ 1236.690378] Freed by task 5137: [ 1236.692242] kasan_save_track+0x3e/0x80 [ 1236.694272] kasan_save_free_info+0x40/0x50 [ 1236.695514] __kasan_slab_free+0x3a/0x60 [ 1236.696773] kfree+0x14e/0x4e0 [ 1236.697216] ib_destroy_cq_user+0x18d/0x250 [ 1236.699817] smbdirect_connection_destroy_qp+0xf2/0x280 [ 1236.702115] smbdirect_socket_destroy_sync+0x1607/0x2720 [ 1236.704062] smbdirect_socket_release+0x140/0x280 [ 1236.705286] smb_direct_free_transport+0x3b/0x90 [ 1236.707241] __ksmbd_conn_release_work+0x99/0xf0 [ 1236.709287] process_scheduled_works+0xc22/0x1600 [ 1236.710763] worker_thread+0x975/0xee0 [ 1236.711262] kthread+0x3a6/0x490 [ 1236.711720] ret_from_fork+0x55a/0xa20 [ 1236.712232] ret_from_fork_asm+0x1a/0x30 [ 1236.712762] [ 1236.712992] Last potentially related work creation: [ 1236.715157] kasan_save_stack+0x3e/0x60 [ 1236.716993] kasan_record_aux_stack+0x99/0xb0 [ 1236.718864] insert_work+0xb2/0x4a0 [ 1236.720916] __queue_work+0xebb/0x1260 [ 1236.722397] queue_work_on+0x23b/0x350 [ 1236.723809] ib_cq_completion_workqueue+0xac/0x160 [ 1236.724895] rxe_cq_post+0x433/0x7c0 [ 1236.726273] rxe_receiver+0xa41/0xd0d0 [ 1236.727754] do_work+0x272/0x860 [ 1236.728896] process_scheduled_works+0xc22/0x1600 [ 1236.730026] worker_thread+0x975/0xee0 [ 1236.731499] kthread+0x3a6/0x490 [ 1236.732132] ret_from_fork+0x55a/0xa20 [ 1236.733171] ret_from_fork_asm+0x1a/0x30 [ 1236.734224] [ 1236.734871] Second to last potentially related work creation: [ 1236.736001] kasan_save_stack+0x3e/0x60 [ 1236.737161] kasan_record_aux_stack+0x99/0xb0 [ 1236.739074] insert_work+0xb2/0x4a0 [ 1236.740414] __queue_work+0xebb/0x1260 [ 1236.740932] queue_work_on+0x23b/0x350 [ 1236.741849] ib_cq_completion_workqueue+0xac/0x160 [ 1236.744099] rxe_cq_post+0x433/0x7c0 [ 1236.745514] rxe_receiver+0xa41/0xd0d0 [ 1236.746091] do_work+0x272/0x860 [ 1236.747187] process_scheduled_works+0xc22/0x1600 [ 1236.749060] worker_thread+0x975/0xee0 [ 1236.750224] kthread+0x3a6/0x490 [ 1236.751480] ret_from_fork+0x55a/0xa20 [ 1236.751989] ret_from_fork_asm+0x1a/0x30 [ 1236.752974] [ 1236.753627] The buggy address belongs to the object at ffff888111865800 [ 1236.753627] which belongs to the cache kmalloc-1k of size 1024 [ 1236.757729] The buggy address is located 0 bytes inside of [ 1236.757729] freed 1024-byte region [ffff888111865800, ffff888111865c00) [ 1236.760816] [ 1236.761373] The buggy address belongs to the physical page: [ 1236.762599] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111860 [ 1236.764306] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 1236.765281] flags: 0x100000000000040(head|node=0|zone=2) [ 1236.765979] page_type: f5(slab) [ 1236.766410] raw: 0100000000000040 ffff8881000430c0 ffffea0004a7e210 ffffea0004586210 [ 1236.770418] raw: 0000000000000000 00000000000a000a 00000000f5000000 0000000000000000 [ 1236.775899] head: 0100000000000040 ffff8881000430c0 ffffea0004a7e210 ffffea0004586210 [ 1236.782823] head: 0000000000000000 00000000000a000a 00000000f5000000 0000000000000000 [ 1236.786239] head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff [ 1236.790658] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 1236.794132] page dumped because: kasan: bad access detected [ 1236.798301] [ 1236.799640] Memory state around the buggy address: [ 1236.802028] ffff888111865700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1236.806254] ffff888111865780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1236.809036] >ffff888111865800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1236.813968] ^ [ 1236.816416] ffff888111865880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1236.819454] ffff888111865900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1236.823143] ================================================================== [ 1236.830365] Disabling lock debugging due to kernel taint [ 1236.831136] BUG: unable to handle page fault for address: ffffc90006dc8080 [ 1236.838157] #PF: supervisor read access in kernel mode [ 1236.843686] #PF: error_code(0x0000) - not-present page [ 1236.849393] PGD 100000067 P4D 100000067 PUD 100366067 PMD 12913e067 PTE 0 [ 1236.854156] Oops: Oops: 0000 [#1] SMP KASAN NOPTI [ 1236.857893] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Tainted: G B 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy) [ 1236.860893] ksmbd: smb_direct: smbdirect_connection_recv_io_refill() failed -ECONNRESET [ 1236.864209] Tainted: [B]=BAD_PAGE [ 1236.864220] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 1236.864233] Workqueue: ib-comp-wq ib_cq_poll_work [ 1236.878314] RIP: 0010:rxe_req_notify_cq+0x13a/0x350 [ 1236.881683] Code: 20 87 fd 4c 89 fe 48 ba 00 00 00 00 00 fc ff df 4c 8b 3e 49 83 ef 80 4c 89 f8 48 c1 e8 03 0f b6 04 10 84 c0 0f 85 9b 01 00 00 <45> 8b 2f 41 80 3c 16 00 74 18 49 89 f6 48 89 f7 e8 71 20 87 fd 4c [ 1236.886819] ksmbd: smb_direct: smbdirect_connection_recv_io_refill() failed -ECONNRESET [ 1236.890671] RSP: 0018:ffff88810222f920 EFLAGS: 00010046 [ 1236.890705] RAX: 0000000000000000 RBX: ffff88810222f920 RCX: ffffffff84c92863 [ 1236.901613] RDX: dffffc0000000000 RSI: ffff888120456d48 RDI: ffff888120456d48 [ 1236.903979] RBP: ffff88810222fa20 R08: 0000000000000003 R09: 0000000000000004 [ 1236.908958] R10: dffffc0000000000 R11: ffffed1020445f10 R12: ffff888120456d40 [ 1236.914473] R13: dffffc0000000000 R14: 1ffff1102408ada9 R15: ffffc90006dc8080 [ 1236.918946] FS: 0000000000000000(0000) GS:ffff88842600d000(0000) knlGS:0000000000000000 [ 1236.921600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1236.925779] CR2: ffffc90006dc8080 CR3: 000000012b35f003 CR4: 0000000000f72ef0 [ 1236.926809] ksmbd: smb_direct: smbdirect_connection_recv_io_refill() failed -ECONNRESET [ 1236.928302] PKRU: 55555554 [ 1236.928328] Call Trace: [ 1236.928338] [ 1236.928352] ? ib_cq_poll_work+0xd0/0x1a0 [ 1236.928374] ? __pfx_rxe_req_notify_cq+0x10/0x10 [ 1236.941601] ? ib_cq_poll_work+0xd0/0x1a0 [ 1236.943306] ib_cq_poll_work+0xfe/0x1a0 [ 1236.943961] ? process_scheduled_works+0x954/0x1600 [ 1236.947036] process_scheduled_works+0xc22/0x1600 [ 1236.951626] ? __pfx_process_scheduled_works+0x10/0x10 [ 1236.954316] ? __pfx_assign_work+0x10/0x10 [ 1236.958110] ? lock_is_held_type+0x7b/0x110 [ 1236.960042] worker_thread+0x975/0xee0 [ 1236.962668] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 1236.965334] ? __kthread_parkme+0x21e/0x260 [ 1236.966058] kthread+0x3a6/0x490 [ 1236.968115] ? __pfx_worker_thread+0x10/0x10 [ 1236.971020] ? __pfx_kthread+0x10/0x10 [ 1236.974488] ret_from_fork+0x55a/0xa20 [ 1236.977419] ? __pfx_ret_from_fork+0x10/0x10 [ 1236.979846] ? __pfx_kthread+0x10/0x10 [ 1236.981238] ret_from_fork_asm+0x1a/0x30 [ 1236.984086] [ 1236.986181] Modules linked in: [ 1236.989048] CR2: ffffc90006dc8080 [ 1236.990412] ---[ end trace 0000000000000000 ]--- [ 1236.994119] RIP: 0010:rxe_req_notify_cq+0x13a/0x350 [ 1236.998482] Code: 20 87 fd 4c 89 fe 48 ba 00 00 00 00 00 fc ff df 4c 8b 3e 49 83 ef 80 4c 89 f8 48 c1 e8 03 0f b6 04 10 84 c0 0f 85 9b 01 00 00 <45> 8b 2f 41 80 3c 16 00 74 18 49 89 f6 48 89 f7 e8 71 20 87 fd 4c [ 1237.006635] RSP: 0018:ffff88810222f920 EFLAGS: 00010046 [ 1237.008513] RAX: 0000000000000000 RBX: ffff88810222f920 RCX: ffffffff84c92863 [ 1237.014100] RDX: dffffc0000000000 RSI: ffff888120456d48 RDI: ffff888120456d48 [ 1237.021058] RBP: ffff88810222fa20 R08: 0000000000000003 R09: 0000000000000004 [ 1237.024939] R10: dffffc0000000000 R11: ffffed1020445f10 R12: ffff888120456d40 [ 1237.030203] R13: dffffc0000000000 R14: 1ffff1102408ada9 R15: ffffc90006dc8080 [ 1237.034299] FS: 0000000000000000(0000) GS:ffff88842600d000(0000) knlGS:0000000000000000 [ 1237.037311] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1237.042838] CR2: ffffc90006dc8080 CR3: 000000012b35f003 CR4: 0000000000f72ef0 Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: 6073eb3e3175 ("smb: smbdirect: introduce smbdirect_connection_{create,destroy}_qp()") Signed-off-by: Yunseong Kim Acked-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 497c221bf6b2f659511719a6acfae84cc1be1caf Author: Yunseong Kim Date: Tue Jul 21 02:05:13 2026 +0200 ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user() [ Upstream commit 7405d0ba294306721843bc551611775e6edef516 ] ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with user->passkey_sz = resp->hash_sz; user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); if (user->passkey) memcpy(user->passkey, resp->hash, resp->hash_sz); resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object. ipc_validate_msg() does not bound hash_sz, so reject any response whose hash_sz exceeds the on-stack hash[] buffer before allocating and copying. [ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680 [ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611 [ 2030.242296] [ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy) [ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work [ 2030.242763] Call Trace: [ 2030.242769] [ 2030.242776] dump_stack_lvl+0xa2/0xd0 [ 2030.242794] print_address_description+0x77/0x200 [ 2030.242815] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242831] print_report+0x58/0x70 [ 2030.242848] kasan_report+0x117/0x150 [ 2030.242869] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242888] kasan_check_range+0x3c7/0x3f0 [ 2030.242908] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242925] __asan_memcpy+0x29/0x70 [ 2030.242942] ksmbd_alloc_user+0x278/0x680 [ 2030.242960] ksmbd_login_user+0xc3/0x120 [ 2030.242978] ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300 [ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208] handle_ksmbd_work+0x954/0x1280 [ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249] ? process_scheduled_works+0xa07/0x1490 [ 2030.243270] ? process_scheduled_works+0xa07/0x1490 [ 2030.243291] process_scheduled_works+0xa70/0x1490 [ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340] ? do_raw_spin_lock+0x130/0x300 [ 2030.243358] ? lock_is_held_type+0x7b/0x110 [ 2030.243388] worker_thread+0x932/0xe20 [ 2030.243415] kthread+0x38a/0x470 [ 2030.243431] ? __pfx_worker_thread+0x10/0x10 [ 2030.243451] ? __pfx_kthread+0x10/0x10 [ 2030.243467] ret_from_fork+0x484/0x910 [ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10 [ 2030.243501] ? __switch_to+0xc77/0x12c0 [ 2030.243523] ? __pfx_kthread+0x10/0x10 [ 2030.243540] ret_from_fork_asm+0x1a/0x30 [ 2030.243564] [ 2030.243570] [ 2030.290164] Allocated by task 19279: [ 2030.290911] kasan_save_track+0x3e/0x80 [ 2030.292179] __kasan_kmalloc+0x72/0x90 [ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467] handle_generic_event+0x59b/0x750 [ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553] genl_rcv_msg+0x606/0x7b0 [ 2030.297129] netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500] genl_rcv+0x2d/0x40 [ 2030.299273] netlink_unicast+0x7ba/0x930 [ 2030.300019] netlink_sendmsg+0x8c3/0xb00 [ 2030.301073] __sock_sendmsg+0xec/0x140 [ 2030.301579] __sys_sendto+0x357/0x470 [ 2030.302255] __x64_sys_sendto+0xe3/0x100 [ 2030.303425] do_syscall_64+0x135/0x460 [ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [ 2030.305819] The buggy address belongs to the object at ffff888121bb6640 [ 2030.305819] which belongs to the cache kmalloc-192 of size 192 [ 2030.309595] The buggy address is located 64 bytes inside of [ 2030.309595] allocated 166-byte region [ffff888121bb6640, ffff888121bb66e6) [ 2030.312484] [ 2030.312719] The buggy address belongs to the physical page: [ 2030.314315] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x121bb6 [ 2030.316481] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 2030.318248] flags: 0x100000000000040(head|node=0|zone=2) [ 2030.319662] page_type: f5(slab) [ 2030.320242] raw: 0100000000000040 ffff8881000424c0 ffffea00047c1510 ffff888100040468 [ 2030.321911] raw: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000 [ 2030.324413] head: 0100000000000040 ffff8881000424c0 ffffea00047c1510 ffff888100040468 [ 2030.326150] head: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000 [ 2030.327960] head: 0100000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff [ 2030.329615] head: ffff888121bb7ab0 0000000000000000 00000000ffffffff 0000000000000000 [ 2030.331861] page dumped because: kasan: bad access detected [ 2030.332946] [ 2030.333502] Memory state around the buggy address: [ 2030.334698] ffff888121bb6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2030.336475] ffff888121bb6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 [ 2030.338143] >ffff888121bb6680: 00 00 00 00 00 00 00 00 00 00 00 00 06 fc fc fc [ 2030.339116] ^ [ 2030.341315] ffff888121bb6700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2030.342801] ffff888121bb6780: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb [ 2030.344643] ================================================================== Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit abb5146b2d8197d695ea9eaa0847c73e34f00985 Author: Enzo Matsumiya Date: Wed Jul 8 09:59:12 2026 -0300 smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer [ Upstream commit 1c3ebf832d010c08afe1359215d4121cb1ed2de5 ] Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm "pool-0", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: a77e0e02af1c ("ksmbd: add support for supplementary groups") Signed-off-by: Enzo Matsumiya Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 07a9e289ff7edcc004f58952405f8a65c4e37512 Author: Guangshuo Li Date: Sun Jul 5 19:34:35 2026 +0800 ksmbd: Do not skip lock checks for single-byte ranges [ Upstream commit d40c24634fe077a0dc91fd11fccf44ce12b454d5 ] check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size. Fixes: 5d510ac31626 ("ksmbd: skip lock-range check on equal size to avoid size==0 underflow") Signed-off-by: Guangshuo Li Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit eb287c6e81dedef92da01eb947f380d0aae513c3 Author: Yiyang Chen Date: Sun Aug 16 10:56:33 2026 +0000 bpf: Check pointer type for all atomic RMW paths [ Upstream commit 4bc49ae344d65cfcef738f281ac575cf73ca2fc5 ] Atomic RMW verification records an instruction pointer type only when the current destination is PTR_TO_ARENA. A second path can therefore reach the same instruction with an ordinary pointer without comparing it against the saved arena type. The post-verification fixup uses the saved type to rewrite the instruction to BPF_PROBE_ATOMIC for every path. Record the actual destination type for all atomic RMW paths so the existing mismatch check rejects incompatible uses of one instruction. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Signed-off-by: Yiyang Chen Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260816-bpf-next-038-mixed-atomic-v1-v2-1-4644c1886dbc@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 9cd837ed9efd822cdd13c0f1cf97d5113db11f8b Author: Marius Cristea Date: Thu Aug 13 11:40:07 2026 +0300 hwmon: (emc1403) Drop hysteresis for low limit temperature [ Upstream commit 75f2c0b3690702c90863c2e138cb5520670845ea ] Remove the hysteresis for low temperature limit, in hardware the hysteresis is applied only to the maxim limit and the critical limit temperature. Fixes: 54392ce4446e3 ("hwmon: (emc1403) Add support for min_hyst attributes") Signed-off-by: Marius Cristea Link: https://lore.kernel.org/r/20260813-emc1403_remove_min_hyst-v1-1-43a0d05d9f49@microchip.com [groeck: Updated subject] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9b23a010a1e8232974617c412cb9f578f3378b70 Author: Szymon Wilczek Date: Mon Aug 10 21:23:44 2026 +0200 hwmon: (coretemp) Fix core_data leak on CPUs without PTS [ Upstream commit 0cd8450c257faa0cece0e0c43d3b55d1a389acc7 ] pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles. Fixes: 1a793caf6f69 ("hwmon: (coretemp) Use dynamic allocated memory for core temp_data") Signed-off-by: Szymon Wilczek Link: https://lore.kernel.org/r/20260810192344.3733721-1-swilczek.lx@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 072fb5aeec2eac7d445bf28c7119a1d6f6a2e333 Author: John Johansen Date: Wed Aug 12 02:27:15 2026 -0700 apparmor: fix deadlock in complain-mode change_hat [ Upstream commit 4ec11f14d1d6fdda787d991b142537be7841d395 ] The use of change_hat when in complain mode can cause a deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is because change_hat() has taken the lock to search the hat list and creating the new learning profile needs to take the lock to add it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su in complain mode set to change hats. Then verified in newest available vanilla kernel I've compiled to see if still present: 7.2-rc7 vanilla -> affected checked also some other kernels: 6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected On systems without bug (for example 6.12.95 debian) it just prints: aa_change_hat rc=0 On systems with bug, the executable always hangs, prints nothing and becomes unkillable. (And once stuck this way, it will cause any further hat changes to also cause the changing process to get stuck) Then in syslog you can find hint about cause: kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: kernel: __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel: __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel: build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710 kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel: apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel: __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ? __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ? __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ? do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ? count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ? do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel: kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409. To fix the issue, lift the locking out of the core of aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues introduced by commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat() without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the new label reference is put, and then used for the next lookup. The mutex_lock, will block replacement, and removal in the locked ns. However there are two cases where putting the reference can result in the label being freed even with the lock held. 1. the label does not have a list reference (possible for temporary or special profiles) in which case the put can trigger the cleanup. 2. the new label reference is in a different namespace, which does not have a lock held on it. This extends case 1 to also include replacement, and removal that could be occurring in the namespace new is in. Reported-by: Martin Petricek Link: https://lists.ubuntu.com/archives/apparmor/2026-August/014907.html Fixes: 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit c5a6c30e6ee7ac46012e39b1d5c2e66e2dbad1d2 Author: Mike Rapoport (Microsoft) Date: Wed Aug 12 11:17:40 2026 +0300 selftests/mm: thuge-gen: fix test_shmget() for PAGE_SIZE check [ Upstream commit 08745c62350126bc31b09548137be87e2866f628 ] Commit 49a4e7186b08 ("selftests/mm: thuge-gen: add setup of HugeTLB pages") changed thuge-gen test to use common functions for reading hugetlb attributes from sysfs, but it missed that the original read_free() function special cased PAGE_SIZE tests. For PAGE_SIZE tests, failure to read sysfs was ignored and read_free() returned 0. This allowed test_shmget() to essentially skip the check of how many huge pages was consumed when it ran with PAGE_SIZE. Commit 3199b0c09efa ("selftests/mm: fix read_file() return value check") fixed checks for read_file() return value and this exposed the issue in test_shmget() that checks the number of free hugetlb pages even for PAGE_SIZE test, tries to access /sys/kernel/mm/hugepages/hugepages-/free_hugepages and obviously fails there. Gate the checks for free huge pages on size != getpagesize() and initialize before and after variables to values matching PAGE_SIZE test. Link: https://lore.kernel.org/20260812-selftests-thuge-gen-fix-v2-1-9adaa693e73b@kernel.org Fixes: 49a4e7186b08 ("selftests/mm: thuge-gen: add setup of HugeTLB pages") Acked-by: David Hildenbrand (Arm) Reviewed-by: Sarthak Sharma Acked-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Cc: Liam R. Howlett Cc: Michal Hocko Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b389dc35a55713ac24a145741e76196fea1663bc Author: Hongyan Xu Date: Thu Aug 6 14:04:41 2026 +0800 block: mtip32xx: synchronize ioctls with device removal [ Upstream commit 68940f841d013192086a0f6d7cfbac2cd079e228 ] The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down. Fixes: 88523a61558a ("block: Add driver for Micron RealSSD pcie flash cards") Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/20260806060441.676-1-getshell@seu.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b9cc6cc74daf6fef533dbe65d8cee779fea69600 Author: Yao Sang Date: Tue Aug 4 20:57:36 2026 +0800 ublk: avoid teardown retry loop on xarray allocation failure [ Upstream commit 4fd66a7f829f3f38f92a79081f0f2688aed644f0 ] __ublk_shmem_remove_ranges() removes matching maple tree ranges in batches, but first stores each range into a temporary xarray so that the pages can be unpinned after dropping the maple tree lock. That temporary xarray is filled under the maple tree lock with xa_store(..., GFP_ATOMIC). If the store fails before mas_erase(), the current range is left in the tree and the helper returns false. The outer ublk_shmem_remove_ranges() loop then immediately retries the same range. While the atomic allocation keeps failing, the teardown path has no forward progress. The issue can be reproduced with radix_tree_node failslab injection after a SHMEM_ZC buffer has already been registered: # Kernel config: # CONFIG_BLK_DEV_UBLK=y # CONFIG_DEBUG_FS=y # CONFIG_FAULT_INJECTION=y # CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAILSLAB=y echo 10 > /proc/sys/vm/nr_hugepages mkdir -p /tmp/htlb mount -t hugetlbfs none /tmp/htlb fallocate -l 4M /tmp/htlb/ublk_buf dev_id=$(kublk add -t null --shmem_zc \ --htlb /tmp/htlb/ublk_buf | awk -F '[ :]' '/dev id/ {print $3}') echo 1 > /sys/kernel/slab/radix_tree_node/failslab echo Y > /sys/kernel/debug/failslab/cache-filter echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait echo 1 > /sys/kernel/debug/failslab/interval echo -1 > /sys/kernel/debug/failslab/times echo 100 > /sys/kernel/debug/failslab/probability kublk del -n "$dev_id" On the unfixed kernel the delete command was still running after 3 seconds. Disabling failslab made it return. The fault-injection stack showed: should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev Remove the allocation from the teardown loop. Keep the existing batch limit, but collect {base_pfn, nr_pages} pairs in a fixed-size stack array. Once a matching range is found, the range is erased from the maple tree before dropping the lock, so each successful scan makes progress without depending on any GFP_ATOMIC allocation. With the same failslab settings, the fixed kernel completed "kublk del -n $dev_id" successfully in about 45 ms. Fixes: 309e02dccf64 ("ublk: avoid unpinning pages under maple tree spinlock") Signed-off-by: Yao Sang Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260804125736.2011774-1-sangyao@kylinos.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6220421b97296ded4af36653b3a1c6faec41a51f Author: Yao Sang Date: Fri Aug 14 10:32:24 2026 +0800 ublk: reject non-power-of-2 zone sizes in SET_PARAMS [ Upstream commit 2707acf1856da266139986c9398ad722fd4f48c0 ] UBLK_F_ZONED uses params.basic.chunk_sectors as zone size. ublk uses ilog2(chunk_sectors) to get number of zones, so the value must be power of 2. If chunk_sectors is 96 and dev_sectors is 96 * 16, userspace asks for 16 zones. But the shift calculation gets 24 zones. Block layer rejects such zone size when the disk is started. But SET_PARAMS has already returned success, which is confusing for userspace. Reject it in SET_PARAMS with other zoned parameter checks. Fixes: 29802d7ca33b ("ublk: enable zoned storage support") Signed-off-by: Yao Sang Link: https://patch.msgid.link/20260814023226.354288-2-sangyao@kylinos.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b9c16db833e3ff15d923282f94dddf0e10fab8c0 Author: Usama Arif Date: Fri Aug 14 09:56:38 2026 -0700 blk-iocost: clear delay state when freeing policy data [ Upstream commit 97cb95d2148835ae86ff916b145aef332d40439d ] iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count. Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path. ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for the rest of its life. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear it explicitly, after the list removal and the synchronous hrtimer_cancel() so that neither timer processing nor an I/O path can re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Usama Arif Acked-by: Tejun Heo Link: https://patch.msgid.link/20260814165712.510132-3-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 02f1b90ab33ef99c89dd96a385b432ff57abc64d Author: Usama Arif Date: Fri Aug 14 09:56:37 2026 -0700 blk-iolatency: clear delay state when freeing policy data [ Upstream commit 8935bf22c0a0db517a7f72f7097300e05dd852f5 ] io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0. iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->use_delay set and blkcg->congestion_count elevated with nothing left that can drop it. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear the delay in iolatency_pd_free(). By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so check_scale_change() cannot re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check. Fixes: d70675121546 ("block: introduce blk-iolatency io controller") Signed-off-by: Usama Arif Acked-by: Tejun Heo Link: https://patch.msgid.link/20260814165712.510132-2-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3 Author: Niklas Cassel Date: Thu Aug 13 16:14:56 2026 +0200 null_blk: serialize configfs attribute updates with device setup [ Upstream commit 4e1f23f9c33c156be7e313b40695af5a3a834739 ] The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX(). Fixes: 3bf2bd20734e ("nullb: add configfs interface") Reported-by: syzbot+643a6dd130546afdf1fb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-block/6a7d0b3f.ac361c09.22ff0a.004c.GAE@google.com/ Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260813141456.1625857-2-cassel@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c70994c2862b05e44728912b2ea9487d31e2aea7 Author: Zizhi Wo Date: Sat Jul 25 10:25:08 2026 +0800 null_blk: serialize configfs attribute stores with the lock [ Upstream commit 7e7fff51808237703a3a1df6dd5cae1dfd1db86d ] The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Suggested-by: Bart Van Assche Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-10-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit baff300541a0012907cdde349728739fe16176d7 Author: Zizhi Wo Date: Sat Jul 25 10:25:06 2026 +0800 null_blk: reject per-device queue resize for shared tag set [ Upstream commit 1cdfe2fa62b48728a9b436fbbd3dbe4c11593e24 ] When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Suggested-by: Nilay Shroff Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260725022509.714271-8-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0a3afab87124171022fb3579502fa38ef5b311c9 Author: Zizhi Wo Date: Sat Jul 25 10:25:04 2026 +0800 null_blk: free zones array on device power-off [ Upstream commit 2a6357a9b935a34f5508618fee8a7fffbf7722a8 ] null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface. Fixes: ca4b2a011948 ("null_blk: add zone support") Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260725022509.714271-6-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 081cf37e8a0e00cd91d6df53172c9d928790a798 Author: Zizhi Wo Date: Sat Jul 25 10:25:03 2026 +0800 null_blk: free global tag_set on init error path [ Upstream commit 5a1c5ff3a49ba93a1fd0b70537e7a0164071760d ] If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set). Fixes: 82f402fefa50 ("null_blk: add support for shared tags") Signed-off-by: Zizhi Wo Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-5-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cab9bf5f68f76cd44e0ec92bd4a60c9b83656a36 Author: Zizhi Wo Date: Sat Jul 25 10:25:01 2026 +0800 null_blk: register configfs subsystem after creating default devices [ Upstream commit c9d293d6bb0575fcb1f3408129453187e2a28a4e ] In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above. Fixes: 3bf2bd20734e ("nullb: add configfs interface") Signed-off-by: Zizhi Wo Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-3-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 234117949da3b3f9705a21b66094f9f30bbe681d Author: Zizhi Wo Date: Sat Jul 25 10:25:00 2026 +0800 null_blk: use DEFINE_MUTEX for the file-scope mutex [ Upstream commit 017dac7670909eaea3eb36e6b3b5a8be9ce0a14d ] In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue. Fixes: 49c3b9266a71 ("block: null_blk: Improve device creation with configfs") Suggested-by: Bart Van Assche Signed-off-by: Zizhi Wo Reviewed-by: Bart Van Assche Reviewed-by: Damien Le Moal Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-2-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c7bc5e7677bcda7a446d63b989cfaa3fe91d6b76 Author: Pengpeng Hou Date: Fri Aug 14 16:02:15 2026 +0800 mailbox: riscv-sbi-mpxy: validate RPMI notification lengths [ Upstream commit 11d5af151bcbe78f5a579e0faecd3be9cea0399a ] The SBI return value controls how many bytes are copied from shared memory into the RPMI notification buffer. It is not validated against the negotiated shared-memory size before that copy. The event walker also uses a reversed loop condition and can inspect a short event record. Validate the complete notification length before copying it, iterate only while a full event header remains, and stop when a declared event payload extends beyond the copied notification data. Fixes: bf3022a4eb11 ("mailbox: Add RISC-V SBI message proxy (MPXY) based mailbox driver") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c362e993e3a55fad147c6395c92a7ac6a03b3b6f Author: Huisong Li Date: Thu Jul 23 15:39:28 2026 +0100 mailbox: pcc: Fix command timeout due to missed interrupt [ Upstream commit 3360b088175dc5d5c9166685836158470d00571e ] PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li Signed-off-by: Sudeep Holla Tested-by: Adam Young Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 53281c3a89cf9fa69d55ee309f05a42da375c4c9 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 b3d73e7440e0c40644285be1bda349cdf90122d8 Author: Jia Yang Date: Thu Aug 6 15:03:57 2026 +0800 mailbox: qcom-cpucp: handle NULL data in send_data callback [ Upstream commit fc4f2f99530298a1739226947aa76525142d421d ] mailbox_clear_channel() calls mbox_send_message() with NULL data to notify the remote side that the RX channel has been cleared. qcom_cpucp_mbox_send_data() blindly dereferenced the data pointer, causing a NULL pointer dereference kernel panic when invoked from this path under PREEMPT_RT. Add an explicit NULL check and return early without writing to the TX register, which is the correct behaviour for a channel-clear notification. Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller") Signed-off-by: Jia Yang Reviewed-by: Dmitry Baryshkov Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit e40b3edeaf25cd09e9c88edb1ef99373ca37593b Author: Jia Yang Date: Thu Aug 6 15:03:56 2026 +0800 mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler [ Upstream commit 3690aaa6d18f6775c3e7932fb8af8c5bf6a6b69c ] qcom_cpucp_mbox_irq_fn() calls mbox_chan_received_data() while holding chan->lock. Under PREEMPT_RT, spin_lock_irqsave() is converted to an rt_spinlock (rtmutex-based), which tracks ownership and can sleep. The callback chain triggered by mbox_chan_received_data() eventually reaches mailbox_clear_channel() -> mbox_send_message() -> add_to_rbuf(), which attempts to re-acquire the same chan->lock. Since rtmutex detects the re-entrant lock attempt by the same owner, the thread blocks waiting for a lock it already holds, causing a permanent deadlock. This deadlock manifests as 'irq/N-apss_cpucp_mbox' stuck in D state with the following call trace: rt_spin_lock -> mbox_send_message -> mailbox_clear_channel -> scmi_rx_callback -> mbox_chan_received_data [<- held chan->lock here] Fix by saving chan->cl locally and clearing the HW interrupt register inside the lock, then invoking mbox_chan_received_data() after releasing the lock. This preserves the mutual exclusion for chan->cl access while avoiding the lock re-entrancy that causes the PREEMPT_RT deadlock. Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller") Signed-off-by: Jia Yang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit f445e7be37ce1c757f425f7ea15bffb74ee746ce Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:46 2026 -0300 perf dso: Replace assert with runtime check in dso__read_symbol() [ Upstream commit 62972e5644e48255dcc715e6ec4401882f8b37d1 ] dso__read_symbol() asserts that len <= jited_prog_len, where len comes from sym->end - sym->start (parsed from PERF_RECORD_KSYMBOL in perf.data). Both values originate from untrusted file input. With NDEBUG (production builds), the assert is compiled out, allowing an out-of-bounds heap read when the BPF program buffer is accessed. Without NDEBUG, a crafted perf.data crashes perf with an assertion failure. Replace the assert with a runtime bounds check that returns NULL with an appropriate error code, matching the existing error handling pattern in this function. Fixes: aa04707f507e ("perf dso: Support BPF programs in dso__read_symbol()") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Song Liu 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 94d82e7a95b51decfcf8dcaa3121e469997fccd4 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 b3339e4bd7a13e7a807b9e9725fefcfc71365262 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:44 2026 -0300 perf dso: Use stored fd error instead of stale errno in file_read() and file_size() [ Upstream commit 075d2c32353ded0fe5f3b62f4aa4e98dccb3fb29 ] file_read() and file_size() use ret = -errno when dso__data(dso)->fd is negative after try_to_open_dso() fails. By this point errno has been through mutex_lock(), nsinfo__mountns_enter(), and multiple open() attempts inside try_to_open_dso() — it no longer reflects the actual open failure. If errno happens to be 0, ret = 0 looks like EOF rather than an error, and file_size() callers like dso__data_size() would then report a zero-sized file instead of failing. dso__data(dso)->fd is always negative on failure — -errno from __open_dso() when no filename could be built (e.g. -EINVAL, -ENOENT), or -1 when do_open() itself failed — and never 0, so use it directly instead of reading the stale global errno. No assert() or comment is needed after the assignment: the enclosing if (dso__data(dso)->fd < 0) already guarantees ret < 0 [Namhyung Kim review]. Fixes: 33bdedcea2d7 ("perf tools: Protect dso cache fd with a mutex") 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 2482a7b86a2bdf55fca33d5e588c327c5383d6f3 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 bd98711ed867e978544193aad99e6135cfcf7e97 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:42 2026 -0300 perf dso: Guard against errno==0 when dso__get_filename() returns NULL [ Upstream commit 51a7a9ddcb3ebc86615886b1f44e85bdea9df326 ] __open_dso() computes fd = -errno when dso__get_filename() returns NULL. Some failure paths in dso__get_filename() (e.g. binary type mismatch) return NULL without making a syscall, leaving errno at 0 from a prior successful call. fd = -0 = 0, which is stdin — subsequent code treats it as a valid file descriptor. Fall back to ENOENT when errno is 0, ensuring fd is always negative on failure. The forced ENOENT stays in errno for the callers that check it after a negative fd. It must not misdirect the try_to_open_dso() fallback loop, though: dso__get_filename()'s chroot fallback used to accept a stale ENOENT even when stat() succeeded on a non-regular file (e.g. a directory). Re-stat() there and only take the chroot path when stat() actually failed with ENOENT [sashiko-bot review of PATCH 1/5]. Fixes: eba5102d2f0b ("perf tools: Add global list of opened dso objects") 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 a0161780a0b89d161400842ccb491bf140ffe94b Author: Tejun Heo Date: Fri Aug 14 23:44:52 2026 -1000 sched_ext: Make SCHED_CLASS_EXT select GENERIC_ALLOCATOR [ Upstream commit 524ab50763af33d65e6e042cf7034cd8f82d437b ] kernel/sched/ext/arena.c uses the gen_pool allocator, which is built only when GENERIC_ALLOCATOR is set. SCHED_CLASS_EXT doesn't select it, so on configs where nothing else does, the build fails to link: build_policy.o: undefined reference to `gen_pool_create' build_policy.o: undefined reference to `gen_pool_for_each_chunk' build_policy.o: undefined reference to `gen_pool_destroy' Fixes: 9eca087deb0b ("sched_ext: Sub-allocator over kernel-claimed BPF arena pages") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608151315.tvN3X0Oq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202608151632.3p91bTQj-lkp@intel.com/ Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit ed30a1892c630c17298e469866cce01a6bfb3ee9 Author: Tao Cui Date: Sat Aug 15 12:59:05 2026 +0800 sched_ext/scx_flatcg: Fix cvtime true-up on slice expiry [ Upstream commit 9b4243d30469e7733730e786792d1560442e229e ] fcg_dispatch() true-ups the current cgroup's cvtime when its slice expires or its DSQ runs empty while the slice is still active: __sync_fetch_and_add(&cgc->cvtime_delta, (cpuc->cur_at + cgrp_slice_ns - now) * FCG_HWEIGHT_ONE / (cgc->hweight ?: 1)); The true-up should be actual minus charged: on CNS_EXPIRE, the overrun (now - cur_at - cgrp_slice_ns) should be added; on CNS_EMPTY, the unused portion of the slice should be subtracted. The expression above has the sign inverted, and in the CNS_EXPIRE case now is already past cur_at + cgrp_slice_ns, so the u64 subtraction wraps. The multiplication preserves the two's complement encoding but the unsigned division by hweight destroys it, adding roughly 2^64/hweight per expiry instead of a small correction. Under saturation the hweight budget clamp in cgrp_cap_budget() masks most of the garbage, so the weight distribution barely moves, but the accounting is broken all the same. Compute the delta as a signed value and use fetch_and_add()/fetch_and_sub() so that the dividends stay positive, as BPF division is unsigned. Instrumented the true-up and ran a saturated three-leaf cgroup tree on a 4-CPU VM: without the fix, each expiry added ~5e15 (2^64/hweight territory) to cvtime_delta; with it, the corrections are back to slice scale, with the overrun added and the unused portion subtracted. Fixes: a4103eacc2ab ("sched_ext: Add a cgroup scheduler which uses flattened hierarchy") Suggested-by: Tejun Heo Signed-off-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 97bdcf58c0d6d8318d0dd6825d69f517063a1942 Author: Tejun Heo Date: Fri Aug 14 23:47:39 2026 -1000 sched_ext: Drop unlocked scx_rq_clock_invalidate() from scx_root_disable() [ Upstream commit d44093323131a42a85184315bb9b6da4813cc39b ] scx_root_disable() invalidates each rq's clock before taking the rq lock. scx_rq_clock_invalidate() is a plain read-modify-write of rq->scx.flags and every other writer of the word runs under the rq lock, so the unlocked update can race a concurrent flags update and lose one side's bits. The invalidation doesn't matter in the first place. The cached clock is read only by scx_bpf_now() from a loaded scheduler's BPF programs, nothing can re-validate the clock while sched_ext is disabled as scx_rq_clock_update() is gated on scx_enabled() too, and the usual rq lock cycles under the next scheduler refresh or invalidate it before it's practically observable. Drop the invalidation instead of fixing the locking. v2: Description and comment updated - the invalidation is unnecessary rather than subsumed by the rq lock cycle below. Fixes: 3a9910b5904d ("sched_ext: Implement scx_bpf_now()") Signed-off-by: Tejun Heo Cc: Changwoo Min Signed-off-by: Sasha Levin commit 9e099588ee6aad3814e3d2bc1f09aea002a3760b Author: Karl Mehltretter Date: Sat Aug 8 13:48:48 2026 +0200 crypto: lskcipher - propagate errors from unaligned crypt [ Upstream commit 7537036a2e6fe96f8ed82034f755c54714a0e417 ] The while loop declares a second err variable that shadows the outer one. When the crypt callback fails, the goto out path returns the outer err, which still holds the -ENOMEM value assigned before the successful allocation check. The real error from the cipher is discarded and the caller sees -ENOMEM instead. Drop the inner declaration so the callback error reaches the caller. Verified with a test module that registers an lskcipher whose encrypt callback fails with -EIO and calls it through a misaligned buffer. An unpatched kernel returns -ENOMEM, a patched kernel returns -EIO. Found with Clang's -Wshadow. Fixes: 31865c4c4db2b ("crypto: skcipher - Add lskcipher") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ed9ab15652c24970538246d49cab7b1f5f398e7d Author: Zhushuai Yin Date: Tue Aug 4 10:22:07 2026 +0800 crypto: hisilicon/sec2 - fix CCM algorithm long packet failure [ Upstream commit b82f60be50c87b3d75e207852c5ca74fa18f66cf ] In the CCM B0 block the message-length field Q spans L bytes, where L (cl in the driver) is derived from the cipher IV flags byte as c_ivin[0] + 1. set_aead_auth_iv() hardcoded writing only the last 2 bytes of a_ivin with cryptlen, implicitly assuming cl = 2. When cl = 3 (a shorter nonce yielding a 3-byte length field) and the packet is longer than 65535 bytes, cryptlen no longer fits in 2 bytes. The dropped high byte made the auth IV built by the driver differ from the one consumed by the hardware, so the software/hardware comparison failed and the CCM request errored out. Write the last cl bytes of a_ivin in a loop driven by the IV's CL value, so the length-field width always matches the algorithm configuration instead of assuming a fixed 2-byte field. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Zhushuai Yin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9eb64cfc9554225c82d5f74e6a64d8bae00ad37f Author: Michal Blaszczyk Date: Tue Aug 11 14:13:58 2026 +0000 selftests/sched_ext: Fix flaky ddsp failure tests on busy systems [ Upstream commit e72979d3264a87a6a2dfb44fe0f5723a17d2ef84 ] The ddsp_vtimelocal_fail and ddsp_bogus_dsq_fail tests skip calling scx_bpf_dsq_insert_vtime() if scx_bpf_pick_idle_cpu() fails to find an idle CPU (returns a negative error code). On loaded systems, this results in the tests skipping the very assertions they are meant to verify. Eliminate this flakiness by falling back to prev_cpu if no idle CPU is found, ensuring the illegal dispatch operations are unconditionally attempted and tested. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Michal Blaszczyk Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 69f5815a0910bc0023a3bbe26b82b0fdde5ee0ea 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 10158c8aa7bb96dfc8e0063a9770268b69d44134 Author: Ihor Solodrai Date: Fri Aug 14 10:35:21 2026 -0700 selftests/bpf: Fix selftest build after filter.h update [ Upstream commit a2b83a8c8430b5a4cb43a1671c62535afcfce78d ] Upstream commit 7a1f400ff5e5 ("tools: Ensure tools copy of linux/filter.h exports the UAPI") caused selftests/bpf build to fail [1] with: In file included from progs/arena_atomics.c:9: /codebuild/output/src2365462129/src/actions-runner/_work/bpf/bpf/tools/testing/selftests/bpf/../../../include/linux/filter.h:9:10: fatal error: 'uapi/linux/filter.h' file not found 9 | #include | ^~~~~~~~~~~~~~~~~~~~~ 1 error generated. CLNG-BPF [test_progs] bind_perm.bpf.o make: *** [Makefile:888: /codebuild/output/src2365462129/src/actions-runner/_work/bpf/bpf/tools/testing/selftests/bpf/arena_atomics.bpf.o] Error 1 make: *** Waiting for unfinished jobs.... GEN-OBJ [libarena] libarena.bpf.o GEN-SKEL [libarena] libarena.skel.h make: Leaving directory '/codebuild/output/src2365462129/src/actions-runner/_work/bpf/bpf/tools/testing/selftests/bpf' Process completed with exit code 2. BPF selftest programs include the tools header directly, but BPF_CFLAGS only exposes tools/include/uapi. Compiler therefore cannot resolve the nested UAPI include. Add tools/include after tools/include/uapi in BPF_CFLAGS. This preserves the existing UAPI header precedence while allowing tools headers to include uapi headers. [1] https://github.com/kernel-patches/bpf/actions/runs/31806678733/job/94787271162 Fixes: 7a1f400ff5e5 ("tools: Ensure tools copy of linux/filter.h exports the UAPI") Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814173522.2783625-1-ihor.solodrai@linux.dev Signed-off-by: Sasha Levin commit c98a1abbda87127d5003508b075338c755a16cce Author: Rafael J. Wysocki Date: Mon Aug 10 13:40:18 2026 +0200 ACPI: scan: Use acpi_bus_get_primary_device() [ Upstream commit 87ee7d704f69f303c86b2dcf617e33764371fe7b ] The acpi_get_first_physical_node() usage in acpi_create_video_bus_device() is generally unsafe because in theory the device returned by it may be freed at any time. Address this issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and dropping the device reference acquired by it after registering the child. Fixes: 6ab3532b4c98 ("ACPI: video: Switch over to auxiliary bus type") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/10906414.nUPlyArG6x@rafael.j.wysocki Signed-off-by: Sasha Levin commit c9d202d3b6c28e8c779cd2f2b10d2f7ab665ca71 Author: Rafael J. Wysocki Date: Mon Aug 10 13:38:08 2026 +0200 ACPI: platform: Use acpi_bus_get_primary_device() [ Upstream commit a9ba4dd2f18bf3f439d9ef0d8f375f90360ba1bd ] The acpi_get_first_physical_node() usage in acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the device returned by it may be freed at any time [1]. It is also inefficient because acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided. Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the device reference acquired by it upon the return from that function. Fixes: 3b95bd160547 ("ACPI: introduce a function to find the first physical device") Fixes: a252d881c558 ("ACPI / platform: Pay attention to parent device's resources") Link: https://sashiko.dev/#/patchset/12955541.O9o76ZdvQC%40rafael.j.wysocki [1] Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/3436112.aeNJFYEL58@rafael.j.wysocki Signed-off-by: Sasha Levin commit 5657859851abb65105220a6cdb5804926249f714 Author: Rafael J. Wysocki Date: Wed Aug 12 14:41:44 2026 +0200 ACPI: bus: Introduce acpi_bus_get_primary_device() [ Upstream commit 72530e1f72b0515a73fd88292254d04fecf03649 ] The function used for obtaining the first "physical" device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last reference to the "physical" device may be dropped then before the pointer to it is returned to the caller. If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for addressing this problem, introduce a new function for getting the first "physical" device associated with the given ACPI one (the "primary physical device") that will also reference count the device in question before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the physical node list lookup code. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/2843318.mvXUDI8C0e@rafael.j.wysocki Stable-dep-of: a9ba4dd2f18b ("ACPI: platform: Use acpi_bus_get_primary_device()") Signed-off-by: Sasha Levin commit 0b9053cd0955c7cd66d71a8442be33926d70e197 Author: Hongyan Xu Date: Sat Aug 8 16:59:42 2026 +0800 ACPI: scan: fix bus ID cleanup on device_add() failures [ Upstream commit a414485ebc2aa50907d0ce97cde2b1a353696897 ] When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. Fixes: d783156ea384 ("ACPI / scan: Define non-empty device removal handler") Signed-off-by: Hongyan Xu [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260808085943.526-1-getshell@seu.edu.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6f21453927d0aed918deeb19ce85aad5ee620df1 Author: Vincent Donnefort Date: Thu Aug 13 14:11:50 2026 +0100 ring-buffer: Remove trace_buffer::cpus [ Upstream commit d9b5e22bf24d5c82522475306cd332b287ac43bc ] The 'cpus' field in struct trace_buffer became useless in commit 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order"). Remove it Link: https://patch.msgid.link/20260813131152.3589632-9-vdonnefort@google.com Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 71dbd143be598954ae103feadd12692aeb0f2f88 Author: Pu Lehui Date: Fri Aug 14 06:47:26 2026 +0000 riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args [ Upstream commit f2aaa621591093cfe8224a25ef2f04a3b1e304b0 ] On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc args. However, the RV64 JIT currently does not perform sign-extension for such kfunc args. Before commit 7ce090afbf72 ("bpf: Infer zext_dst based on static register liveness analysis"), state pruning could potentially omit zero-extension of 32-bit subregisters, which inadvertently masked the above issue by making the args appear as if they had been properly sign-extended. After that commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4 selftest to fail. Fix this by extending the existing sign-extension logic to handle signed 1-byte and 2-byte kfunc args as well. Fixes: 443574b03387 ("riscv, bpf: Fix kfunc parameters incompatibility between bpf and riscv abi") Signed-off-by: Pu Lehui Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260814064726.3607615-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit e62b867143ef89c1c1460d147cb1a6d4b6ffbe3e Author: Mykyta Yatsenko Date: Wed Aug 12 07:47:22 2026 -0700 bpf: Fix arm64 KASAN false positive after bpf_throw [ Upstream commit b0e872a31e157d48479507c2821ba8bf6323b7ad ] arm64 passes zero as the stack pointer while walking BPF frames, so bpf_throw() leaves stale KASAN stack poison after jumping to the exception callback. Use the frame pointer as the fallback stack watermark. Fixes: e74cb1b42213 ("arm64: stacktrace: Implement arch_bpf_stack_walk() for the BPF JIT") Signed-off-by: Mykyta Yatsenko Signed-off-by: Daniel Borkmann Tested-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260812-hello_world-v1-1-c3c2ddcb362d@meta.com Signed-off-by: Sasha Levin commit a3e6a9bd5ee8adbbf0c06ce0cd62e3388132cc0b Author: Andrii Nakryiko Date: Thu Aug 13 14:35:58 2026 -0700 selftests/bpf: Use ping_command() for IPv6 pings in lwt_ip_encap [ Upstream commit 073574da7a8e6055b1687c256bea070ab4b4ebea ] lwt_ip_encap hardcodes the ping6 binary for its IPv6 pings. iputils merged ping6 into ping long ago and distros have started dropping the compat symlink -- Arch's iputils 20250605 ships only arping, clockdiff, ping and tracepath. There, every lwt_ip_encap subtest fails: check_ping_ok:FAIL:ip netns exec ns-lwt-ip-encap-1-0101330 ping6 -c 1 \ -W1 -I veth1 fb04::1 > /dev/null unexpected error: 256 (errno 2) #217/1 lwt_ip_encap_ipv4/egress:FAIL The IPv4 subtests fail too, because check_ping_ok() pings both families. SYS() runs the command through system(), so a missing binary is indistinguishable from an unreachable peer. network_helpers.c has had ping_command() for exactly this since commit 372642ea83ff ("selftests/bpf: Move netcnt test under test_progs"): it falls back to "ping -6" when ping6 is not present. lwt_ip_encap.c is the last hardcoded ping6 user. Fix that. Fixes: f5e288943e2c ("selftests/bpf: Move test_lwt_ip_encap to test_progs") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20260813213558.3103179-1-andrii@kernel.org Signed-off-by: Sasha Levin commit aa7200c77b8b6afc413be1416b282699766f8c05 Author: Linmao Li Date: Fri Jul 10 18:23:14 2026 +0800 HID: tmff: Use 64-bit arithmetic for force feedback scaling [ Upstream commit 463f7cc26ce3ccc8fb76d6194f83214be7105e2f ] The logical minimum and maximum values come from the HID report descriptor and cover the full signed 32-bit range. Subtracting them in an int can overflow before the force feedback value is scaled. The subsequent multiplication can overflow as well, producing an incorrect value despite the final range checks. Use 64-bit intermediates for both scaling helpers, as done by commit 48d1677779ad ("HID: pidff: Fix integer overflow in pidff_rescale") for the same arithmetic in the PID driver. This keeps the arithmetic defined for the complete descriptor range before the result is clamped. Fixes: dc76c912145f ("Input: use new FF interface in the HID force feedback drivers") Fixes: b27c9590ca0f ("HID: add support for Thrustmaster FGT Force Feedback wheel") Signed-off-by: Linmao Li Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 351cdfcd097d043c56fef3445c270900ca0b0adc Author: Xianglin Lin <1021538027@qq.com> Date: Sat Jul 11 22:22:55 2026 +0800 HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU [ Upstream commit 69226cd6fad7a07370ec9a009af1c174de7635c5 ] Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was necessary because the device sometimes fails to send touch release signals when transitioning from >=2 fingers to <2 fingers, and MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing contacts as released. However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES. As a result, after a two-finger scroll finger lift, the device still reports stale coordinates from the released contact in subsequent frames, and the driver overwrites the remaining active slot with those frozen coordinates. The remaining finger appears stuck at the lift position until all fingers are lifted. This was confirmed via evtest on Arch Linux 7.1.3: after TRACKING_ID=-1 for the released slot, every subsequent frame contained duplicate position pairs -- the real moving finger's coordinates followed by the lifted finger's frozen position, both attributed to the active slot. Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU (0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE, IGNORE_DUPLICATES), preventing stale coordinate contamination. The additional FORCE_MULTI_INPUT flag is harmless here: it separates the mouse and touchpad collections into distinct input devices, which is the standard behavior libinput already expects. Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") Signed-off-by: Xianglin Lin <1021538027@qq.com> Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 72d0b77412aef2cec554cc84e176658f2a48dafa Author: Pengpeng Hou Date: Fri Aug 14 16:12:38 2026 +0800 ASoC: SOF: validate topology volume range before allocation [ Upstream commit a698e4a60fa54268a38f4e66378851a196cb139b ] SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table. Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20260814081238.25434-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c44b8673baba6947d32f82c11af2307043bc6dd Author: Steven Rostedt Date: Thu Aug 13 20:42:26 2026 -0400 tracing: Have trace_event_update_all() only handle module that is loading [ Upstream commit ae70b04ab9c7f6162a8c0fdd18a62a945c133142 ] The function trace_event_update_all() does a scan of events looking to replace enums with their values in the strings that get exported to the event format files. It's run at boot up on all events and again when a module loads. The issue is that when a module loads, it still runs on *all* events. There's no reason to process every event when a module loads as the previous events have already been processed. Only execute on the events that are loaded with the module. Link: https://patch.msgid.link/20260813204226.29563591@gandalf.local.home Fixes: 3673b8e4ce723 ("tracing: Allow for modules to convert their enums to values") Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 2d92c250815cba6bffd64f0125fac7afe4fa6ce0 Author: Karl Mehltretter Date: Sat Aug 8 21:04:17 2026 +0200 HID: haptic: don't write an uninitialized value to unhandled usages [ Upstream commit 3efb7f6491526f5012f9ec94769e9ed832feeef8 ] fill_effect_buf() initializes value only for the four haptic usages handled by its switch, but writes it to field->value[] for every usage. An unhandled usage can therefore receive either an uninitialized value or one left over from the previous usage. hid_output_report() then serializes that value into the effect's report buffer. Skip unhandled usages instead. This also matches switch_mode(), which only updates fields it recognizes. Found with Clang's -Wconditional-uninitialized. Fixes: 344ff3584957 ("HID: haptic: initialize haptic device") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7d9b5e86775fa97a487da08b9aa76e1674bf8868 Author: Aleksandr Nogikh Date: Fri Aug 14 12:05:43 2026 +0000 ALSA: core: Fix use-after-free in snd_card_do_free() [ Upstream commit 5ae1a690c522fea2900ff56c8c2ace7b059f5e04 ] A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+7061d72c26b7daebe2b4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7061d72c26b7daebe2b4 Link: https://syzkaller.appspot.com/ai_job?id=24752a23-f0b6-49c1-bf20-4fa89c2e7eb2 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/02042186-27b7-42a9-b64e-f93ce8fbe05a@mail.kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2b9a0e57bfd365e2096706b19ae34dce3b4a884b Author: Zhan Xusheng Date: Wed Jun 24 11:44:30 2026 +0800 fs/ntfs3: reject out-of-range evcn in mi_enum_attr() [ Upstream commit 20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3 ] In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: if (svcn > evcn + 1) goto out; When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the "evcn + 1" wraparound. svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1" implies svcn <= nbits. Fixes: 013ff63b6494 ("fs/ntfs3: Add more attributes checks in mi_enum_attr()") Signed-off-by: Zhan Xusheng [almaz.alexandrovich@paragon-software.com: fixed evcn check] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 169383d8914b8fe03464a83540b5b6de3e7831af Author: Zhan Xusheng Date: Wed Jun 24 11:41:33 2026 +0800 fs/ntfs3: fix integer overflow in MFT cluster validation [ Upstream commit c510c63873103a5da6a498fe537bdb5d6f8d03a2 ] In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in sbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Zhan Xusheng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit fa4168538494c101b9da388d49e1fa688a630773 Author: Puranjay Mohan Date: Thu Aug 13 12:03:48 2026 -0700 bpf, arm64: Fix stack-passed arguments for indirect trampolines [ Upstream commit 50de1c47a41d4031f6002969e71dc6954dedb6b2 ] save_args() reads stack-passed arguments relative to FP assuming the trampoline is entered through the fentry call from a traced function, in which case both the parent frame (FP/x9) and the traced function frame (FP/LR) are saved before FP is set, so the arguments start at FP + 32. An indirect trampoline for a struct_ops callback is entered through a function pointer (blr), so only the FP/LR frame is pushed and the arguments start at FP + 16, not FP + 32. Every stack-passed argument of a struct_ops callback with more than eight argument slots is read two slots off. This went unnoticed because no struct_ops member passed arguments on the stack until bpf_testmod_ops3::test_arena_stack, added by commit 2d4de9a493a0 ("selftests/bpf: Test stack-passed struct_ops arena arguments"). That member covers this on arm64 once the JIT gains arena argument support later in this series. Pass is_struct_ops into save_args() and pick the offset accordingly, mirroring the x86 fix. Fixes: 9014cf56f13d ("bpf, arm64: Support up to 12 function arguments") Signed-off-by: Puranjay Mohan Reviewed-by: Xu Kuohai Link: https://lore.kernel.org/bpf/20260813190356.335181-2-puranjay@kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 9b65b0253ad5a66f73efee9a79a21a1e2b57cf59 Author: Jijie Shao Date: Fri Aug 7 19:48:30 2026 +0800 net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg race [ Upstream commit 24ef02f934eeb48830cff6b739abc3c62b1d107b ] This bug was discovered while testing the hns3 driver under channel reconfiguration (`ethtool -L` / `ethtool -G`) with iperf3 traffic on arm64. The race is intermittently triggered when page_pool_destroy() runs page_pool_scrub() concurrently with page return via page_pool_put_netmem() on a different CPU. A WARN in page_pool_clear_pp_info() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation. page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no page ref held. __page_pool_release_netmem_dma() currently reads and writes netmem fields (dma_addr, DMA index bits in pp_magic) after xa_cmpxchg() returns. The unref path calls put_page() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free. Fix this by splitting the DMA release into two functions: 1. __page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dma_unmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref. 2. __page_pool_release_netmem_dma() wraps the above and additionally clears dma_addr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (page_pool_return_netmem). The scrub path calls __page_pool_unmap_netmem_dma() directly; the return path calls __page_pool_release_netmem_dma(). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Suggested-by: Mina Almasry Reviewed-by: Mina Almasry Signed-off-by: Jijie Shao Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260807114830.344336-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c52f3c102687b48186f3c8f422a941a52609f44b Author: Bart Van Assche Date: Fri Aug 7 15:49:46 2026 -0700 scsi: ufs: core: Set task state before io_schedule_timeout() [ Upstream commit 720d8b2f2457f4962ca353dd90395e2660d9a10d ] Set the task state to TASK_UNINTERRUPTIBLE before calling io_schedule_timeout() in ufshcd_wait_for_pending_cmds(). Without setting the task state, io_schedule_timeout() returns immediately because the task state remains TASK_RUNNING. This results in a busy loop that wastes CPU cycles. Fixes: 2000bc309703 ("scsi: ufs: core: Reduce the clock scaling latency") Reviewed-by: Peter Wang Reported-by: Sashiko Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/8fe4526ce272811b28e99048b42358dd8f7c48af.1786142946.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit e2cd23443d3616ea0876f27762b17e2ec67d896c 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 319324b5fbb292f09f3ac439434cf49e1310c068 Author: Eduard Zingerman Date: Tue Aug 11 23:05:42 2026 -0700 selftests/bpf: Fix for veristat file/prog filters processing [ Upstream commit 98d309ec8189fd91698d1a72946c3d888270c57e ] At the moment veristat filtering behaves unexpectedly for the following filter expression: -f !file/prog The expression rejects all programs with name 'prog', and all programs in a file with name 'file'. This commit fixes the expression to exclude only a program 'prog' from a file 'file'. Additionally, the commit makes empty filters like '-f ""' or '-f "/"' and error. Here is the filtering behaviour compared old versus new: | filter | file | prog | old verdict | new verdict | |----------+------+------+-------------+-------------| | !foo | foo | bar | skipped | skipped | | !foo | bar | foo | skipped | skipped | | !foo | bar | bar | processed | processed | | !foo/bar | foo | bar | skipped | skipped | | !foo/bar | foo | buz | skipped | processed | (!) | !foo/bar | bar | bar | skipped | processed | (!) | !foo/ | foo | bar | skipped | skipped | | !foo/ | bar | bar | processed | processed | | !/bar | foo | bar | skipped | skipped | | !/bar | foo | foo | processed | processed | | !/ | foo | bar | processed | error | (!) | ! | foo | bar | processed | error | (!) |----------+------+------+-------------+-------------| | foo | foo | bar | processed | processed | | foo | bar | foo | processed | processed | | foo | bar | bar | skipped | skipped | | foo/bar | foo | bar | processed | processed | | foo/bar | foo | buz | skipped | skipped | | foo/bar | bar | bar | skipped | skipped | | foo/ | foo | bar | processed | processed | | foo/ | bar | bar | skipped | skipped | | /bar | foo | bar | processed | processed | | /bar | foo | foo | skipped | skipped | | / | foo | bar | processed | error | (!) | | foo | bar | skipped | error | (!) Fixes: 10b1b3f3e56a ("selftests/bpf: consolidate and improve file/prog filtering in veristat") Signed-off-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260811-veristat-filter-fix-v2-1-6c234c4cd6ef@gmail.com Signed-off-by: Sasha Levin commit e4afd90bc7bf3dd477970c6c42bdd29ad3fda7fe 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 1222f7a3183b35c0c566899fdaead5c7c4043076 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 418e0ae42fa769d354b15e62c01a00413024755b Author: ZhengYuan Huang Date: Mon Aug 3 11:00:07 2026 +0800 ocfs2: validate DIO orphan slot during inode read [ Upstream commit bb88131c9831075b8dc08cdd375743e5d44c7ca2 ] [BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error: BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer. [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it. Link: https://lore.kernel.org/20260803030007.3993199-3-gality369@gmail.com Fixes: 06ee5c75b575 ("ocfs2: add functions to add and remove inode in orphan dir") Signed-off-by: ZhengYuan Huang 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 3d7c4b7ce7b4baedfd8699fa692cd95f77d332de Author: ZhengYuan Huang Date: Mon Aug 3 11:00:06 2026 +0800 ocfs2: validate orphan slot during inode read [ Upstream commit b2d31acbd3b182755b019183fb46949ba5e39b9f ] Patch series "ocfs2: validate active orphan slots during inode read". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing. Link: https://lore.kernel.org/20260803030007.3993199-1-gality369@gmail.com Link: https://lore.kernel.org/20260803030007.3993199-2-gality369@gmail.com Fixes: b4df6ed8db0c ("[PATCH] ocfs2: fix orphan recovery deadlock") Signed-off-by: ZhengYuan Huang 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 b262056695e897341b657714d2d438b48ab9b2d8 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 97bc6e3f5f9ac3d3e3f79e22e4babe1344d2c1fc 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 404b2a460566bc0eac951547a4da1862a067a1b8 Author: Rui Qi Date: Thu Aug 13 21:28:07 2026 +0800 selftests/cgroup: Preserve CPU hotplug write errors [ Upstream commit ddabc5dbd262f3ca981e679ddae99ed7a9adb279 ] The cpuset partition root state selftest checks several CPU hotplug transitions. If writing to a CPU online file fails, the helper still runs pause afterwards and returns the status of pause instead of the failed write. This hides the real hotplug failure and can make later checks run against expectations for a transition that never happened. Move the write before the bookkeeping and return when it fails, so callers can observe the hotplug error and the test does not record a CPU as offline unless the offline operation actually succeeded. Also change the O* command handler in set_ctrl_state() to use "eval $COMM $REDIRECT" like all other handlers. The previous version set COMM but still called write_cpu_online directly, bypassing the redirect that captures stderr for error reporting. Changes since v1: - Use eval $COMM $REDIRECT in the O* handler instead of calling write_cpu_online directly (Waiman Long) Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test") Signed-off-by: Rui Qi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2c23fc91789dfd9db746edb3ae9b90d65fabd410 Author: Maurizio Lombardi Date: Thu Aug 13 15:18:50 2026 +0200 nvmet: fix max_qid race between configfs and controller allocation [ Upstream commit f1a8846e06388113dfdbb89dee005083fa9afdf9 ] The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions. Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs") Reported-by: syzbot+2626e846cd2585c9aa67@syzkaller.appspotmail.com Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 282a3ef9e4b63b2f6823bbbb3c1a90b002cdaf12 Author: John Keeping Date: Thu Aug 13 16:08:08 2026 +0100 ALSA: seq: midi: Serialize input teardown with event_input [ Upstream commit 403f7f3ad3808a0096d84cf228fab68dc253fd9d ] snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): snd_rawmidi_input_trigger(up=0) snd_midi_input_event() -> snd_rawmidi_kernel_read() -> snd_rawmidi_input_trigger(up=1) -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) snd_rawmidi_input_event_work+0x1c/0x2c process_one_work+0x150/0x3a4 worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with event_input") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: John Keeping Link: https://patch.msgid.link/20260813150810.795393-1-jkeeping@inmusicbrands.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 67461b9113e74be0d2968d35921c6dedff7ee4e3 Author: Takashi Iwai Date: Thu Aug 13 16:42:16 2026 +0200 ALSA: seq: midi: Optimize event_input locking with RCU [ Upstream commit 4cc25cdd3cffa475edb8dec8199b3227038ebcfb ] The recent fix for serializing the output teardown introduced a spinlock invocation at every MIDI output event via event_process_midi. Since this is a hot path, let's do performance optimization with RCU. The new output_substream __rcu pointer is published via rcu_assign_pointer() in midisynth_use() after output_rfile is set, and cleared in midisynth_unuse() before the resource teardown. event_process_midi() reads it under rcu_read_lock() and bumps output_use_lock inside that section, which is necessary to close the window between the pointer dereference and the refcount increment. midisynth_unuse() calls synchronize_rcu() before snd_use_lock_sync(): this guarantees that any reader who obtained a non-NULL pointer has already called atomic_inc (output_use_lock), so the subsequent snd_use_lock_sync() sees the correct in-flight count. Fixes: ef7607ab1c8a ("ALSA: seq: midi: Serialize output teardown with event_input") Link: https://patch.msgid.link/20260813144224.753399-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 63730818d3618ab253ebdbe775397e66fb9e578c 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 7eb5764d25c4ac7f5d126621660f7219b61fd2fd Author: Marek Szyprowski Date: Mon Jul 13 10:56:53 2026 +0200 clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type [ Upstream commit 3b212f9d70805d91febae01d618868f4860e267c ] Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT. Fixes: 7aac482e6290 ("clocksource: samsung_pwm_timer: Make PWM spinlock global") Fixes: f11899894c0a ("clocksource: add samsung pwm timer driver") Signed-off-by: Marek Szyprowski Signed-off-by: Daniel Lezcano Reviewed-by: Krzysztof Kozlowski Reviewed-by: Sebastian Andrzej Siewior Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20260713085653.1145015-1-m.szyprowski@samsung.com Signed-off-by: Sasha Levin commit e4764fa09a2e34a0e57b60b0b5e5fd3f75e66e74 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 54e1259b75d6402a1d0cfb822b9bb2c507e53dab Author: Peter Oberparleiter Date: Wed Aug 12 09:53:19 2026 +0200 s390/debug: Fix deadlock during unregister [ Upstream commit 445c31ac638fd1af203d79bdf25fc0cb3149fbbc ] Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked. Fixes: 9372a82892c2 ("s390/debug: fix debug area life cycle") Signed-off-by: Peter Oberparleiter Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit e9ba3132a9edc3e23afde697ead3613b9586c906 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 811fdac2d1bdf0b0d3fda262aac288ddd13a1422 Author: Waiman Long Date: Wed Jul 1 15:58:10 2026 -0400 sched/isolation: Defer freeing of cpumask memblock memory to initcall [ Upstream commit 2b58c749b8c5244e259a0230bc57b10b010dc545 ] When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock: warn when freeing reserved memory before memory map is initialized"), the following warning was hit when there was a "nohz_full" kernel boot parameter. Cannot free reserved memory because of deferred initialization of the memory map WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0 : Call Trace: memblock_phys_free+0xcb/0x100 housekeeping_init+0x14c/0x170 start_kernel+0x207/0x450 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xda/0xe0 common_startup_64+0x13e/0x141 IOW, we shouldn't free memblock allocated memory so early in the boot process when memory map isn't fully initialized in deferred_init_memmap(). Fix it by saving the housekeeping cpumask memblock memory to be freed into a llist free list in housekeeping_init() and add a new housekeeping_late_init() helper to defer the actual freeing of memblock memory to when initcall's are being processed. The cpumask memblock memory is treated as a llist_node with the size of a "long" type which is also smallest cpumask size that can be allocated. The non-atomic version of the llist APIs are used as there is no contention. This commit depends on the presence of commit 7c2eee9c1367 ("memblock: don't touch memblock arrays when memblock_free() is called late") to prevent a KASAN UAF bug report [1]. [1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/ Fixes: 27c3a5967f05 ("sched/isolation: Convert housekeeping cpumasks to rcu pointers") Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker Reviewed-by: Phil Auld Link: https://patch.msgid.link/20260701195810.477326-1-longman@redhat.com Signed-off-by: Sasha Levin commit b33197aef23494a14838b4334d276ed6b51c68f8 Author: Ricardo B. Marlière (SUSE) Date: Mon Aug 10 17:56:00 2026 -0300 selftests/namespaces: Fix racy pipe handshake in timens and pidns_separate [ Upstream commit dcacab904fe78d60840ba947a104993ee9ded887 ] In timens_separate and pidns_separate both the child and the grandchild write a 'Y' readiness byte to the same pipe, but the parent expects a single 'Y' followed by the grandchild's pid. If the grandchild's byte arrives first, the parent takes it for the child's and reads the pid misaligned, ending up with a garbage value. The parent stores that pid in self->grandchild_pid so that FIXTURE_TEARDOWN() can kill the grandchild. A garbage pid leaves the real grandchild alive in pause(), holding the test runner's TAP pipe open and hanging the whole collection. The grandchild has nothing to report, so drop its write() and leave the child as the sole writer. Fixes: fdb48976b637 ("selftests/namespaces: Kill grandchild in nsid fixture teardown") Signed-off-by: Ricardo B. Marlière (SUSE) Link: https://patch.msgid.link/20260810-selftests-namespaces_race-v1-1-4307e833783e@marliere.net Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 65c3939656fd7848e9274faa07c26748b5bf049c Author: Hui Zhu Date: Tue Aug 11 10:46:19 2026 +0800 bpf: Fix UAF in bpf_trampoline_multi_attach_free on update failure [ Upstream commit 0253073fb7d79a2dd2eae9581ea16db2aef395a6 ] When bpf_trampoline_update() fails before modify_fentry_multi()/ unregister_fentry_multi() is called, cur_image is unchanged (cur_image == old_image) and ftrace still calls into it. Freeing old_image in that case causes a UAF. Only free old_image when it differs from cur_image. Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions") Signed-off-by: Hui Zhu Acked-by: Leon Hwang Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/aaa3829e11e2e26bcd3bda9ee6df7a0101a718ac.1786412280.git.zhuhui@kylinos.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 7edb0248f4ff515d2f7d16fd426f97519f7feb2d Author: Willem de Bruijn Date: Tue Aug 11 14:26:50 2026 -0400 selftests: drv-net: so_txtime: fix qdisc replace with handle [ Upstream commit dbf34acdfb29781dd4a8a86f7111d99c016fc7e8 ] The blamed commit updated a tc replace command by adding a handle. - tc(f"qdisc replace dev {ifname} root {qdisc} {optargs}") + tc(f"qdisc replace dev {ifname} root handle 1: {qdisc} {optargs}") This breaks the test if the root qdisc already has that handle and is of different kind, with "Invalid qdisc name: must match existing qdisc." If no handle is asked, or the kind differs, tc replace removes the old qdisc and grafts a new one. If a handle is asked and exists, tc replace tries to change the qdisc in place, for which the kind must be the same. It does not trigger in all setups, like netdevsim or debian 13, which do not have root handle 1:. But it is a common root handle. Solve the bug by first deleting the existing root qdisc if one exists. Wrap that command in a try block, because it will fail for default qdiscs with handle 0: with "Error: Cannot delete qdisc with handle of zero." Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20260810183118.32d5c06a@kernel.org/ Fixes: ef3d6cca02c8 ("selftests: drv-net: so_txtime: only send test traffic to sch_etf") Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260811182856.2702163-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6dd217e218d47b16e020a0827b4e5643dd71bbd8 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 17d2a9ef48d099d3f7affac4575a775106c08323 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 fd7aa80ecf69a4b9584f2714ed0dfdbc1bd4b555 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 4492288889b97a9272aa49ba9f9b0aba35362f55 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 c18d09a1012bb5478d6ba732bd19e4b1ec316bce Author: Matti Vaittinen Date: Mon Aug 10 13:09:45 2026 +0300 power: supply: bd71828: Do not hide errors [ Upstream commit a3c841e420e124783a805919ab072551543e477b ] The bd71828 reports success / continues operation even when some regmap operations fail. This can lead incorrect data to be reported. Return appropriate errors when operations fail. Signed-off-by: Matti Vaittinen Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi Link: https://patch.msgid.link/22db56cf35252d2d8f67828a0554e8daac7ae251.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 513cdd61debddf4621761e2755bde77fafa4e0ce Author: Matti Vaittinen Date: Mon Aug 10 13:09:25 2026 +0300 power: supply: bd71828: Drop duplicate power-supply property [ Upstream commit 6605209ceb53eaa25582d1f4726217bd09eff392 ] The POWER_SUPPLY_PROP_HEALTH is added into property-array twice. Drop the duplicate property. Signed-off-by: Matti Vaittinen Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi Link: https://patch.msgid.link/518283ec9163943fcd1b53ad61fc3025fd346d83.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 80091fbba3e925679102a76ecb0048d4150eef6b Author: Matti Vaittinen Date: Mon Aug 10 13:09:07 2026 +0300 power: supply: bd71828: Fix current direction [ Upstream commit d012fab12fed2053e0dca4c8cd4e2b2053afabfb ] Both the current and the average current registers contain same 'direction' -bit to denote the direction of the current. The code reading these registers incorrectly caches the direction read from the first register, and uses it also for the second. Fix this by initializing the direction bit for both register reads. Signed-off-by: Matti Vaittinen Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Andreas Kemnade # Kobo Clara 2e rev B Tested-by: Kalle Niemi Link: https://patch.msgid.link/22c6816204b3f2a8b50df8171e384937822d195b.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 367b8a8860e755daefc091126a8a2968c8dce2d4 Author: Matti Vaittinen Date: Mon Aug 10 13:08:50 2026 +0300 power: supply: bd71815: Fix temperature reading [ Upstream commit c15f0eabec5a051cb8190fa2bff3b211730f4acb ] The temperature read from the hardware is never returned to caller. Furthermore, the check for temperature validity is wrong. This yields garbage value to be returned to caller, and also detection of bad values read from hardware to fail. Signed-off-by: Matti Vaittinen Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi Link: https://patch.msgid.link/4ae3dfa7fc80372977fd29c837321f96d551bf6f.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 101cd6f72922989f58e297861a87b14a2a5a3785 Author: Josh Poimboeuf Date: Sat Aug 8 16:17:05 2026 -0700 objtool/klp: Fix .kcfi_traps special section extraction [ Upstream commit 7df1638df97b2aaaff4731b72d4940053257c952 ] create_fake_symbols() creates a symbol per entry for special sections. It does so in two steps: first for the sections which have ANNOTATE_DATA_SPECIAL annotations, then for the rest, using entsize or the reloc count to infer the entry size. The second step skips the sections already handled by the first one by looking for a symbol at offset 0. That heuristic is too fuzzy: with Clang and CONFIG_CFI, it misfires on .kcfi_traps because Clang emits a .Ltmp* assembler-local label at the start of the section, so no symbols are created and clone_special_sections() extracts nothing. klp-build still reports SUCCESS, but the livepatch module has no __kcfi_traps section and the traps for the patched functions are lost. Look for the actual fake symbols created by the first step instead. Fixes: da4326573ae8d ("objtool/klp: Fix kCFI trap handling") Reported-by: Joe Lawrence Closes: https://lore.kernel.org/r/akQNqlfFC0T5pcMa@redhat.com Acked-by: Song Liu Link: https://patch.msgid.link/8faaead205b219607b6fc2359ae743be824056eb.1786230311.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 4e8a940c31539ae0f8386638752c06e522b18673 Author: Puranjay Mohan Date: Fri Aug 7 11:16:29 2026 -0700 objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbols [ Upstream commit 6656cf1e975aa152c082012b820efffaebd49979 ] Building a kernel via klp-build fails to link: `__exitcall_aes_mod_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_dax_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_hid_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_usb_serial_module_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o module_exit() on a built-in emits a static __exitcall_$fn pointer into .exitcall.exit, which vmlinux.lds.h discards unconditionally via EXIT_CALL. When two built-in translation units define a module_exit() function of the same name, the resulting local symbols collide, symid_needed() sees a duplicate and emits a .klp.symid entry for each, referencing symbols the linker then throws away. Same-named module_exit() functions are not rare: dax_exit drivers/dax/device.c, drivers/dax/fsdev.c hid_exit drivers/hid/hid-core.c, drivers/hid/usbhid/hid-core.c aes_mod_exit arch/arm64/crypto/aes-ce-ccm-glue.c, lib/crypto/aes.c usb_serial_module_exit module_usb_serial_driver() expands to this fixed name in each of its ~49 users The last one makes the collision structural rather than accidental: any kernel with two built-in USB serial drivers has it. This is not arch specific either; it only requires the objects to be built in rather than modular, which is why a monolithic config trips it while a typical distro config does not. Add .exitcall.exit to the discarded section list so its symbols don't get symids. This is the same failure mode as "objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols", for another unconditionally discarded allocated section. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Signed-off-by: Puranjay Mohan Link: https://patch.msgid.link/m24igzlbxf.fsf@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 01923107661a443ad8c687681c4afb1dd678fca9 Author: Krishna Chaitanya Chundru Date: Tue Aug 11 21:19:41 2026 -0500 PCI/ASPM: Disable/restore ASPM on every function for multi-function devices [ Upstream commit 733cd811b3ac50586164a0864c4351fe23e21890 ] pcie_aspm_cap_init() disables ASPM L0s/L1 before touching L1SS config, then restores the pre-existing state afterward. Both steps only ever touched link->downstream, i.e. function 0 of the downstream component, leaving sibling functions (>0) on a multi-function device untouched. This means the "disable" step does not actually disable ASPM link-wide on a multi-function device: a sibling function can still have L1 enabled even after this step runs. PCIe r7.0, sec 7.5.3.7, recommends programming the same ASPM Control value for all functions of a multi-function device, and pcie_config_aspm_link() already loops over every function on the bus for exactly this reason. Loop over every function on linkbus->devices for both the disable and restore steps, keeping the existing sec 7.5.3.7 ordering (disable downstream functions before upstream, restore upstream before downstream functions). The masked pcie_capability_clear_and_set_word() accessor from the previous commit makes this safe: it only ever touches the ASPM Control bits, so function-specific bits elsewhere in LNKCTL (e.g. Read Completion Boundary, CLKREQ Enable) on sibling functions are left untouched. Fixes: 7447990137bf ("PCI/ASPM: Disable L1 before disabling L1 PM Substates") Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/ Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260727-aspm-v6-2-2ebb3ee7ef71@oss.qualcomm.com Signed-off-by: Sasha Levin commit bcbcbd0370e670587b58922e9326f9e437c1b63b 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 6b6007e96d62aa16d6e46fb849bfb60ef7f07213 Author: bui duc phuc Date: Wed Aug 5 13:43:48 2026 +0700 ASoC: spacemit: advertise only DMA-backed DAI streams [ Upstream commit 0a91bb72980e4aa5f0c1be33d691e7767d7db9ed ] The static DAI template initializes both playback and capture stream capabilities before dma-names is examined. As a result, snd_soc_dai_stream_valid() considers both directions valid even when the device only provides a single DMA channel. Move the playback and capture capability initialization into spacemit_i2s_init_dai(), where it is performed only for the stream directions backed by a corresponding DMA channel. This preserves the existing capabilities for devices with both "tx" and "rx" DMA channels, while preventing unsupported stream directions from being advertised. Initialize rate_min and rate_max together with the other stream capabilities to preserve the existing rate constraints. Fixes: fce217449075 ("ASoC: spacemit: add i2s support for K1 SoC") Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260805064348.44283-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a2129953aea8ce915eb60c4ed86c1d73c4e1116 Author: Vineet Gupta Date: Fri Aug 7 13:44:34 2026 -0700 selftests/bpf: vmtest.sh: Preserve command quoting when running in the VM [ Upstream commit 3a59f11e0f989bdd637c87151992605a6559a7cb ] vmtest.sh captures the trailing command with command="$@", which flattens the arguments into a single space-separated string, and then pastes it into the generated guest init script: cd /root/bpf echo ${command} stdbuf -oL -eL ${command} That here-doc is unquoted, so the host expands ${command} and the flattened text lands in the script verbatim. The guest bash then parses those lines as shell source, re-splitting the text on whitespace and glob-expanding it against /root/bpf. As a result any command with a glob or an argument containing spaces is corrupted before it reaches the test binary. For example: vmtest.sh -- ./test_progs -a 'verifier_*' has 'verifier_*' expanded in the guest into the matching object/skeleton files (verifier_align.bpf.o verifier_align.skel.h ...), so test_progs is handed a list of filenames instead of the intended name filter and runs no matching tests. Quote each argument with printf '%q ' so the command is reproduced verbatim inside the VM: the escaped text goes through exactly one round of quote removal when the guest parses the init script, yielding the original argv with globs and special characters intact. The common case (e.g. -t ) is unaffected. Only do this when there is a command to quote. printf '%q ' with no arguments still applies the format once and emits '', which the -s (debug shell) path would take for a real command and try to run. Note this makes the trailing command strictly an argv rather than a shell snippet: passing it pre-quoted as one word, e.g. vmtest.sh -- "./test_progs -t foo" no longer works, and neither does embedding guest-side shell syntax such as ';' or a redirection. 'sh -c ...' still works. The RV64 recipe in README.rst does depend on the old double parse: it wraps the denylist in \" so the literal quotes reach the guest, whose second parse of the init script removes them. Under %q those quotes now survive into argv, and parse_test_list() strtok_r()s on ',' turns them into junk filters: -d ",exceptions," -> ["] [exceptions] ["] That is harmless for DENYLIST.riscv64 only because its first line is a comment, so the leading field is empty. A denylist starting with a real entry would silently lose it - ["*arena*] never matches - so drop the backslashes and let the host consume the quotes instead. Fixes: c9709f52386d ("bpf: Helper script for running BPF presubmit tests") Signed-off-by: Vineet Gupta Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260807204434.1036279-5-vineet.gupta@linux.dev Signed-off-by: Sasha Levin commit 817ad6d29cbc8ffc16139f1e43891fc12e0dbd08 Author: David Matlack Date: Mon Jul 6 18:31:54 2026 +0000 selftests: harness: Mark test fixture objects __maybe_unused [ Upstream commit 37ffa24c9d07edcd414d34283e02af3f3866cf12 ] Mark _##fixture_name##_##test_name##_object __maybe_unused since it may not ever be read. This pointer is only read in XFAIL_ADD(), which tests are not required to use. clang made a change to -Wunused-but-set-variable (split out into its own subwarning, -Wunused-but-set-global) that causes this warning to be emitted for various selftests and can be upgraded to an error in selftest that set -Werror. VFIO selftests have been broken since commit ff556bd98348 ("vfio: selftests: Add -Wall and -Werror to the Makefile"), and the net selftests builds have been noisy due to -Wall. Fixes: 24cf65a62266 ("selftests/harness: Share _metadata between forked processes") Reported-by: Kuniyuki Iwashima Reported-by: Aaron Lewis Reviewed-by: Alex Williamson Reviewed-by: Kuniyuki Iwashima Signed-off-by: David Matlack Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20260706183154.2660394-1-dmatlack@google.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 44b702fceb4cf3a4ddbfb496f487b034814bf1a3 Author: Daniel Borkmann Date: Tue Aug 11 15:15:59 2026 +0200 bpf, s390: Clear fetch destination on faulting arena atomic [ Upstream commit cc3e12330599f097f0e1f792435686ddc276f26d ] Same missing register clear as on riscv64. A RMW atomic on an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but bpf_jit_probe_atomic_pre() only fills in the arena base and the probe offset, leaving probe->reg at the -1 that bpf_jit_probe_init() set, which bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads back as "there is nothing to clear". That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory, but an RMW carrying BPF_FETCH also reads the old value into a register: src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for BPF_CMPXCHG. So on a fault over an unmapped arena page the program resumes at the landing pad with whatever that register held before the atomic instead of the 0 that every other BPF_PROBE_* access delivers. Fill probe->reg in from bpf_atomic_load_reg(). Unlike x86-64 and arm64, s390x does not report arena violations from its exception handler, so there is no access direction to correct here, only the missing register clear. Fixes: 2f9469484a3b ("s390/bpf: Support arena atomics") Signed-off-by: Daniel Borkmann Reviewed-by: Ilya Leoshkevich Link: https://patch.msgid.link/20260811131600.506721-5-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 84fac27c0ca3e9494bc59c7b8cce7001d748b59f Author: Daniel Borkmann Date: Tue Aug 11 15:15:58 2026 +0200 bpf, arm64: Clear fetch destination on faulting arena atomic [ Upstream commit ea3f20cb5918fea8e3786899b78fc7bb867c6a5e ] Same problem as on x86-64: add_exception_handler() folds "there is no destination register to clear" and "this is a store" into one DONT_CLEAR value ... if (BPF_CLASS(insn->code) != BPF_LDX && !bpf_atomic_is_load_acq(insn)) dst_reg = DONT_CLEAR; ... which ex_handler_bpf() then reads back as the access direction: bool is_write = (dst_reg == DONT_CLEAR); A RMW carrying BPF_FETCH is both. emit_lse_atomic() reads the old value into src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and into r0 for BPF_CMPXCHG, so a fault over an unmapped arena page is correctly reported as a WRITE but leaves that register holding a stale value instead of the 0 that every other BPF_PROBE_* access delivers. Same as on x86-64, add a separate ARENA_WRITE bit for the direction. FIXUP_REG is now filled in by the callers of add_exception_handler(), the BPF_PROBE_ATOMIC one deriving it from bpf_atomic_load_reg(), so that the helper only has to determine the direction. This is how the riscv64 JIT already does it, and it stops the two store callers from handing in a dst_reg that was only going to be overwritten with DONT_CLEAR anyway. Fixes: e612b5c1d3ee ("bpf, arm64: Add support for lse atomics in bpf_arena") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://patch.msgid.link/20260811131600.506721-4-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 5eb3ff6a3bf27f43b83917af8347e41cefd446ca Author: Daniel Borkmann Date: Tue Aug 11 15:15:57 2026 +0200 bpf, x86: Clear fetch destination on faulting arena atomic [ Upstream commit cf92a108601a3f2465b550e44a98c8a78cabf8d1 ] populate_extable() encodes "there is no destination register to clear" as DONT_CLEAR in the DST_REG field of the exception table metadata, and later ex_handler_bpf() then reuses that very value to derive the direction it reports the fault with is_write = (reg == DONT_CLEAR). The two coincide for a plain load or store, but not for a RMW carrying BPF_FETCH. Such an atomic writes memory, so it has to be reported as a WRITE, and it also reads the old value into a register, src_reg for BPF_ADD | BPF_FETCH and BPF_XCHG, r0 for BPF_CMPXCHG, so that register has to be cleared on fault. A single DONT_CLEAR cannot say both, and the store branch picks it unconditionally: [...] } else { arena_reg = reg2pt_regs[dst_reg]; fixup_reg = DONT_CLEAR; } [...] The reported direction is therefore right, but on a fault over an unmapped arena page the fetch destination keeps whatever it held before the atomic, where every other BPF_PROBE_* access delivers 0. Give the metadata its own ARENA_WRITE bit so that the reported direction no longer depends on whether there is a register to clear, and fill DST_REG in from bpf_atomic_load_reg(). BPF_{AND,OR,XOR} | BPF_FETCH need no handling here, bpf_jit_supports_insn() already rejects those in the arena. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260811131600.506721-3-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 6465c2c0f1e34d932b79291c29abe9faa586a1a9 Author: Daniel Borkmann Date: Tue Aug 11 15:15:55 2026 +0200 bpf: Derive the atomic load register in one place [ Upstream commit 41c5dbb4be3c1ef4a5e2ce4c28de60b2be3cdccf ] check_atomic_rmw() open codes the mapping from a BPF_ATOMIC to the register it reads the old value into, the BPF_STX case of insn_def_regno() open codes the very same mapping a second time, the const folding and the liveness transfer functions a third and a fourth time, and BPF JITs need it as well to know which register a faulting BPF_PROBE_ATOMIC has to clear. Add a small helper so that all of them can share it. No functional change. The BPF_LOAD_ACQ case is there for the JITs, which do walk all instruction classes. const_reg_xfer() loses its explicit BPF_ATOMIC mode test since the helper checks class and mode itself; the BPF_PROBE_ATOMIC it additionally accepts cannot be seen there as it is only set from bpf_do_misc_fixups(), that is, after const folding has run. arg_track_xfer() keeps its mode test since that also guards the stack clearing next to it. Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260811131600.506721-1-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Stable-dep-of: cf92a108601a ("bpf, x86: Clear fetch destination on faulting arena atomic") Signed-off-by: Sasha Levin commit 840f7275081523f28f5c601e0942e1f447427e50 Author: Daniel Borkmann Date: Tue Aug 11 15:15:56 2026 +0200 bpf, riscv: Clear fetch destination on faulting arena atomic [ Upstream commit 1519f488e8ce430c68ade11d24b8459631f5dca9 ] A RMW atomic on an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but that entry records no destination register to clear unless the instruction is a load-acquire today. That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory, but an RMW carrying BPF_FETCH also reads the old value into a register: src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for BPF_CMPXCHG. emit_atomic_rmw() emits it that way, e.g.: [...] case BPF_XCHG: ctx->ex_insn_off = ctx->ninsns; emit(is64 ? rv_amoswap_d(rs, rs, rd, 1, 1) : rv_amoswap_w(rs, rs, rd, 1, 1), ctx); [...] Thus, a fault over an unmapped arena page ex_handler_bpf() jumps over the access but leaves rs untouched, and the program resumes with whatever it held before the atomic instead of the 0 that every other BPF_PROBE_* access delivers. Fill the exception table entry in from bpf_atomic_load_reg(), which returns the BPF register an atomic reads the memory operand into or -1 when it has none. A load-acquire ends up with the same register it gets today, it just goes through the helper. Unlike x86-64 and arm64, riscv64 does not report arena violations from its exception handler, so there is no access direction to correct here, only the missing register clear. Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64") Signed-off-by: Daniel Borkmann Reviewed-by: Pu Lehui Link: https://patch.msgid.link/20260811131600.506721-2-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 82b97be6a478ee54e5994379b298f536937b751e Author: Mohammad Abu-Khader Date: Mon Aug 3 19:02:17 2026 +0000 kunit: tool: fix _list_tests filtering wrong variable when list has TAP prefix [ Upstream commit dea754ded9518b51740c417d2c1e02ff540784c6 ] `_list_tests()` runs the kernel to list tests, strips printk timestamp lines via `extract_tap_lines()`, then drops the dummy TAP header from the cleaned `lines`. However the subsequent regex filter mistakenly operates on the original `output` instead of the cleaned `lines`. When the kernel output includes timestamp prefixes (common with UML or slower setups), e.g.: [ 0.100000] suite.test1 [ 0.100000] suite.test2 the anchored regex `^[^\s.]+\.[^\s.]+$` rejects them and `--list_tests` returns an empty list. Filter `lines` instead of `output`, matching the behavior of the adjacent `_list_tests_attr()` which already returns the cleaned list. Add a regression test with timestamp-prefixed input to verify the fix. Link: https://lore.kernel.org/r/20260803190059.36491-1-mohammad.abukhader@hotmail.com Fixes: 723c8258c8fe ("kunit: tool: Add command line interface to filter and report attributes") Signed-off-by: Mohammad Abu-Khader Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 7e2ee531560e0391997f168f74ff3af4b19599be Author: Dan Carpenter Date: Sat Aug 8 22:41:28 2026 +0300 drm/amd/pm: silence uninitialized variable warnings [ Upstream commit b4cb43789b6ac0f25fc0d9b21c5e7a6225cf6a31 ] Smatch complains that: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu15/smu_v15_0_8_ppt.c:1964 smu_v15_0_8_set_performance_level() error: uninitialized symbol 'ret'. In this line there is an "if (ret)" condition where "ret" is either zero or uninitialized. Initialize "ret" at the start of the function to avoid a potential uninitialized variable bug. But also delete the condition since it is never true. Fixes: 422b399b09c7 ("drm/amd/pm: Add od_edit_dpm_table support") Reviewed-by: Lijo Lazar Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e87e015f44f15eaf2ad1dcc612a7c66180646256 Author: Arnaldo Carvalho de Melo Date: Tue Aug 11 15:28:59 2026 -0300 perf build: Remove leftover feature tests for removed cxx and clang support [ Upstream commit b60f6bc128b972e018de6bcfa7007b4021f4a31a ] 56b11a2126bf2f42 ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)") removed the test-cxx.cpp and test-clang.cpp sources, but left behind their entries in the feature test FILES list, the build rules and the cxx and clang entries in FEATURE_TESTS_EXTRA. Since the sources no longer exist, those rules would always fail, making the artificial feature-cxx and feature-clang results to be perpetually disabled/absent, remove the leftover entries, making the feature test scripts list match the available sources. Fixes: 56b11a2126bf2f42 ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)") Cc: Ian Rogers Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 20ed93f1fd576a4a3d4031328fc384dc89fb7bdb Author: Julian Braha Date: Sun Jul 19 03:49:02 2026 +0100 backlight: ktd2801: Fix unmet dependency on GPIOLIB [ Upstream commit 5859fa79c7d85d0c242a9a1ffb40bab9732d4ef1 ] LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801 also needs to ensure GPIOLIB is enabled. Otherwise: WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n] Selected by [y]: - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] This unmet dependency was found by kconfirm, a static analysis tool for Kconfig. Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB") Signed-off-by: Julian Braha Reviewed-by: Daniel Thompson (RISCstar) Acked-by: Duje Mihanović Tested-by: Randy Dunlap Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260719024902.151710-1-julianbraha@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d32a47e7cda714fc6594f255d39d0fe36d3f5373 Author: Junjie Cao Date: Tue Aug 4 11:02:54 2026 +0800 backlight: aw99706: Validate all DT property values consistently [ Upstream commit 3d142b19b09ea62d6e9a33d46d1b858b3ad05707 ] The lookup helpers for dim-mode and ramp-ctl take a shortcut when lookup_tbl is NULL: they accept any u32 value without range-checking and return success unconditionally. Out-of-range values get silently truncated by regmap_update_bits instead of triggering the dev_warn + default-fallback path that the other properties use. Add a field-width check for the NULL-table case so that values exceeding the register field maximum are rejected the same way a table-lookup miss is. The switching frequency table has a second hole: reserved slots use 0 as their marker, so "awinic,sw-freq-hz = <0>" matches slot 0 and programs a reserved encoding. Make the reserved marker U32_MAX and skip such slots during lookup. While here, also switch the error returns to -EINVAL for consistency. Fixes: 147b38a5ad06 ("backlight: aw99706: Add support for Awinic AW99706 backlight") Signed-off-by: Junjie Cao Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260804030255.1934470-3-junjie.cao@intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 43ba7cdff6dd48a3c7a8175d6e6afeb07bc5a6f6 Author: Charles Keepax Date: Wed Aug 5 13:01:09 2026 +0100 mfd: cs42l43: Fix regmap defaults ordering [ Upstream commit 9d0e4b1ae5b045a2c92b0b9a1c3b268191c219d9 ] The regmap defaults should be ordered as binary search is done on the array. A few registers were added in the wrong places, move these to be in register address order. Fixes: a6fe20d67dc7 ("mfd: cs42l43: Add support for the B variant") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260805120109.4024451-1-ckeepax@opensource.cirrus.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 829539c4a650544cb8e5e8690f2c2d0aa2c0e298 Author: Will Deacon Date: Tue Aug 11 15:04:29 2026 +0100 arm64/efi: Avoid voluntary preemption with efi_mm installed [ Upstream commit e98a9d0146372b046d863164025a66ab4488b972 ] Gus reports a bad kernel memory access when using software PAN (CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime services: Unable to handle kernel access to user memory outside uaccess routines at virtual address 00000000f322ff30 Mem abort info: ESR = 0x0000000096000004 FSC = 0x04: level 0 translation fault Internal error: Oops: 0000000096000004 [#1] SMP Workqueue: efi_rts_wq efi_call_rts pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : efi_call_rts+0xd8/0x288 Call trace: efi_call_rts+0xd8/0x288 (P) process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 This is because the fpsimd context management code called from __efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI code with an incorrect value for TTBR0_EL1 thanks to the deferred mm switching used by the software PAN implementation. Since EFI runtime services cannot preempt voluntarily and because the fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply reorder the fpsimd switch so that it occurs before we change the page-table. Cc: Ard Biesheuvel Reported-by: Gus Bourg Tested-by: Gus Bourg Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption") Link: https://lore.kernel.org/all/20260806000144.3388823-1-gus@bourg.net/ Reviewed-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit fdbdc5c016a818b970e01accdb351d100009ae71 Author: Christoph Hellwig Date: Tue Aug 4 05:43:58 2026 -0700 iomap: iomap_bio_read_folio_range_sync is missing a call to bio_uninit [ Upstream commit accb6624e383872e7703974a5d5826755fb27032 ] Which could leak blkg references. Fixes: c03cea42149d ("iomap: add initial support for writes without buffer heads") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260804124404.737145-3-hch@lst.de Reviewed-by: "Darrick J. Wong" Reviewed-by: Anuj Gupta Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 778f6a80705117eecef61743049a2a187124b5d7 Author: Karl Mehltretter Date: Sat Aug 8 14:38:02 2026 +0200 super: fix dying superblock warning messages [ Upstream commit 9ac8fd831252e52aa78399eaccc11a72f6c2af1a ] WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Fixes: f0cd988016f6 ("fs: massage locking helpers") Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260808123802.73687-1-kmehltretter@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ef34de895dfd70075ffb5363d99977453c5e4f3c Author: Krishna Chaitanya Chundru Date: Mon Jul 27 19:32:36 2026 +0530 PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM disable/restore [ Upstream commit 75a3b50ad9dc99ce9693a0086b968c6d3501db21 ] pcie_aspm_cap_init() disables ASPM L0s/L1 on both ends of the Link before touching L1SS config, then later restores the LNKCTL state that was in effect beforehand. Both steps use raw pcie_capability_write_word() calls: the disable step computes the new value by hand from a snapshot taken earlier in the function, and the restore step writes that same snapshot straight back. Switch both steps to pcie_capability_clear_and_set_word(), masked to PCI_EXP_LNKCTL_ASPMC, matching the accessor pcie_config_aspm_dev() already uses elsewhere in this file for the exact same register. This does a live read-modify-write of just the ASPM Control bits instead of relying on a stale snapshot for the rest of the word, and is consistent with how the rest of the file already touches this register. No functional change. Fixes: 7447990137bf ("PCI/ASPM: Disable L1 before disabling L1 PM Substates") Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/ Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260727-aspm-v6-1-2ebb3ee7ef71@oss.qualcomm.com Signed-off-by: Sasha Levin commit f024208da64d35fb275fc0ee8fee283fb89057c3 Author: Josh Poimboeuf Date: Fri Aug 7 14:37:53 2026 -0700 objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols [ Upstream commit 4cd3cfb8b54feca89a682720434092a87bfa4967 ] EXPORT_SYMBOL_FOR_MODULES() puts a symbol in a "module:" namespace, which the module loader grants access to by matching the importing module's name against that list. klp_reloc_needed() only creates a klp reloc for module-owned exports; a vmlinux export gets a normal reloc. For a vmlinux symbol exported with EXPORT_SYMBOL_FOR_MODULES(), using a normal reloc results in a modpost failure in klp-build: ERROR: modpost: module livepatch-foo uses symbol mpol_shared_policy_lookup from namespace module:kvm, but does not import it. And the modpost error is correct: even with that error removed, the patch module would fail to load: livepatch_foo: module uses symbol (mpol_shared_policy_lookup) from namespace module:kvm, but does not import it. livepatch_foo: Unknown symbol mpol_shared_policy_lookup (err -22) Treat it like an unexported symbol by using a klp reloc. Note this only affects "module:" namespaces. Ordinary namespaced exports continue to work with normal relocs thanks to copy_import_ns(), which propagates the patched object's import_ns tags to the patch module. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Joe Lawrence Link: https://lore.kernel.org/6a6608f4-0a05-4d75-8b7f-edddfac9c5d4@redhat.com Acked-by: Joe Lawrence Acked-by: Song Liu Link: https://patch.msgid.link/fe5a00818e06ec613344d41d5944de054fcd8832.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit d4ae0baea6d68a205950da393df103c7ca1e4656 Author: Josh Poimboeuf Date: Fri Aug 7 14:37:51 2026 -0700 objtool/klp: Don't match local symbols against exports [ Upstream commit 86a697572c6271083694025eefa8de518eeef623 ] While cloning a reloc, klp diff calls find_export() to determine whether the referenced symbol is exported. That decides whether the reference needs a klp reloc, which object the klp symbol belongs to, and whether the symbol's data needs to be copied into the patch module. But find_export() matches purely on symbol name, so a static function or variable which happens to share its name with an export is mistaken for a reference to that export: - klp_reloc_needed() creates a klp reloc pointing at the exporting module's symbol rather than the local one. For a vmlinux export it skips the klp reloc altogether, leaving a normal reloc which the module loader resolves to the vmlinux symbol. - clone_reloc() treats the symbol as external and clones it without its data, leaving a dangling reference. - validate_special_section_klp_reloc() attributes a static branch or call key to the wrong module, and for a vmlinux export skips the unsupported-key check entirely. Exports are always global, so ignore local symbols in find_export(). Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/dafc7c017d1f62e2190a20dc84a52fbfc4c70210.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit a8efbd6bd582a8d7e1e606d57b269fd560c95eb6 Author: Josh Poimboeuf Date: Fri Aug 7 14:37:50 2026 -0700 objtool/klp: Fix cross-module klp relocation section naming [ Upstream commit 07f14d6af9d7791fdc2b44a3dd0693e42c71d2b8 ] A klp relocation section is .klp.rela.., where objname is the object being patched. klp-build wrongly derives objname from where the referenced symbol lives, not where it's referenced. For a cross-module reference like patched can_isotp code calling can.ko's can_rx_unregister(), that gives .klp.rela.can..text rather than .klp.rela.can_isotp..text. Unless the patch happens to patch can.ko as well, the relocation never gets applied and the call goes off into the weeds. Name the intermediate section __klp_relocs. so post-link can read the patched object's name from there. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Joe Lawrence Link: https://lore.kernel.org/20260720145658.1103243-2-joe.lawrence@redhat.com Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/ee93a08f3e55e76ffa67d04e283917ddaa893f09.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 6a990e74d4e848f32eda91d69e4f885604fc326d Author: Takashi Sakamoto Date: Tue Aug 11 21:09:28 2026 +0900 firewire: core: fix memory leak in error path of build_tree() [ Upstream commit 05bfb1327dc5fb61528bab31cd8f0c1e4bddec23 ] In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller. Fixes: 3038e353cfaf ("firewire: Add core firewire stack.") Reported-by: Abdun Nihaal Link: https://lore.kernel.org/all/20260727095955.104972-1-nihaal@cse.iitm.ac.in/ Link: https://lore.kernel.org/r/20260811120928.700577-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 727013e31478e5873390d7270aa4cf1150931df1 Author: Takashi Sakamoto Date: Tue Aug 11 21:09:27 2026 +0900 firewire: core: validate parent port count before allocating nodes in build_tree() [ Upstream commit a563a7cb645a79a3a7e31bed8cbf95980ef5feb1 ] The node tree requires each child node to have exactly one port connected to a parent node, while the root node must have no such port. This can be validated by comparing the parent port count for a PHY with the rest of the self ID sequence. Currently, this validation is done after the node has been allocated. Move it before the allocation so that an invalid self ID sequence can cause an error without having to clean up the newly allocated node. Link: https://lore.kernel.org/r/20260811120928.700577-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 3f3980920f0210be0f75f4f544c00ed7e190fe66 Author: Takashi Sakamoto Date: Tue Aug 11 21:09:26 2026 +0900 firewire: core: consolidate port counting in build_tree() [ Upstream commit 87c48e54f28d410af0c12b5dd339307bb43abeea ] The self ID sequence describes the state of each port for each PHY. Currently, build_tree() counts the ports in two separate places. Consolidate the port counting in one place. Link: https://lore.kernel.org/r/20260811120928.700577-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 75c00ce4049c9495a99ee2ca2800940cefe2ee64 Author: Takashi Sakamoto Date: Mon Aug 10 15:41:19 2026 +0900 firewire: core: add KUnit tests for failure of tree building [ Upstream commit f744022705b7eb479a1931ddd95aae4e9a4be221 ] Abdun Nihaal has reported a memory leak when tree building fails in the middle of self ID sequence enumeration. This is caused by an invalid self ID sequence and is not a common occurrence. This commit is intended to assist in fixing the issue by adding KUnit tests to show the cases in which the memory leak is triggered. The leak occurs internally in the build_tree() function, therefore it cannot be detected directly by the tests. Link: https://lore.kernel.org/r/20260810064119.410324-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit a41a7dd31c4aba7e1254ff40a7e291bed65a37ce Author: Takashi Sakamoto Date: Mon Aug 10 15:41:18 2026 +0900 firewire: core: add KUnit tests for successful tree building [ Upstream commit 7b763ea17152cf61ede5289c3c66bf133c8aafa7 ] After a bus reset, self ID sequence is captured by 1394 OHCI hardware and passed to software through SelfID DMA context. The core parses the sequence to build an internal cache of the node tree for the current generation of the bus. This is the first step in managing resources on the bus. The tree is build by the build_tree() function. This commit adds KUnit tests for the function, covering several successful scenarios. Link: https://lore.kernel.org/r/20260810064119.410324-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 0e86ed95eda9c6792d6d1af824b91a19c7d09cfc Author: Takashi Sakamoto Date: Mon Aug 10 15:41:17 2026 +0900 firewire: core: add KUnit test skeleton for node tree [ Upstream commit 1f9b65cf57081035547b4d3ca1805df20892e9db ] Some issues have been reported in node tree management. Refactoring the topology-related code in the core is required. Adding unit tests would help ensure that the refactoring does not introduce regressions. This commit adds a KUnit test skeleton for this purpose. Link: https://lore.kernel.org/r/20260810064119.410324-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 6d9c3ae59c7f76d85fa5ae85a35f9b5cb67b866d 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 4e0ce77df7d9808926719d7950a07fbad14ea9ef 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 851c5e9a829d56cb0982965f07ef8966a6722884 Author: Yuho Choi Date: Fri Aug 7 16:45:50 2026 -0400 mtd: ubi: Release device reference on busy detach [ Upstream commit 31dd710cd84d5dd63c49f640d3a9f36c9699ca95 ] ubi_detach_mtd_dev() obtains a device reference through ubi_get_device() before checking whether the UBI device is busy. The busy return path drops ubi->ref_count but leaves the device reference held, so the device object cannot be released after a later detach. Drop the device reference before returning -EBUSY. Fixes: 7e84c961b2eb ("mtd: ubi: introduce pre-removal notification for UBI volumes") Signed-off-by: Yuho Choi Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit ec3fffb06a3f5772d56eebc4aef32f43a5db10f5 Author: Josh Poimboeuf Date: Fri Aug 7 14:37:48 2026 -0700 objtool/klp: Ignore replacement offset of empty x86 alternatives [ Upstream commit 636f230ce21e2730072c58280f1fa0bed4a00eed ] An x86 alternative with an empty replacement, e.g. the second entry of ALTERNATIVE_2("orig", "repl", ft1, "", ft2) has a replacementlen of zero. Its replacement offset still gets a relocation, but the label it points at is the end of the previous replacement, which is also the beginning of the *next* alternative's replacement. The value is meaningless; get_alt_entry() already ignores it for that reason. klp diff doesn't ignore it. When such an alternative belongs to a changed function, cloning its relocations drags in the unrelated neighboring replacement, along with everything that replacement references. On an x86 clang/lto build an empty alternative in meminfo_proc_show() pulled in the replacement of an alternative in proc_kcore_init(), silently emitting a klp relocation against init text which has long since been freed by the time the patch is applied. Add arch_alt_ignore_new_reloc() and skip such relocations when cloning. This has to be arch specific: on arm64 a zero-length replacement instead identifies an alternative callback, whose replacement offset points at the callback function and must be preserved. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/7a885b70974795c3417f3358869e62aafd4ef783.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit ab0648f06367f41e792bf523177df4f6b65c3119 Author: Josh Poimboeuf Date: Fri Aug 7 14:37:47 2026 -0700 objtool/klp: Fix size of empty special section entries [ Upstream commit 1ea786097cd79522b76cbd41beeb8f84ef3a76f4 ] create_fake_symbols() sizes each ANNOTATE_DATA_SPECIAL entry from the offset of the next annotation, falling back to the end of the section for the last entry. But the last entry is detected by a zero size, which also happens for an *empty* entry: ALTERNATIVE(oldinstr, "", ft) still annotates its zero-length replacement, at the same offset as the next entry's annotation. So every empty replacement gets a fake symbol spanning the entire rest of .altinstr_replacement. That's harmless today only because find_symbol_containing() picks the smaller of two overlapping symbols. Track whether a next annotation was found rather than inferring it from the size. A zero-length fake symbol is fine: find_symbol_containing() skips those, so the properly sized symbol at the same offset still wins. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/913e691c5009397df832c7c9a18cd5cf71b42737.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit ba20c5bb872cdf5ca7f247acd1828546e49f47dc Author: Josh Poimboeuf Date: Fri Aug 7 14:37:46 2026 -0700 objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols [ Upstream commit 3a83d9cd3d0e66c0ef99ce84f972ed26f50c990f ] Testing klp-build with arm64 produced the following linker error during the original kernel build: `__notrim.1' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.no_trim_symbol' of vmlinux.o symbol_get() puts a static __notrim[] in .no_trim_symbol, which GCC names __notrim.1, __notrim.2, etc. Two or more built-in translation units calling symbol_get() thus produce duplicate names, resulting in corresponding .klp.symid references which trigger the above error. Add .no_trim_symbol to the discarded section list so its symbols don't get symids. Note this issue is not specific to arm64: it just needs two built-in symbol_get() callers. arm64 trips over it easily because it has KVM always compiled in vmlinux, whereas on x86 it's typically a module. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/5a3cc4cded743167dd0878220201d80f7e48e5d7.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 87b3da4acb860605643ebee312178f13b20744cf 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 6424b9cde9edc7f2098115bbfd1ee3d84a958380 Author: Ning Ding Date: Mon Aug 10 20:59:54 2026 -0700 bpf: Compare iterator types during state pruning [ Upstream commit 83608e303b95d07afba1c15da0b5d9e513c2f15a ] An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots. Fixes: dfab99df147b ("bpf: teach the verifier to enforce css_iter and task_iter in RCU CS") Signed-off-by: Ning Ding Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260811035955.132989-2-dingning04@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 07697272bfacdd548eebff14ab76c60ffe816185 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 41033f8d870bf0f1e8d39682aabe18df3f5adee5 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 4302bc71ace164799d3514b1ff6379e3d9ae5296 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 c1829705803a52816a894c46f8ec8db2138f60b9 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 5eab61a483f4b84bc347214a901237fae6896997 Author: Willem de Bruijn Date: Mon Aug 3 17:06:23 2026 -0400 idpf: add missing cpu_to_le32 in idpf_tx_splitq_build_flow_desc [ Upstream commit b802a8c1ca16f9490fa0cb3110c00c10d52b392d ] idpf_tx_splitq_build_flow_desc performs a 32-bit store to &cmd_dtype to set the 8-bit cmd_dtype and zero the adjacent 3-byte timestamp field in a single operation. Descriptors are in little endian. Add missing cpu_to_le32 and cast to __le32 to ensure the fields are written correctly also on big endian platforms. Fixes: 1a49cf814fe1 ("idpf: add Tx timestamp flows") Signed-off-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 57715e257c8a51e3fd6497f0246e32faf8150244 Author: Robert Malz Date: Tue Aug 4 10:35:36 2026 +0200 ice: acquire NVM lock around each flash read [ Upstream commit df88d6f1ed653993bd5c8647aef0e6498f4b1647 ] FW caps the NVM read lock at a maximum of 3000ms regardless of the timeout requested via ice_acquire_nvm(). ice_read_flat_nvm() splits a read into multiple ice_aq_read_nvm() commands, one per 4KB sector, all issued under a single lock taken by the caller. Reading a large region can exceed 3000ms, so FW reclaims the lock mid-read and the remaining commands might fail. Move the lock acquire/release into ice_read_flat_nvm() so it brackets each individual ice_aq_read_nvm() command, ensuring the lock is never held across more than one FW read. ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, which some callers inspect after a failed read. Add an optional read_aq_err output parameter to ice_read_flat_nvm() to capture the failing read's AQ error before the release; callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status, others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. The now-redundant per-block locking in ice_devlink_nvm_snapshot() is dropped. ice_read_sr_word() is now a thin wrapper, so ice_read_sr_word_aq() is folded into it. Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") Signed-off-by: Robert Malz Reviewed-by: Przemek Kitszel Reviewed-by: Marcin Szycik Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit dfa94b403e69af9b674bd485c4fe375f21051568 Author: Petr Oros Date: Mon Jun 22 10:10:30 2026 +0200 ice: clear the default forwarding VSI rule when releasing a VSI [ Upstream commit d04287e27bf1c0b879a10d929c163f2da69715b6 ] When a VSI is configured as the switch's default forwarding VSI (ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release() -> ice_vsi_release()) does not disable promiscuous mode either, which only happens on VF reset in ice_vf_clear_all_promisc_modes(). A trusted VF that enters unicast promiscuous mode becomes the default forwarding VSI (this is the default mode, when the PF does not have VF true-promiscuous mode enabled). If the VFs are then destroyed without the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the freed hw_vsi_id. If it is assigned a different VSI handle than the leaked rule holds, ice_set_dflt_vsi() does not recognize it as already-default, and ice_add_update_vsi_list() folds the dangling (freed) handle into a VSI list, which the firmware rejects. The VSI handle assigned on re-creation varies, so the failure is intermittent rather than every cycle. Reproduce by repeatedly running the cycle below on the two ports of the same card, where $VF0 and $VF1 are the netdevs of vf 15 once they appear. The VF must be brought up so iavf actually pushes the unicast promiscuous request, and the rule must settle before the VFs are torn down again: echo 16 > /sys/class/net/$PF0/device/sriov_numvfs echo 16 > /sys/class/net/$PF1/device/sriov_numvfs ip link set $PF0 vf 15 trust on ip link set $PF1 vf 15 trust on ip link set $VF0 up ip link set $VF1 up ip link set $VF0 promisc on ip link set $VF1 promisc on sleep 1 echo 0 > /sys/class/net/$PF0/device/sriov_numvfs echo 0 > /sys/class/net/$PF1/device/sriov_numvfs Within a few cycles the ice PF and iavf VF log: Failed to set VSI 25 as the default forwarding VSI, error -22 Turning on/off promiscuous mode for VF 63 failed, error: -22 PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14 This cleanup used to live in ice_vsi_release() but was dropped by the referenced refactor. Restore it. Clear the default forwarding VSI rule in ice_vsi_release() when this VSI owns it, which covers every teardown path. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Signed-off-by: Petr Oros Reviewed-by: Marcin Szycik Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit dc0234c8c5730a13593ce70f8b39422034432a1b Author: Przemyslaw Korba Date: Fri Jun 5 14:06:26 2026 +0200 ice: fall back to SBQ when LL PHY timer interface times out [ Upstream commit 6959fbdc940f62d8eef2a171d3a3342d7c248855 ] The low-latency (LL) PHY timer interface relies on a tight, atomic poll of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update / EMPR, FW may need significantly longer than 2ms to start responding to ATQBAL commands. The first PHY adjust or incval write issued by ice_ptp_rebuild_owner() fails with -ETIMEDOUT. Fix this by falling back to the existing SBQ-based PHY register write path when LL times out. This makes sure PTP is initialized when FW takes longer than expected to come back online. Steps to reproduce: ./nvmupdate64e -if devlink -f Update E810 card with nvmupdate64e, and observe dmesg errors: Failed to write PHC increment value, status -110 PTP reset failed, error: -110 (-ETIMEDOUT) Fixes: ef9a64c07294 ("ice: implement low latency PHY timer updates") Signed-off-by: Przemyslaw Korba Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 64a2bd4cfc16c24f0a0e6321a2fd00ffde3e0a5b 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 ea41b5630fa3d9877ce9ed8832cf5575f742bfbb 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 068122750ee8ad059362df3751a15a79e866d316 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 99c91dca54a6c54234080d72bdf50e3239be601b Author: Cristian Ciocaltea Date: Tue Aug 11 18:44:46 2026 +0300 phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes [ Upstream commit aec3e4ce25da4ed37bbbfedcbb7107ae9428b183 ] Any changes to the PHY link rate and/or color depth done via the HDMI PHY configuration API are not immediately programmed into the hardware, but are delayed until the PHY usage count gets incremented from 0 to 1, that is when it is powered on or when the PLL clock exposed through the CCF API is prepared, whichever comes first. Since the clock might remain in prepared state after subsequent PHY config changes, the programming can also be triggered via clk_ops.set_rate(). However, from the clock consumer perspective (i.e. VOP2 display controller), the (pixel) clock rate doesn't vary with bpc, as that is handled internally by the PHY and reflected in the TDMS character rate only. As a consequence, changing the bpc while preserving the modeline may lead to out-of-sync issues between CCF and HDMI PHY config state, because the .set_rate() callback is not invoked when clock rate remains constant. This may also happen when the PHY PLL has been pre-programmed by an external entity, e.g. the bootloader, which is actually a regression introduced by the recent FRL-related changes. Introduce a pll_config_dirty flag to keep track of uncommitted PHY config changes and use it in clk_ops.determine_rate() to invalidate the current clock rate (as known by CCF) and, consequently, ensure those changes are programmed into hardware via clk_ops.set_rate(). Moreover, proceed with a similar fix in phy_ops.power_on() callback, to handle the scenario where the CCF API is not used due to operating in FRL mode, while the clock is still in a prepared state and thus preventing rk_hdptx_phy_consumer_get() to apply the updated PHY configuration. Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Tested-by: Thomas Niederprüm Tested-by: Simon Wright Tested-by: Diederik de Haas # NanoPC-T6 LTS Reviewed-by: Andy Yan Reviewed-by: Manivannan Sadhasivam Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-5-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c4506784a95ced768d6ba342b943dec14b74e770 Author: Cristian Ciocaltea Date: Tue Aug 11 18:44:45 2026 +0300 phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL [ Upstream commit 9ac3daadb9060360e937a5993a5fd88360d6fdad ] rk_hdptx_phy_clk_calc_rate_from_pll_cfg() is currently unable to handle cascade mode for the 3.2GHz FRL operating mode, as it relies solely on LCPLL_LCVCO_MODE_EN_MASK to determinate the rate from the rk_hdptx_frl_lcpll_cfg array. Since there is no entry for this particular rate, the function returns 0. This is the only rate which requires LC_REF_CLK_SEL to be set in GRF_HDPTX_CON0, hence extend the FRL matching accordingly. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Tested-by: Diederik de Haas # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov Reviewed-by: Andy Yan Reviewed-by: Manivannan Sadhasivam Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-4-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0a111684ed66339cfce5cc5583e0ba1e23ed8fc3 Author: Cristian Ciocaltea Date: Tue Aug 11 18:44:44 2026 +0300 phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow [ Upstream commit 229788526ff24e0607726e93b74dd2ef157a99cd ] The 'fout' subtraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could result in an integer underflow, if the hardware registers are misconfigured or contain uninitialized values, such that the computed sigma-delta modulator offset sdm exceeds the base frequency fout. This might lead to an absurdly high clock rate being returned to the Common Clock Framework, with unpredictable effects on downstream clk consumers. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260611235702.0E9691F000E9@smtp.kernel.org/ Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-3-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 877657310a66bf2b65a6efd5fb5b8a00cec6aefa Author: Cristian Ciocaltea Date: Tue Aug 11 18:44:43 2026 +0300 phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate [ Upstream commit c4fe5a9f379055ce0ec930f6495ae62aad237b89 ] Calculating 'sdm' fraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could trigger a divide-by-zero, as it uses div_u64() with a denominator read directly from hardware: the values ropll_hw.sdm_deno, ropll_hw.sdc_deno, ropll_hw.sdc_n, and ropll_hw.sdc_num are populated from PLL registers which, in theory, could be left by the bootloader uninitialized/misconfigured. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Diederik de Haas # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov Reviewed-by: Andy Yan Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-2-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b6823d7f95abcae35338bf66e6886013a3e3191b Author: Cristian Ciocaltea Date: Tue Aug 11 18:44:42 2026 +0300 phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc [ Upstream commit f0c2c9c58a48b621b1cb90f0821da422b31af814 ] The PHY PLL can be programmed by an external component, e.g. the bootloader, just before the recalc_rate() callback is invoked during devm_clk_hw_register() in the probe path. Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and attempts to compute the clock rate, while making use of the bpc value from the HDMI PHY configuration, which always defaults to 8 because phy_configure() was not run at that point. As a consequence, the (re)calculated rate is incorrect when the actual bpc was higher than 8. Do not rely on any of the hdmi_cfg members when computing the clock rate and, instead, read the required input data (i.e. bpc), directly from the hardware registers. Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Thomas Niederprüm Tested-by: Simon Wright Tested-by: Diederik de Haas # NanoPC-T6 LTS Reviewed-by: Andy Yan Reviewed-by: Dmitry Baryshkov Reviewed-by: Manivannan Sadhasivam Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-1-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6e6e471eef1d5d8cb056c7d364023fe048249204 Author: HyeongJun An Date: Tue Aug 11 22:18:35 2026 +0900 ALSA: seq: Don't leak the extension cell pointer in the bounce payload [ Upstream commit 59e1592d3c270ff4642d5d6dc55c545306eb0693 ] The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e ("ALSA: seq: Clear variable event pointer on read") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool. Fixes: efc86691e4d8 ("ALSA: seq: Fix kernel heap address leak in bounce_error_event()") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260811131835.3837024-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7d44b897bff84edcd4814899314d661ad4956a8e Author: Yun Zhou Date: Wed May 27 13:26:25 2026 +0800 nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing [ Upstream commit d56575a2595ee1f597f39e8a1cfb67ed3501678d ] nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure. Reported-by: syzbot+46ca2592193f2fb3debc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=46ca2592193f2fb3debc Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence") Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260527052625.3309581-1-yun.zhou@windriver.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 3ea115646abfdb6864b6282e6a2011cf50fcd954 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 3e7a093c177f9f8b9fd039cab41191515079425a 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 eeb16fb24cfe67947b832fd9ada5f488afc72579 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 ee08414d78b851e3d1856d6e4d631939b01a1bbe 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 d1b73962675cdc5a58e2707e25b548d8b495fde0 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 bd6f1277b62bc1df348ca21739df2bc546fcd493 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 6d8926debeb9d6c4ffa53d1de529dc79721ec7ce Author: Liang Hao Date: Fri Jul 31 23:04:08 2026 +0800 hrtimer: Account nr_retries on recovered interrupt retries [ Upstream commit 32a05ba399fc52661f59f38efd2e606f45eb2c8f ] Re-arranging hrtimer_interrupt() switched the retry path to a local counter and dropped the update of cpu_base->nr_retries, leaving the field exported via /proc/timer_list stuck at zero. Increment nr_retries only when another pass through the expiry loop is started; the third attempt that falls through to hang handling is still accounted by nr_hangs alone. Fixes: 288924384856 ("hrtimer: Re-arrange hrtimer_interrupt()") Signed-off-by: Liang Hao Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260731150408.19554-1-haohlliang@gmail.com Signed-off-by: Sasha Levin commit ece3da898ef56998e0045a050b4572d9caacd55e Author: Chao Shi Date: Wed Jul 15 11:57:52 2026 -0400 nvme: reject passthrough of driver-managed Set Features [ Upstream commit 1161be71d1ecf7dc785382114c71afed0349531e ] Since commit b58da2d270db ("nvme: update keep alive interval when kato is modified"), a Set Features (KATO) passthrough command lets userspace start keep-alive on any transport. nvme_keep_alive_work() allocates with BLK_MQ_REQ_RESERVED, but nvme_alloc_admin_tag_set() reserves admin tags only for fabrics, so on other transports the allocation trips WARN_ON_ONCE() in blk_mq_get_tag() and fails: nvme nvme0: keep-alive failed: -11 Several Set Features change controller state the driver manages itself and cannot react to when set behind its back. Reject these in nvme_admin_cmd_allowed(): - KATO on non-fabrics (keep-alive is only armed for fabrics; on PCIe it has no reserved tag and harms idle power states) - Host Behavior Support, Host Memory Buffer, Number of Queues, and Autonomous Power State Transition (all driver-managed) Keep Alive on fabrics is unchanged; I/O commands are unaffected as the check is confined to the admin path (ns == NULL). Link: https://lore.kernel.org/linux-nvme/20260523225629.3964037-1-coshi036@gmail.com/ Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modified") Found by FuzzNvme. Acked-by: Sungwoo Kim Acked-by: Dave Tian Acked-by: Weidong Zhu Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b116e9dae433ff631f94c36c61a7a78fe400ed1e Author: Yang Xiuwei Date: Mon Jul 20 14:03:05 2026 +0800 nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() [ Upstream commit b53d495c7f0db46b6748b5ade48371a10dd5d3bc ] Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES. Reviewed-by: Christoph Hellwig Signed-off-by: Yang Xiuwei Signed-off-by: Keith Busch Stable-dep-of: 1161be71d1ec ("nvme: reject passthrough of driver-managed Set Features") Signed-off-by: Sasha Levin commit 0b4cf43f9ca7118590a338de900edbd6047cd89f Author: Guixin Liu Date: Tue Aug 4 11:36:05 2026 +0800 nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() [ Upstream commit f594863967d87b7fcbff6e724d51135fd701a13d ] When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device. Fixes: aaf2e048af27 ("nvmet: add ZBD over ZNS backend support") Reviewed-by: Damien Le Moal Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit ad75556bde3ce83b1af243ce40c5ddc483eaed04 Author: Sven Peter Date: Thu Aug 6 17:27:38 2026 +0200 nvme-apple: Drop the PRP null check chicken bit [ Upstream commit 8ce883fd068b7ba9ab493cd3ecca3a7ea868c375 ] Now that we program the DMA direction correctly the NULL check that used to make commands fail passes. Another side effect of this bit was that non-align buffers on the admin queue were silently allowed and that's been fixed now as well and we this don't need this chicken bit anymore. More importantly, starting with the firmware installed with macOS 15, which is required for M4 but can also be installed on the previous SoCs, the controller no longer exposes this control register and any access SErrors instead. Just drop the write entirely. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit e01921930981352b718b18347bc467a121a3a731 Author: Sven Peter Date: Thu Aug 6 17:27:37 2026 +0200 nvme-apple: Require page aligned buffers on the admin queue [ Upstream commit ea2160c7b78187ea9ab08c3190eef237c4ee99a7 ] Now that we have a quick to align buffers on the admin queue to the NVMe controller page size use it for Apple controllers. This fixes pre-M1 controllers, which always rejected unaligned requests, and also makes this driver work for M4 SoCs and for M1/M2/M3 SoCs that have been updated to the firmware shipped with macOS 15. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 9650fd559f97fd7a0eea570a745e0c7d032735b7 Author: Sven Peter Date: Thu Aug 6 17:27:36 2026 +0200 nvme: Add a quirk for page aligned admin queue buffers [ Upstream commit 69d22a6b2f6984200d92dac689f8b00cc3d7d736 ] Apple controllers seem to require any queue buffers on the admin queue to be aligned to the NVMe controller page size. Weirdly, this constraint does not apply to the i/o queue where any alignment is fine. This has always been required on pre-M1 controllers and is required starting with macOS 15 firmware or post-M4 controllers again. On M1/M2/M3 we only got away with this because there was a chicken bit to disable this requirement. Let's add a quirk that enforces this alignment. Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Stable-dep-of: ea2160c7b781 ("nvme-apple: Require page aligned buffers on the admin queue") Signed-off-by: Sasha Levin commit 03fd8591e90a5fd84ac7e6478d7b4cf0f1f3f8b9 Author: Sven Peter Date: Thu Aug 6 17:27:35 2026 +0200 nvme-apple: Never set the opcode in the NVMMU TCB [ Upstream commit cc0fec9b42cfbc69d70cb4c4b616408a7037b445 ] macOS always sets this to zero and the firmware starting with macOS 15 has started to complain about what we're doing here. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 3bda132d063e6fc6510fd8c912aa45cd6c4dee70 Author: Sven Peter Date: Thu Aug 6 17:27:34 2026 +0200 nvme-apple: Don't set a DMA direction for commands without a data transfer [ Upstream commit 94dd5804938d6681dbf26f023b1356d511f4fc48 ] Setting the DMA direction for commands that don't do any transfer likely triggered the PRP NULL check for which we needed a chicken bit. That bit has disappeared starting with macOS 15 so let's just do this correctly instead. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit c11685ee4eedc70f738b117a4a8c0fbe84cd79b3 Author: Sven Peter Date: Thu Aug 6 17:27:33 2026 +0200 nvme-apple: Destroy the admin queue on removal [ Upstream commit 87d5b9864c8118d26f54de4b66d2bddf2c659272 ] The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ffffc00081915820 x7 : ffffc0001 x5 : ffff80001ca77d08 x4 : 0000000000000000 x3 : ffff80001ca77cb8 x2 : 0000000000000000 x1 : 000000007 Call trace: percpu_ref_tryget_many.constpro blk_mq_timeout_work+0x48/0x298 process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 Code: 91282000 97ed44b2 17ffffd2 ---[ end trace 0000000000000000 ]--- Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 7b81e4d2230e3d2d372c826180c4ef0efc244f31 Author: Guixin Liu Date: Tue Aug 4 11:38:00 2026 +0800 nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() [ Upstream commit 5bb96cc218835769ab74ec7f3ea2bf81fbffe955 ] nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit f6374ec9a3443e5697e6d671585fd3ee61b21e0d Author: Ilya Leoshkevich Date: Thu Aug 6 21:04:45 2026 +0200 s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN [ Upstream commit 3f7c9f9c36b47a2a5cdbc56597eddf32662ef7fa ] Inline KMSAN arch_local_irq_*() definitions run afoul of -Wstatic-in-inline. Move them out-of-line. Make sure decompressor and non-GPL modules see the out-of-line definitions. Cc: Boqun Feng Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607131219.euJHPSJ5-lkp@intel.com/ Suggested-by: Heiko Carstens Fixes: 1b301f5f28ba ("s390/irqflags: do not instrument arch_local_irq_*() with KMSAN") Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 7954540e49ffb8ed8b4407be5ae62e6a6ea7dea8 Author: Josh Poimboeuf Date: Tue Aug 11 14:11:44 2026 +0000 arm64: bti: Disable in-kernel BTI with recent versions of Clang [ Upstream commit d3359af21fc9e7a47577ff90e821b6510ec34dee ] The following BTI exception was seen when loading a livepatch module: Internal error: Oops - BTI: 0000000036000001 [#1] SMP pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc) pc : kill_orphaned_pgrp+0x0/0x150 lr : do_exit+0x498/0xaf0 [livepatch_combined] The problem is that the patch module's do_exit() is branching to a static function in vmlinux using a module PLT veneer (indirect branch), but the target function doesn't have a BTI landing pad. Clang 21+ omits the landing pad for static functions which can only be reached by a direct branch. That's normally fine for ordinary modules which only branch to global exported functions, but Mark Brown points out [1] that this isn't guaranteed if the module branches between sections. Futhermore, livepatch modules use klp relocations to reference arbitrary kernel symbols, so with CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough from the kernel that every R_AARCH64_CALL26 needs a PLT. Put Clang 21+ in the naughty corner alongside GCC, which suffers from the same issue, by disabling CONFIG_ARM64_BTI_KERNEL until we have a version of the toolchain with the problem resolved. Cc: Ard Biesheuvel Link: https://lore.kernel.org/r/da06bbd3-d04b-4d0f-b331-f5b91bc373a5@sirena.org.uk [1] Fixes: fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH") Signed-off-by: Josh Poimboeuf [will: Stitched together commit message, diff and bug number] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 78ac8fc22b12f85aefd6afeafed012e03626618c Author: Jorijn van der Graaf Date: Sun Jul 26 23:12:26 2026 +0200 ASoC: qcom: q6apm: keep the graph start count in sync with the DSP [ Upstream commit daa7ffd765ae67a83e77dae32c66ce2d6d995d19 ] q6apm_graph_start() increments start_count even when APM_CMD_GRAPH_START fails, leaving the graph counted as running while the DSP never started it. A later start - a retried prepare, or a resume after a failed start - then finds a non-zero count, skips the command and returns success with no data flowing. Count the graph only once the DSP has accepted the start. The count then stays at zero for a graph that never started, so also stop decrementing below zero in q6apm_graph_stop(): the compressed free path stops unconditionally, and a negative count would make the next start skip the command in the same way. Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Assisted-by: Claude:claude-opus-5 Signed-off-by: Jorijn van der Graaf Link: https://patch.msgid.link/20260726211226.94059-1-jorijnvdgraaf@catcrafts.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b5fb0376c773d59000345ee653cb039e2792d40a 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 49a61174186bed25d439ff37400c7ce5e3603e73 Author: Vladimir Murzin Date: Mon Jul 27 17:34:17 2026 +0100 arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit [ Upstream commit 39aebe0e89469c2904e60b1e977e0d4dbf33326b ] Currently, when exiting to kernel mode, we attempt involuntary preemption. The preemption logic expects IRQs to be disabled, which is why we call local_irq_disable() before attempting preemption. However, depending on the context, local_irq_disable() may be unnecessary: - __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so local_irq_disable() is redundant. - irqentry_exit_to_kernel_mode_preempt() immediately returns when exiting from an NMI-like context, so calling local_irq_disable() beforehand is unnecessary work. Furthermore, it confuses the pNMI state tracking when we are in a context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set in the PMR, leading to a warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y: WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805 CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--) pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) lr : el1_abort (arch/arm64/kernel/entry-common.c:323) pmr: 000000f0 Call trace: arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P) el1_abort (arch/arm64/kernel/entry-common.c:323) el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449) el1h_64_sync (arch/arm64/kernel/entry.S:589) [...] Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and dispatch parts so that we can avoid this extra work where it is not needed and avoid breaking the pNMI tracking logic. Reported-by: Breno Leitao Fixes: ae654112eac0 ("arm64: entry: Use split preemption logic") Link: https://lore.kernel.org/all/20260807-arm64_fix-v1-1-d069ccf9d71b@debian.org/ Reviewed-by: Jinjie Ruan Signed-off-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit fdda85094b2f6f77b5d2d934aaa6c8969fd48c71 Author: Esteban Urrutia Date: Sat Jul 11 23:13:18 2026 -0400 phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy [ Upstream commit 8fd2b30d187fa33e5dd30699d3e3a3662c1610c9 ] There are no downstream device trees that specify five values in the qcom,aux-cfg1-settings array. Plus, after cross referencing both downstream device trees and entries which refer this function, only 0x13 is specified. Since 0x13 is written at initialization time, drop this function as a whole, and remove now unused variable assignations. Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy") Reviewed-by: Dmitry Baryshkov Signed-off-by: Esteban Urrutia Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-2-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8dda7211be1ea81fdbd54315443cbca2178b3e9c Author: Esteban Urrutia Date: Sat Jul 11 23:13:17 2026 -0400 phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs [ Upstream commit 481807f939077059db278edd0467e7e609b6c9a7 ] Comparing sm8350 and sm8450 tables, this seems to be a typo. Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support") Signed-off-by: Esteban Urrutia Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-1-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8ecad7d61482ff77fa1f32dbcbf1bb23d00b5dc3 Author: Lad Prabhakar Date: Thu Jul 2 13:58:55 2026 +0100 phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator [ Upstream commit 9ea8d49c6cc6e217f5f5818369f659dc25bf89bf ] Commit b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") introduced support for controlling OTG VBUS through the regulator framework. As part of this change, the driver started requesting an exclusive "vbus" regulator for OTG-capable PHYs with no_adp_ctrl set. The lookup failure was propagated unconditionally, causing probe to fail on platforms where no VBUS regulator is described. On RZ/V2H and RZ/V2N, which do not use a VBUS regulator, this results in the following error: phy_rcar_gen3_usb2 15800200.usb-phy: dummy supplies not allowed for exclusive requests (id=vbus) This failure completely prevents the USB 2.0 interface from initializing. Fix this by allowing the probe to continue if an external VBUS regulator is missing. Only propagate the error if the internal vbus-regulator node is explicitly present, or if the lookup returns -EPROBE_DEFER. For all other missing regulator errors, gracefully assume no external VBUS regulator is available and return 0. Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") Signed-off-by: Lad Prabhakar Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Link: https://patch.msgid.link/20260702125855.3157253-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2041b75c123fe47597f9aad68032730d2c48602b Author: Mukesh Kumar Chaurasiya (IBM) Date: Tue Aug 11 12:03:45 2026 +0530 rust: uapi: replace direct asm-generic/ioctl.h include with linux/ioctl.h [ Upstream commit cdfcaa36ac93aa96df8310d7e57860f7600b2861 ] rust/uapi/uapi_helper.h was directly including instead of the proper . On powerpc, pulls in first, which defines _IOC_SIZEBITS, _IOC_DIRBITS, _IOC_NONE, and _IOC_WRITE with the arch-specific values, before falling through to . By bypassing that chain and including directly, the arch-specific overrides never ran first, so when other headers in the compilation later brought in the full arch-aware chain, Clang saw those four macros being defined a second time and emitted: clang diag: arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning: '_IOC_SIZEBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning: '_IOC_DIRBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning: '_IOC_NONE' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning: '_IOC_WRITE' macro redefined [-Wmacro-redefined] Fix this by replacing the direct include of with , which is the correct arch-aware entry point and already maintains the intended include order. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608050618.9dekfjtF-lkp@intel.com/ Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate") Link: https://patch.msgid.link/20260811063345.685884-1-mkchauras@gmail.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit ddddf034ac0e704577876ea997df99f99aecbddf Author: Vasant Hegde Date: Tue Aug 11 04:08:56 2026 +0000 iommu/amd: Fix incorrect device ID in invalid PASID error message [ Upstream commit 5322e19fc5acf013784207bc38191cd418a8bb48 ] The IO page fault notifier handler logs pdev->dev.id when reporting an invalid PASID, but pdev->dev.id is the kernel-internal device ID and not the IOMMU device ID (BDF). Use dev_data->devid instead, which reflects actual devid. Fixes: 978d626b8f1a ("iommu/amd: Add IO page fault notifier handler") Signed-off-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7da0bdf0610f6d35bbb061536a47fc41646306f0 Author: John Johansen Date: Fri May 8 22:30:07 2026 -0700 apparmor: fix unconfined user namespace restriction forced stack [ Upstream commit 08c2f7c8d4b1434cfae006f3daf4d1bce330b57b ] If a task is already confined by a stack the unprivileged transition restriction on unconfined is not correctly, applied. This results in an escape if two transitions through an unconfined profile can be executed. Fix this by pushing the check into the per profile label build. The check will always be done against unconfined and result in a stack of just the unconfined component when necessary. Fixes: 2d9da9b188b8 ("apparmor: allow restricting unprivileged change_profile") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4b835e45a4bb34bd0a12312c0f21b3b49f529f19 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 db7c3ced1fe8f03fbba5dd6b4223d0d9297e9bad Author: Willem de Bruijn Date: Sat Aug 8 12:00:44 2026 -0400 selftests: drv-net: so_txtime: only send test traffic to sch_etf [ Upstream commit ef3d6cca02c8a7b6465fb1691823524b86d1cb99 ] The ETF qdiscs drops traffic without a socket or txtime. Even with parameter skip_sock_check regular traffic is affected by ETF. This test ran fine when run manually in a pure software environment. But with drv-net across two hosts tests fail as early as when calling cfg.remote.deploy due to effectively losing connectivity. Isolate the intended test traffic: - mark that with SO_MARK 100 - install a regular permissive root prio qdisc for background traffic - install the ETF qdisc as leaf - install a filter that only directs SO_MARK 100 traffic to this leaf Technically other high prio traffic will map onto this leaf based on ToS band mapping too. But that is immaterial in practice. Fixes: 5c6baef3885c ("selftests: drv-net: convert so_txtime to drv-net") Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260808160129.890119-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab7891cab3f118b2dc61d4fbab279cab6f6ad898 Author: Mohsin Bashir Date: Thu Jul 30 19:15:42 2026 -0700 selftests: drv-net: Test queue stall upon reconfig [ Upstream commit c98610c2eb7002436f6fca55b21c63200644549a ] Add a reconfig_tx_stall test that detects the possibility of a TX stall after ring reconfiguration. The key observation is that drivers using netif_tx_start_all_queues() are prone to experiencing a stall when reconfiguration completes compared to drivers using netif_tx_wake_all_queues(). start_all_queues only clears DRV_XOFF, while wake_all_queues also calls __netif_schedule() to kick the qdisc. Without the kick, qdisc backlog present at reconfig time can stay stuck until a new trigger is issued. The test caps the TX ring at 64 entries so it fills quickly, then installs FQ on a target TX queue and sends UDP packets with SO_TXTIME scheduled in the future. With napi_defer_hard_irqs slowing completions, the small ring can fill when FQ releases the burst, leaving requeued qdisc backlog with no FQ timer to rescue it. A subsequent ring reconfig must wake the queues to drain the backlog. Simply starting the queues can leave it stuck. Some drivers lack backpressure on the TX path and may not be able to build up the qdisc backlog the test relies on. In that case report an expected failure (xfail) instead of a hard failure. Testing on some of the existing drivers: Driver-A does not have the bug, Driver-B has the bug, Driver-C had the bug but it is fixed now. Driver-A: ./drivers/net/ring_reconfig.py -t reconfig_tx_stall TAP version 13 1..1 Sent 1024 SO_TXTIME packets (+100ms) Backlog before reconfig: 1176378 bytes ok 1 ring_reconfig.reconfig_tx_stall Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 Driver-B: TAP version 13 1..1 Sent 128 SO_TXTIME packets (+100ms) Sent 128 SO_TXTIME packets (+200ms) Backlog before reconfig: 148372 bytes Check| At ./drivers/net/ring_reconfig.py, line 397, in reconfig_tx_stall: Check| ksft_eq(0, backlog, Check failed 0 != 148372 qdisc backlog stuck on queue 1 after ring .... not ok 1 ring_reconfig.reconfig_tx_stall Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 Driver-C: TAP version 13 1..1 Sent 128 SO_TXTIME packets (+100ms) Backlog before reconfig: 192278 bytes ok 1 ring_reconfig.reconfig_tx_stall Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Mohsin Bashir Link: https://patch.msgid.link/20260731021543.1058526-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: ef3d6cca02c8 ("selftests: drv-net: so_txtime: only send test traffic to sch_etf") Signed-off-by: Sasha Levin commit 8dd136173106cf933ff1592a6ede349e01735e5b Author: Jia Wang Date: Fri Jul 31 09:14:29 2026 +0800 PCI: ultrarisc: Get and enable DP1000 PCIe controller clocks [ Upstream commit e152c295d32a15975c480c352000454b9eb5fb07 ] Add the required core, dbi, and aux clocks for the DP1000 PCIe controller and enable them before initializing the controller. Also manage the clocks across system suspend and resume. Fixes: 5fc35740c3b3 ("PCI: ultrarisc: Add UltraRISC DP1000 PCIe Root Complex driver") Signed-off-by: Jia Wang Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260731-ultrarisc-pci-clk-v4-2-d738b491e49a@ultrarisc.com Signed-off-by: Sasha Levin commit e1dc0af719a2566ae7ccb82c0a11f70aa54908e9 Author: Kuniyuki Iwashima Date: Fri Aug 7 02:03:23 2026 +0000 amt: Don't support cross-netns setup. [ Upstream commit e99ecc3046ea5f5c6b5e1f8b4ef854c6c6998e06 ] When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems. 1. amt_lookup_upper_dev() looks up an upper device in the lower device's netns only 2. amt_device_event() unregisters a single upper device only If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0] The cross-netns setup seems unintentional considering 1. and the following points: * amt_link_setup() sets dev->netns_immutable to true * skb_scrub_packet() is not called in the fast path * iproute2 binary fails to find cross-netns lower device via link-netns: # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 Cannot find device "veth1" Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup. Note that the problem 2. needs a separate fix. [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS: 00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace: rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674) rtnetlink_rcv_msg (net/core/rtnetlink.c:7112) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1319) netlink_sendmsg (net/netlink/af_netlink.c:1900) ____sys_sendmsg (net/socket.c:775) __sys_sendmsg (net/socket.c:2738) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791) __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963) netdev_upper_dev_link (net/core/dev.c:9009) amt_newlink (drivers/net/amt.c:3321) Fixes: b9022b53adad ("amt: add control plane of amt interface") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Taehee Yoo Link: https://patch.msgid.link/20260807020326.2519445-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98518a8312dc105d87938abc70428cab3ec8dc9a Author: Simon Glass Date: Wed Jul 29 07:27:25 2026 -0600 pinctrl: rockchip: Decode drive strength in the get function [ Upstream commit 8aa25c6e8893ed911b0cad37a5562fda9bc98438 ] The decoding of the 2-bit and 8-bit level drive-strength values sits in rockchip_set_drive_perpin(), where it is unreachable: the SoCs whose banks declare these drive types (RK3506 and RV1103B) take the early ctrl->type branch in the set path, and the read-and-decode logic in a set function has no purpose. Meanwhile rockchip_get_drive_perpin() lacks the decoding, so pin_config_get() and the debugfs output report -EINVAL for these SoCs. Move the two cases to rockchip_get_drive_perpin(), where they belong. Fixes: dbd2317d7b9f ("pinctrl: rockchip: Add rk3506 pinctrl support") Signed-off-by: Simon Glass Reviewed-by: Heiko Stuebner Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 608816b886a229a597f738578597401b61956270 Author: Liang Luo Date: Fri Aug 7 09:39:12 2026 +0800 selftests/sched_ext: Check skeleton open failure in exit test [ Upstream commit 4dc310b41aba43e9d8dfafe46dce86f8b55c0354 ] exit.c does not check the return value of exit__open(). If it returns NULL, which happens when the skeleton wrapper fails to allocate the object or open the BPF ELF, the very next line dereferences it via SCX_ENUM_INIT(). That macro expands to SCX_ENUM_SET(), which accesses skel->rodata, causing a NULL pointer dereference. Every other selftest guards this with SCX_FAIL_IF(!skel, ...); exit.c is the only one missing it. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 972d037f0046472c88e96aac06ef899f44b23277 Author: Rui Qi Date: Sun Aug 9 16:21:10 2026 +0800 selftests/cgroup: Avoid awk -e in cpuset tests [ Upstream commit 75e79a20190040800445ec95a4c4a84193d16992 ] The cpuset selftests use awk -e to parse cgroup mount points. This works with gawk, but mawk rejects the option. In test_cpuset_prs.sh, this leaves CGROUP2 empty and causes the test to skip as if cgroup v2 were not mounted. The same non-portable invocation exists in the cpuset v1 hotplug test. The scripts only need to pass a single awk program. Use the standard awk invocation without -e so mount point detection works with awk implementations that do not support the gawk extension. Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test") Fixes: 812c5945bdb8 ("cgroup/cpuset: Add test_cpuset_v1_hp.sh") Signed-off-by: Rui Qi Acked-by: Waiman Long Reviewed-by: Ridong Chen Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3f3811bacd93ff7c706ef0e416c85b441a29dd89 Author: Guopeng Zhang Date: Mon Aug 10 17:55:59 2026 +0800 cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates [ Upstream commit 26d3a59e0241c3ef9f66ae1ae990f9326acbc059 ] cpuset_partition_show() reads cs->prs_err without cpuset_mutex using READ_ONCE(). The field is documented as not lock protected, but several updates to live cpusets still use plain stores. Convert the remaining prs_err stores on live cpusets to WRITE_ONCE(). Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Assisted-by: LLM Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 79fb405966edb5065234440d94cc75bfd7b01f41 Author: Guixin Liu Date: Tue Aug 4 10:18:59 2026 +0800 nvme-pci: release descriptor pools on probe failure [ Upstream commit cb144c2f67128abfa5c7ba33318617d19f192156 ] The per-NUMA-node descriptor DMA pools are created lazily from nvme_init_hctx_common() once the admin tag set is allocated, but they are only destroyed in nvme_remove() via nvme_release_descriptor_pools(). Any probe failure after the admin tag set has been allocated unwinds through the out_disable label and nvme_pci_free_ctrl(), neither of which releases the pools, leaking the dma_pool objects. Release the descriptor pools in the out_disable error path. It must not be added to nvme_pci_free_ctrl(), as that would double-free against nvme_remove() on the normal teardown path. Fixes: d977506f8863 ("nvme-pci: make PRP list DMA pools per-NUMA-node") Signed-off-by: Guixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit cead174d424216de7a791bc3b9a8835ecb393ef0 Author: Guixin Liu Date: Tue Aug 4 10:18:58 2026 +0800 nvmet: propagate percpu_ref_init() failure in nvmet_ns_enable() [ Upstream commit 751709592d2626eaa8dc17ef8137796758a3c37f ] The return value of percpu_ref_init() is discarded. At this point ret is 0 from the preceding successful steps, so when the allocation inside percpu_ref_init() fails the code jumps to the out_pr_exit cleanup chain which ends with "return ret", i.e. reports success. The configfs enable store then tells userspace the namespace was enabled even though it was not and its backing device has already been torn down. Capture the return value so the failure is propagated. Fixes: 408232680707 ("nvmet: Fix crash when a namespace is disabled") Signed-off-by: Guixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 480f6b92c914be0e059634c8126d0d1dfcd1afdc Author: Zhengrong Li Date: Tue Jul 28 16:26:01 2026 +0800 nvmet: fix Reservation Register Replace for unregistered host with IEKEY [ Upstream commit 0a96b9e440331bffbf049f80d7e5c96417d37e36 ] When a host sends a Reservation Register command with RREGA=Replace and IEKEY=1 without being previously registered, nvmet returns Reservation Conflict. The NVMe specification states: "A host may replace its reservation key without regard to its registration status or current reservation key value by setting the Ignore Existing Key (IEKEY) bit to '1' in the Reservation Register command." Fix nvmet_pr_replace() to add a new registrant when the host is not found in the registrant list and IEKEY is set with a non-zero NRKEY. If IEKEY is set but NRKEY is zero, return Invalid Field since there is no valid reservation key to register. Tested with nvme-cli against nvmet-tcp: # no prior registration nvme resv-register /dev/nvmeXn1 -n 1 --rrega=2 --iekey --nrkey=0x9999 Before: RESERVATION_CONFLICT (0x4083) After: success, registrant created with rkey 0x9999 Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Reviewed-by: Christoph Hellwig Reviewed-by: Guixin Liu Signed-off-by: Zhengrong Li Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 92533e49fe3c455088657b862cf3562260c0ce25 Author: Chuck Lever Date: Wed Jun 17 08:52:57 2026 -0400 NFS: Return a delegation the client fails to record [ Upstream commit 220af23d863995091f0edeb1e6aa0945b3db8b37 ] When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows. Fixes: ade04647dd56 ("NFSv4: Ensure we honour NFS_DELEGATION_RETURNING in nfs_inode_set_delegation()") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d8f0b83753809761a560c4b33249388548ba6e43 Author: Runyu Xiao Date: Thu Jun 11 13:35:56 2026 +0800 sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE [ Upstream commit 33930840b5f0a79f826e7c69dc6cd78f72a67481 ] xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged. Fixes: a246b0105bbd ("[PATCH] RPC: introduce client-side transport switch") Signed-off-by: Runyu Xiao Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit eb476289c12cc22c8766f8a84eeb7ab46c4e8fb6 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 3039101d61bbd8aae2b29fc0cb77e05aebdae21b Author: surendra Date: Tue Jul 21 11:20:22 2026 +0530 hwmon: (pmbus/ltc4283) Add missing MODULE_DEVICE_TABLE for OF match table [ Upstream commit bd300460cee457c50a16a42654d6de4c85562785 ] The driver registers ltc4283_of_match as the platform driver's .of_match_table so the kernel probes the device when a DT node with compatible "adi,ltc4283" is present, but the corresponding MODULE_DEVICE_TABLE(of, ...) call is absent. Without it the module alias table (modules.alias) does not contain an "of:N*T*Cadi,ltc4283" entry, so udev / kmod cannot auto-load the module when the DT node appears, breaking modules-based deployments while built-in configurations happen to work by accident. Add the missing MODULE_DEVICE_TABLE() to fix module auto-loading. Fixes: dd63353a0b5e ("hwmon: ltc4283: Add support for the LTC4283 Swap Controller") Signed-off-by: surendra Link: https://lore.kernel.org/r/20260721055022.34629-1-kr494167@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit bf3d173e1c410750f5223eb7a680a537da2c8680 Author: Thomas Weißschuh Date: Sat Jul 11 11:59:07 2026 +0200 hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks [ Upstream commit 26db273640887276a24ca2546b06e334508871f8 ] To guarantee consistency for the read-modify-write access in cros_ec_hwmon_cooling_set_cur_state(), locking is necessary. Use the existing hwmon device lock to do so. Fixes: 5798b62867b4 ("hwmon: (cros_ec) register fans into thermal framework cooling devices") Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-3-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2a1828d693e6181fb11b7482564c7e69e194248a Author: Thomas Weißschuh Date: Sat Jul 11 11:59:06 2026 +0200 hwmon: (cros_ec) Store the hwmon device in cros_ec_hwmon_priv [ Upstream commit 434baf3aea987ae61d0d54b6cdf8fccf78383b4e ] The upcoming locking scheme for thermal devices will require access to the hwmon device. Add it do the priv struct. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-2-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit a098347049660d669c0ee7e2e9aa94846897c399 Author: Thomas Weißschuh Date: Sat Jul 11 11:59:05 2026 +0200 hwmon: (cros_ec) Register the thermal devices after the hwmon ones [ Upstream commit 9f1012119f2a4cb5a7f589dc77d5e15dbab49d00 ] To guarantee consistency for the read-modify-write access in cros_ec_hwmon_cooling_set_cur_state(), locking is necessary. The locking will use standard hwmon device locks, which requires the hwmon device to be ready before the fan devices are set up. Reorder the initialization so this works. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-1-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 08d4a5f731b339144eeaabc1a4c25e151ad409f5 Author: Marco Elver Date: Fri Aug 7 13:37:32 2026 +0000 arm64: Disable KCSAN instrumentation in delay.o [ Upstream commit 5eaec4cf41a8f5ac1a0c69a607cdc5035a797f73 ] KCSAN relies on udelay() for injecting delays. To avoid recursively triggering a watchpoint, where KCSAN sets up watchpoint on an address that is accessed by udelay() in the same thread, disable instrumentation in arm64's delay implementation. Paul found a manifestation of this as follows: | BUG: KCSAN: data-race in __delay / set_need_resched_current | | read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8: | __delay+0xb0/0x378 | __udelay+0x4c/0x60 | kcsan_setup_watchpoint+0x3b4/0x820 | __tsan_unaligned_write4+0x228/0x26c | set_need_resched_current+0x138/0x1a8 | rcu_exp_handler+0x418/0x4a0 | __flush_smp_call_function_queue+0x36c/0x4a0 | generic_smp_call_function_single_interrupt+0x20/0x30 | ipi_handler+0xec/0x558 | handle_percpu_devid_irq+0x220/0x2a0 | generic_handle_domain_irq+0x84/0xb4 | gic_handle_irq+0x64/0x144 | call_on_irq_stack+0x30/0x48 | do_interrupt_handler+0x80/0xb8 | el1_interrupt+0x3c/0x60 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x6c/0x70 | smp_call_function_single+0x18c/0x25c | sync_rcu_exp_select_node_cpus+0x534/0x8bc | rcu_exp_sel_wait_wake+0x358/0xef4 | wait_rcu_exp_gp+0x30/0x44 | kthread_worker_fn+0x1b4/0x5dc | kthread+0x1d8/0x204 | ret_from_fork+0x10/0x20 | | write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8: | set_need_resched_current+0x138/0x1a8 | [...] This matches what is already done in arch/x86/lib/Makefile. Reported-by: "Paul E. McKenney" Fixes: dd03762ab608 ("arm64: Enable KCSAN") Signed-off-by: Marco Elver Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 16fb33a8a323fefcb5f7fea8518dd6f358939ede Author: Chuck Lever Date: Sun Jul 12 15:31:22 2026 -0400 xdrgen: Fix opaque and string encoders for unbounded members [ Upstream commit daa52e37851a5a1b5890e7a250a27e94a8b9f273 ] The variable-length opaque and string encoder templates emit an unconditional bound check, "if (value->NAME.len > MAXSIZE) return false". XDR represents an unbounded specifier (opaque foo<>, string foo<>) as a maxsize of 0, so for an unbounded member the check degenerates to "len > 0" and the generated encoder refuses every non-empty value. The decoder does not share this defect. It delegates to xdrgen_decode_opaque() and xdrgen_decode_string(), which treat a maxlen of 0 as unbounded and skip the length check. The sibling variable-length array templates already guard their bound check with maxsize != "0". Guard the bound check the same way in each affected template -- the struct and pointer forms of both the opaque and string encoders -- so an unbounded member encodes a payload of any length while a bounded member keeps its limit. An explicit zero-length bound (foo<0>) parses to the same maxsize of 0 and so also skips the check; xdrgen does not distinguish it from the unbounded form, matching the decoder and the array encoders. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-6-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 621d4bba8f4c66c92644e7926670ae468bb4b5b7 Author: Chuck Lever Date: Sun Jul 12 15:31:21 2026 -0400 xdrgen: Add XDR width macros for short integer types [ Upstream commit c488328375beb4e3a3ca0526919c81767ce1de95 ] Commit ae78eb497868 ("xdrgen: Implement short (16-bit) integer types") taught the generator to emit XDR_short and XDR_unsigned_short in the computed maxsize macros and added the matching encode and decode primitives to _builtins.h, but it left the two width macros themselves undefined in _defs.h. Define XDR_short and XDR_unsigned_short, each one XDR unit wide, to match the width the generator's maxsize table assigns them. Fixes: ae78eb497868 ("xdrgen: Implement short (16-bit) integer types") Link: https://patch.msgid.link/20260712193122.116845-5-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5585954164f50de1165d0a49e7b70be24908acc2 Author: Chuck Lever Date: Sun Jul 12 15:31:20 2026 -0400 xdrgen: Do not declare union XDR functions in the definitions header [ Upstream commit d4ca0b0a6c62bc12407060754df11b23a90f3e57 ] Unlike the struct, enum, typedef, and pointer templates, the union definitions template also emits xdrgen_decode_*() and xdrgen_encode_*() prototypes for a public union into that header. Those prototypes name struct xdr_stream, which the definitions header neither includes nor forward-declares, so any translation unit that includes the definitions header without xdr.h already in scope draws -Wvisibility warnings. The same public prototypes are emitted into the declarations header, which does include , making the definitions-header copies redundant. Drop the prototype emission from the union definitions template so it matches the other type templates. Public unions keep their encode and decode prototypes through the declarations header. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-4-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit af0f6fb2a2f93fb142ec53dbee601d35120bd206 Author: Chuck Lever Date: Sun Jul 12 15:31:18 2026 -0400 xdrgen: Emit a blank line ahead of enum declarations [ Upstream commit ec5a7c2dceb09caf36262ecbd633eb7d4f9e4d3d ] Clean up. The declaration templates for structs, pointers, and typedefs each begin with a blank line, which keeps successive declarations and the include block above them visually separated. The enum declaration template omits that blank line. trim_blocks collapses the template's lone comment line to nothing, so the omission stayed invisible as long as every generated header happened to lead with a non-enum declaration. Fixes: 4329010ad9c3 ("xdrgen: Address some checkpatch whitespace complaints") Link: https://patch.msgid.link/20260712193122.116845-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7ea29e2bffffcccd1181a54cdc4155daaace5a49 Author: Chuck Lever Date: Tue Jun 30 11:56:38 2026 -0400 lockd: Regenerate NLMv4 XDR code [ Upstream commit e1d6e968ee26eee9654e35cd8141e38cefe307a4 ] The checked-in NLMv4 xdrgen output predates the addition of enum value validation to generated decoders. As a result the decoders for fsh4_mode, fsh4_access, and nlm4_stats still accept any 32-bit value, while the current generator rejects values outside the enumeration. Resync the generated files with the in-tree xdrgen by regenerating from the unchanged nlm4.x specification. This is a plain regeneration with no specification change; it also refreshes the recorded specification modification time to show that all existing enum decoders have picked up the xdrgen tool fix. Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260630155638.874492-1-cel@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations") Signed-off-by: Sasha Levin commit 0a7908d48ea04cc977c362314f2e4205b79b2557 Author: Jeff Layton Date: Tue Jun 16 07:58:45 2026 -0400 nfsd: add protocol support for CB_NOTIFY [ Upstream commit a0ac2a63d4b21455985436fbc70192da14a163fd ] Add the necessary bits to nfs4_1.x and remove the duplicate definitions from nfs4.h and the uapi nfs4 header. Regenerate the xdr files. Note that regenerating these files caused conflicts with the definitions of NFS4_VERIFIER_SIZE and NFS4_FHSIZE in include/uapi/linux/nfs4.h. These constants are defined by the RFC, and are not part of the kernel API. They have been removed. Userspace consumers who require those constants should plan to get them from more authoritative sources. The nfsstat4 enum defined in the .x is fed to the xdrgen-generated wire encoder and decoder, which treat every enumerated value as legal on the wire. Do not carry the NFS4ERR_FIRST_FREE sentinel (which is not a protocol error code) into the .x; keeping it would make 10097 a value that could leak onto the wire. Instead base nfsd's internal error codes (NFSERR_EOF and friends) at an impossible nfsstat4 value, as lockd does for its nlm__int__* status codes. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260616-dir-deleg-v7-2-6cbc7eac0ade@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations") Signed-off-by: Sasha Levin commit 7458727fd7cb79d09e5120b6fecc1ad11cdb0946 Author: Chuck Lever Date: Thu Jul 9 13:40:32 2026 -0400 NFSD: Release the export reference when reaping open stateids [ Upstream commit 6480bd703684ed3f760e9e36c4a699033c0806ae ] nfs4_put_stid() releases the svc_export tracked in nfs4_stid.sc_export, but free_ol_stateid_reaplist() frees open and lock stateids by calling ->sc_free() directly, bypassing that path. An open stateid takes an sc_export reference in nfs4_open() and a lock stateid takes its own in init_lock_stateid(); both reach free_ol_stateid_reaplist() through their normal teardown, the open stateid via release_open_stateid() and the lock stateid via nfsd4_release_lockowner(), each through put_ol_stateid_locked(). The reference is therefore never dropped, pinning the export and blocking unmount for the lifetime of the stateid. Release sc_export in free_ol_stateid_reaplist() the way nfs4_put_stid() does. ->sc_free() runs once per stateid, and a stateid reaches free_ol_stateid_reaplist() or nfs4_put_stid() but never both, so the reference is dropped exactly once. Revoked stateids reach this path with sc_export already cleared by drop_stid_export(), so they are skipped rather than double-freed. nfs4_put_stid() itself read sc_export before acquiring cl_lock. drop_stid_export() clears that field and releases the reference under cl_lock, so a concurrent revocation could drop the export in the window between the read and the final put, releasing the same reference twice. Read sc_export while cl_lock is held so the two paths serialize and the reference is released exactly once. Fixes: ba0cde5dc81d ("NFSD: Track svc_export in nfs4_stid") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260707-cel-v3-0-7c0cc16fd54f@kernel.org?part=9 Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-9-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit af3fe52fd108fd38235e4813df62442ed0f1d8ff Author: Pablo Neira Ayuso Date: Mon Aug 10 00:17:41 2026 +0200 netfilter: nft_ct: move custom expectation support to helper [ Upstream commit 3679da4ad8be84cddaf40bc307fef1fe13e051ff ] Originally, the ct expectation support called nf_ct_helper_ext_add() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc ("netfilter: nft_ct: skip expectations for confirmed conntrack") which restricted it to unconfirmed conntracks. However, early insertion of expectations into the expectations list when the conntrack is unconfirmed leads to stale entries pointing to the wrong hlist_head through .pprev due to ct extension reallocation. Commit 7c9664351980 ("netfilter: move nat hlist_head to nf_conn") moved the nat hlist_head to nf_conn for this reason: 1. ... 2. When reallocation of extension area occurs we need to fixup the bysource hash head via hlist_replace_rcu. I'd rather not increase the size of the struct nf_conn for this feature has very limited scope: only one expectation can be created at a time given expect_clash() will make nf_ct_expect_related() reports EBUSY. For this reason, relax nf_ct_expect_related() not to drop packets in case expectation creation fails, therefore, expectation creation becomes best effort. To address this issue, add an internal ct helper and attach it to the conntrack entry to streamline the custom ct expectation support with existing ct helpers. Expose a new nf_conntrack_helper_release() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nft_ct module removal always waits for rcu grace period, then the NULL helper callback is observed after this. This patch also restricts the creation of expectations to different helpers other than this custom helper that is created for this type of expectations. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Reported-by: Jaeyeong Lee Link: https://patch.msgid.link/20260715144755.00ea7dfcd9f@proton.me Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1e694ac22ef2ce88c5d751a95213c7f75248d593 Author: Florian Westphal Date: Mon Jun 22 14:50:18 2026 +0200 netfilter: nft_ct: support expectation creation for natted flows [ Upstream commit d4beefc90a66672e43fdf82b43e4b3c0b1b18c5e ] This feature only works for connections originating from the host and only if there no source address rewrite. Add the needed nat glue to have the expectation follow the original nat binding. Signed-off-by: Florian Westphal Stable-dep-of: 3679da4ad8be ("netfilter: nft_ct: move custom expectation support to helper") Signed-off-by: Sasha Levin commit 026f7f91de39b4b463c6c93167c992e81e788651 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 74669cc3483e9729ca26b4e06a096ccdd607db64 Author: Yifei Gao Date: Thu Jul 30 14:14:04 2026 +0000 media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path [ Upstream commit ef46d80a7015269a98c9505b5912a83798799199 ] isp4sd_pwron_and_init() holds ops_mutex via guard(mutex) and, on any init failure, jumps to err_deinit and calls isp4sd_pwroff_and_deinit(). That helper takes the same ops_mutex, re-acquiring a non-recursive mutex already held by the current thread, so any init failure deadlocks. Unwind the error path in stages instead, releasing only what each failure point acquired. This also avoids the issues that an unconditional teardown would hit at the earlier failures, such as a runtime-PM underflow from pm_runtime_resume_and_get() and MMIO access while the device is unpowered. Fixes: 4e5e7a7ddb4a ("media: platform: amd: isp4 subdev and firmware loading handling added") Assisted-by: Claude:claude-opus-4-8 smatch Signed-off-by: Yifei Gao Reviewed-by: Bin Du Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit a1f8750668e552837df781783909f2f680958006 Author: Yifei Gao Date: Thu Jul 30 14:14:03 2026 +0000 media: amd: isp4: release partial allocations in isp4if_alloc_fw_gpumem() [ Upstream commit fea97ee13c5332f67850733d6cefc1fe99460bde ] isp4if_alloc_fw_gpumem() allocates several GPU memory pools in sequence. If one of them fails, it jumps to error_no_memory and returns -ENOMEM without releasing the pools that were already allocated, leaking them. Release the already-allocated pools before returning. isp4if_gpu_mem_free() is a no-op on pools that were not allocated, so calling isp4if_dealloc_fw_gpumem() here safely frees exactly the pools that succeeded. isp4if_gpu_mem_free() previously logged an error for a NULL entry, which is a normal case during partial-allocation cleanup, so make it silent. Fixes: 4c5feef6a62c ("media: platform: amd: Add isp4 fw and hw interface") Signed-off-by: Yifei Gao Reviewed-by: Bin Du Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 8cd13087eb57d6f3e58e437d1652b75da4dbe4b9 Author: Yuho Choi Date: Sun Aug 2 18:22:59 2026 -0400 hwrng: imx-rngc - Disable clock on registration failure [ Upstream commit 188bb9ad86c3b2d527385328a30c1d9510253202 ] The RNGC clock is enabled manually before runtime PM is configured. If devm_hwrng_register() fails, probe returns without disabling the clock. The devm_pm_runtime_enable() cleanup only disables runtime PM and does not call imx_rngc_suspend(). Disable the clock before returning from this failure path. Fixes: 7a96a64e8689 ("hwrng: imx-rngc - add runtime pm") Signed-off-by: Yuho Choi Reviewed-by: Martin Kaiser Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7c7d3e51c2903f91986d338571c79c5854b39e22 Author: Ahsan Atta Date: Fri Jul 31 13:48:32 2026 +0100 crypto: qat - remove dead ADF_HEX code [ Upstream commit 61135c1597af56eb454d53c9d7cda90d5e5dc566 ] The ADF_HEX value type is defined in the adf_cfg_val_type enum and handled in adf_cfg_add_key_value_param(), but no caller in the tree uses it. Remove the unused ADF_HEX enum value and its dead handling code. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Reviewed-by: Giovanni Cabiddu Reviewed-by: Svyatoslav Pankratov Signed-off-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2a3c526c7554cb673bab188475dc1a0484998996 Author: Thorsten Blum Date: Sat Jun 6 01:11:02 2026 +0200 crypto: qat - use 2-arg strscpy where destination size is known [ Upstream commit 4525ac14115d07c3e4c57a8cd5c154916e9d1172 ] To simplify the code, drop explicit and hard-coded size arguments from strscpy() where the destination buffer has a fixed size and strscpy() can automatically determine it using sizeof(). Acked-by: Giovanni Cabiddu Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: 61135c1597af ("crypto: qat - remove dead ADF_HEX code") Signed-off-by: Sasha Levin commit 5baddf100b3be730912485648cbaae5e3a251923 Author: Lu Baolu Date: Wed Aug 5 07:43:13 2026 +0800 iommu/vt-d: Flush context cache with correct SID when tearing down aliases [ Upstream commit c54e4ae971b98e8d650400137d332cee56c03f55 ] domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device’s own RID, the context entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info. Fixes: f90584f4beb84 ("iommu/vt-d: Add helper to flush caches for context change") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit db5daf25f754cdc20c18525adb88240ece6fdee9 Author: Lu Baolu Date: Wed Aug 5 07:43:12 2026 +0800 iommu/vt-d: Tear down scalable-mode context on probe failure [ Upstream commit c509fb73a1093a15accd7d43a61645d4b520f6ac ] intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached. Fixes: 301f1a80487fd ("iommu/vt-d: Setup scalable mode context entry in probe path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 143cd37ce76527ddd6f6dbac4a89bde31fb8b0dc Author: Lu Baolu Date: Wed Aug 5 07:43:11 2026 +0800 iommu/vt-d: Fix iopf_refcount leak on RID domain replacement [ Upstream commit 236dd58fabd2e951b940a6ad88b81147899ed311 ] intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6b822d18c33af9d1e16a8e5e6aa6e656987b09de Author: Lu Baolu Date: Wed Aug 5 07:43:10 2026 +0800 iommu/vt-d: Clear Present bit before tearing down copied context entry [ Upstream commit f532c57985b1a7d6b7e37e05506b46d413e5cca4 ] copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry. Fixes: c7191984e5aad ("iommu/vt-d: Factor out helpers from domain_context_mapping_one()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a45f0b5eaac6b3a1a253b4c10843c573cadb9791 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 2af1e99ec14d226d66ceb9f16c663ee2568e6676 Author: Andrew Jones Date: Thu Jul 30 15:23:23 2026 +0200 iommu/dma: Restore locking around msi_page_list [ Upstream commit 5a9e89ea34e0e34ac5d7e949042d665533549e40 ] Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") dropped the prior msi_prepare_lock on the reasoning that "each iommu_domain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction. Fixes: 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") Signed-off-by: Andrew Jones Reviewed-by: Jason Gunthorpe Reviewed-by: Nutty Liu Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 956265326139374c535469ce16080a2bf9365cf1 Author: Karl Mehltretter Date: Sat Aug 8 16:41:14 2026 +0200 fbdev: clps711x-fb: Remove unreachable unregister_framebuffer() call [ Upstream commit 39dd7598fbe90c5b4bb77fb34d8f3dad8385d11c ] The unregister_framebuffer() call in clps711x_fb_probe() is unreachable. register_framebuffer() failure jumps to the unwind label, while success returns immediately. Remove it. Found with Clang's -Wunreachable-code. Fixes: 36462ac193088 ("fbdev: clps711x-fb: Replace check_fb in favor of struct fb_info.lcd_dev") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Acked-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 7bf36dc23bcf3496dec274a46ae0aaff4961ea03 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 4b2c707bf5b1fe538e657947a289f57b2bd20b6e Author: Myeonghun Pak Date: Wed Jul 1 20:21:47 2026 +0900 fbdev: tdfxfb: fix PCI enable cleanup with pcim_enable_device() [ Upstream commit 95a627143a696f70e17be5ed3b1e733bb6724b46 ] tdfxfb_probe() enables the PCI device with pci_enable_device(), but several failure paths after that point return without disabling it. The framebuffer_alloc() failure path returns -ENOMEM directly, and the later shared out_err path releases the framebuffer and returns -ENXIO without balancing the PCI enable state. The successful probe path has the same imbalance because tdfxfb_remove() releases the framebuffer, mappings and regions, but never calls pci_disable_device(). Use pcim_enable_device() so the PCI device is disabled automatically on probe failure and driver detach. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit ef79a405f83993f0fda5efde371d98433f7d7a47 Author: Fabrice Derepas Date: Sun Aug 9 16:29:45 2026 +0200 apparmor: fix integer overflow in verify_tags() bounds check [ Upstream commit 465946d3c560c0137e6a180ba054dddc4d049f5a ] verify_tags() validates the tagset table unpacked from a policy blob. For each set it reads a count and checks that advancing the index by that count stays inside sets.table[]: u32 cnt = tags->sets.table[i]; if (i+cnt >= tags->sets.size) { i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32. sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so every entry is a raw unbounded 32-bit word taken from the policy blob, and verify_tags() is the function that is supposed to validate it. A count close to U32_MAX makes the sum wrap to a small value, the guard passes, and the inner loop then walks sets.table[++i] past the end of the kcalloc(size, sizeof(u32)) allocation. Note that sets.size is bounded by 65535, because unpack_tagsets() reads it with aa_unpack_array() as a u16, so the wrap cannot be reached by growing the table; it is reached purely through the attacker-supplied count. With sets.size = 2 and sets.table = { 0, 0xffffffff }: i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is false, so the guard is bypassed and the inner loop reads sets.table[2] -- one element past a two element allocation The walk continues until an out-of-bounds value happens to be >= hdrs.size or the access faults, so a crafted policy yields an out-of-bounds read on the policy load path (aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags -> verify_tags). unpack_tags() runs before the perms and DFA tables are unpacked, so no other table needs to be well formed to reach it. Policy load is gated by aa_may_manage_policy(), which checks CAP_MAC_ADMIN relative to the subject's own user namespace rather than the init user namespace, so with the default unprivileged_userns_apparmor_policy=1 the path is reachable from an unprivileged task in a matched-level nested namespace, not only by a globally privileged one. Perform the addition in u64 so that it cannot wrap, restoring the intended i + cnt < sets.size guarantee. Fixes: 3d28e2397af7 ("apparmor: add support loading per permission tagging") Signed-off-by: Fabrice Derepas Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit b518c2468d91ad5e168a97c061a2fdc689b2765c 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 8340726a60aa6b0519a6f102b79bbda502fd5f4a Author: Ian Rogers Date: Sun Aug 9 00:14:53 2026 -0700 perf python: Fix memory leak in pyrf__metrics_cb [ Upstream commit 1ec13016ba36f1bf7dc61e054068fe00f2f628c7 ] In pyrf__metrics_cb, PyDict_SetItem does not steal the reference of the key and value, so they need to be decref'ed after successful insertion to avoid memory leaks. Fixes: 47b3e95728eb ("perf python: Add metrics function") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 31245887b0e0e0456bcb1950deda125446d149c8 Author: Ian Rogers Date: Sun Aug 9 00:14:52 2026 -0700 perf python: Fix count_values memory leak in pyrf_evsel__read [ Upstream commit cb45ede21d02cc85de18ce6b60a51a7449f4179b ] In pyrf_evsel__read, if PyArg_ParseTuple fails, the allocated count_values is leaked. Move the allocation of count_values after the PyArg_ParseTuple call to prevent the memory leak. Fixes: 739621f65702 ("perf python: Add evsel read method") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9cd2a9a5fd744b770b7f43ac18a7d06a8107ca3b Author: Ian Rogers Date: Sun Aug 9 00:14:48 2026 -0700 perf python: Validate attribute setters in pyrf_evsel [ Upstream commit 0b274050c4d427828595c12c2e4e53d98612b4f9 ] If val is NULL when setting an attribute, PyErr_SetString should be called as deleting the attribute isn't supported. In addition, ensure PyErr_Occurred is checked before setting the attribute to avoid setting a garbage value. Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a05972af8e9aaad2f3e2d5a5048c3159352b1d46 Author: Ian Rogers Date: Sun Aug 9 00:14:47 2026 -0700 perf python: Validate CPU and thread maps in pyrf_evsel__open [ Upstream commit 9a142beb1eba42b986dc7016f4fc1a3bc28b8c09 ] Add explicit Py_TYPE checks to ensure the arguments passed are actually of the correct pyrf_thread_map and pyrf_cpu_map types. Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1f8f4e482af32042bbcbc564e2d3bc1b546cd8e1 Author: Ian Rogers Date: Mon Jun 15 18:15:40 2026 -0700 perf python: Handle Py_None for thread and cpu maps [ Upstream commit 054d1c7717b95d9089cd3b80e9e85fe1f2ea0471 ] The python stubs allow passing None for threads and cpus to the perf.parse_events() and perf.parse_metrics() bindings. However, PyArg_ParseTuple parses None into a Py_None object, which is not a NULL pointer. Because the C code lacked an explicit check for Py_None, it would cast Py_None to a pyrf_thread_map/pyrf_cpu_map struct pointer and dereference it, causing a memory corruption crash. Fix this pre-existing issue by explicitly checking for Py_None alongside NULL in pyrf__parse_events, pyrf__parse_metrics, and pyrf_evsel__open. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: 9a142beb1eba ("perf python: Validate CPU and thread maps in pyrf_evsel__open") Signed-off-by: Sasha Levin commit 3d34725649fa646df9c0e9c3ee000ea6ca78db33 Author: Ian Rogers Date: Sun Aug 9 00:14:46 2026 -0700 perf python: Check counts_values size in set_values [ Upstream commit 612aca22a978d43f6e6765272676a17afdba8572 ] The set_values function incorrectly assumed the list contained exactly 5 elements. Add a check to prevent out-of-bounds access. Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 41579b30c2fd76bc97a098695b0b0ed5105b5518 Author: Ian Rogers Date: Sun Aug 9 00:14:45 2026 -0700 perf test: Fix skiplist leak in cmd_test [ Upstream commit 44e82c4d2ff37f073946b594840fd549ab6b9fb8 ] Fix a memory leak in cmd_test() where skiplist was not freed on exit paths. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 2ae828786c65 ("perf test: Allow skipping tests") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7e0cf79cd2f9c777c4ceedc96763b7d9dd2a9537 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 cf34a68e9adaa6a96be9388293e7464ce720461f Author: Ian Rogers Date: Sun Aug 9 00:14:43 2026 -0700 perf python: Fix memory leak in pyrf_evlist__get_pollfd [ Upstream commit 38d778acbee3ee96c14e33863b747e674d975eae ] Fix a Python list object leak in pyrf_evlist__get_pollfd() by adding a missing Py_DECREF on the error exit path. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit fbf8dc5170dae6b15f93a23f650812fdabe17cd9 Author: Ian Rogers Date: Sun Aug 9 00:14:42 2026 -0700 perf tools: Fix sb_evlist leaks in top and record [ Upstream commit 08e96e3c737bf63d917c6c4e0bb67450ad53f1d8 ] Fix a memory leak in cmd_top() where top.sb_evlist was not freed if evlist__add_bpf_sb_event() fails. Note that evlist__start_sb_thread() and evlist__stop_sb_thread() take ownership of the evlist and free it, so we must only free it if we fail before starting the thread. Also set top.sb_evlist to NULL to prevent use-after-free bugs. Apply the same fix to builtin-record.c to avoid leaking rec->sb_evlist and calling pthread_join on uninitialized threads in the error path. Assisted-by: Antigravity:gemini-3.1-pro Fixes: b38d85ef49cf ("perf bpf: Decouple creating the evlist from adding the SB event") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b0756b5be72983f78514ef27c648e9118e1717d0 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 acf06e025eea4516080f4e2e5b15199f4f068030 Author: Ian Rogers Date: Sun Aug 9 00:14:40 2026 -0700 perf script: Fix metric_evlist leak in script_find_metrics [ Upstream commit d4171c774070e9d1c45324e3667d7dcba9be7749 ] Fix a memory leak in script_find_metrics() where metric_evlist is leaked when returning early on error paths. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 3622990efaab ("perf script: Change metric format to use json metrics") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a52414ecdbe6fa849c68f6cf5f89ab9207652480 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 e16bf987061858c0a5e46ed84d80fb1650b991a5 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 8d976901462c1e29136123a65224712d91eb005d 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 393d33d5d54c260eb75ee52b252d23b5a77388f2 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 d1409d203251fe9657c9247afeaec1b53827e4d2 Author: Tommaso Merciai Date: Fri Jul 31 09:01:46 2026 +0200 i3c: renesas: Don't register devices when ENTDAA times out [ Upstream commit b6e56fd8c8a8ac7992868a28702192372ab04015 ] renesas_i3c_daa() derives the number of newly assigned dynamic addresses from cmd->rx_count, which the response ISR sets to the number of address slots ENTDAA left unassigned. It starts out as zero, which already means "every address was assigned", so a timed out transfer leaves that value in place and it gets used as a result. On a bus with no target connected the ENTDAA times out and the driver registers RENESAS_I3C_MAX_DEVS devices that are not there, each costing the core two seconds on a GETPID that can only time out: i3c i3c-0: Failed to add I3C device at address 9, error -110 ... i3c i3c-0: Failed to add I3C device at address 16, error -110 Start from maxdevs instead: no address is assigned before ENTDAA runs, and the existing rx_count >= maxdevs check then reports an empty bus. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Signed-off-by: Tommaso Merciai Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea # on RZ/G3S Reviewed-by: Frank Li Link: https://patch.msgid.link/20260731070150.2519825-1-tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 869ecb1312921476cfdf12613fb59edd2a8841fd Author: Claudiu Beznea Date: Mon Jul 13 16:05:39 2026 +0300 i3c: renesas: Follow a unified pattern for transfer and command initialization [ Upstream commit 234a26e6febcf789d9f6779d67c01e3d0c1df5bc ] Follow a unified pattern for transfer and command initialization across the driver. This keeps the code cleaner and easier to follow. Also, in some cases the I3C device was enabled before the transfer data structure was even allocated. Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-12-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Stable-dep-of: b6e56fd8c8a8 ("i3c: renesas: Don't register devices when ENTDAA times out") Signed-off-by: Sasha Levin commit 739eb8ac160db36d5dd47f36af5e583f1e122d17 Author: Claudiu Beznea Date: Mon Jul 13 16:05:38 2026 +0300 i3c: renesas: Return immediately if there is no transfer [ Upstream commit 33b5ecc5a16e270c8e0dd9835e7d9d2522f64129 ] There is no need to allocate a transfer structure when i2c_nxfers is zero. Return immediately instead of unnecessarily allocating memory. Signed-off-by: Claudiu Beznea Reviewed-by: Frank Li Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-11-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Stable-dep-of: b6e56fd8c8a8 ("i3c: renesas: Don't register devices when ENTDAA times out") Signed-off-by: Sasha Levin commit 051f2da26ce377f683b938a3382e0f16d02f3139 Author: Sanghyun Park Date: Wed Aug 5 12:14:25 2026 +0900 bpf: Fix mmap_lock leak in irq_work path [ Upstream commit fa9dcacdcdf487f0ffef64bf67622f1caed509f1 ] stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap(). Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm. Fixes: eac9153f2b58 ("bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()") Reported-by: syzbot+cdd6c0925e12b0af60cc@syzkaller.appspotmail.com Reported-by: sashiko-bot@kernel.org Signed-off-by: Sanghyun Park Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Closes: https://syzkaller.appspot.com/bug?extid=cdd6c0925e12b0af60cc Closes: https://lore.kernel.org/r/20260630033745.B80201F000E9@smtp.kernel.org Link: https://lore.kernel.org/bpf/20260805031425.2157475-2-sanghyun.park.cnu@gmail.com Signed-off-by: Sasha Levin commit 3f45d8358e01fb5fda7991a0f0d9a5c6c1f9643e Author: Guodong Xu Date: Fri Aug 7 19:24:33 2026 -0600 riscv: cpufeature: Clarify ISA spec version for canonical order [ Upstream commit fdef048705daa3d4ed1fa212ee071bcbdac02d80 ] Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Conor Dooley Link: https://riscv.org/specifications/ratified/ [1] Fixes: 99e2266f2460 ("RISC-V: clarify ISA string ordering rules in cpu.c") Signed-off-by: Guodong Xu Link: https://patch.msgid.link/20260125-supm-ext-id-v2-3-1e3b9714c860@riscstar.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit dc8b33b819cb02a75936940c120aa669ad89942d Author: Victor Nogueira Date: Wed Aug 5 10:40:49 2026 -0300 net/sched: cls_api: fix teardown of an adopted proto on insert-race loss [ Upstream commit d4e359b3608a0e184bbe8d61a5c3b50d0831c44a ] In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reported-by: TencentOS Corvus AI Tested-by: Aohan Mei Link: https://patch.msgid.link/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ffd3e983069b033b98e9d6c4d88c5c5745d9b9d 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 470edb012b1d9a4fba1cd59e329e60f0798c791a 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 38c077c815901f01bbaf81f9725966fcfd8c12b5 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:43 2026 +0530 iio: light: opt4060: Fix pointer type passed to div_u64_rem() [ Upstream commit 0ba0ed0d42ebd3144f0050c48374817f5f3f07d6 ] div_u64_rem() expects a u32 * for the remainder, but opt4060_read_ev_period() passes val2, which is declared as an int *. While this has no functional impact, it triggers a pointer type mismatch. There is no behavioural change because int and u32 have the same size and representation on all supported architectures, and the remainder is always less than MICRO, so it fits within the positive range of int. Use a local u32 to receive the remainder before assigning it to *val2. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 12feca126831556dc7fabe5a3ba28fbd328768b6 Author: Pu Lehui Date: Fri Aug 7 10:44:03 2026 +0000 bpf, cgroup: Fix storage null-ptr-deref after replacing prog [ Upstream commit 3f562c537e9ecf4bc5e206cfffc2cc047f1b7e94 ] Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Amery Hung Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [1] Link: https://lore.kernel.org/bpf/20260807104403.1013064-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit bf8f635531232acd02f230e573709d71465aedbc Author: Alvin Šipraga Date: Mon Jul 27 14:20:08 2026 +0200 pinctrl: fix PINCTRL_GENERIC_MUX not always being selectable [ Upstream commit 465f276bb928093685c2a2b98bf0a7ccc4283b8d ] CONFIG_MULTIPLEXER can only be enabled indirectly. If it's not already enabled, then CONFIG_PINCTRL_GENERIC_MUX cannot be selected at all in menuconfig. That's because it depends on MULTIPLEXER. Follow similar consumers of the multiplexer core and select MULTIPLEXER instead. This way the driver will be visible in menuconfig as long as PINCTRL is selected. Fixes: 34acc5a8adfb ("pinctrl: add generic board-level pinctrl driver using mux framework") Signed-off-by: Alvin Šipraga Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 63562cfaea8a650fdb31ee8de21c32e3600be642 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 22624d43fd7373b7ae857ccd82e70b394d147c70 Author: Guangshuo Li Date: Fri Aug 7 23:14:47 2026 +0800 Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negative [ Upstream commit b0c0b37940115383e7ea65d4d988f9b9e613ab92 ] btmtksdio_setup() calls pm_runtime_use_autosuspend() when runtime PM is supported, but btmtksdio_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 driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call in the remove path before restoring the runtime PM usage reference. This issue was found by manual code inspection. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 481533b03985177ddc805e0bd12fc07e7adf9040 Author: Linmao Li Date: Thu Aug 6 20:59:57 2026 +0800 Bluetooth: MGMT: free the HCI command when it is cancelled [ Upstream commit 414b365ecea6c30357adee6b8a7c5edc03a03575 ] mgmt_hci_cmd_sync() queues the pending command with a NULL destroy callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. The now-empty done label is replaced by a direct return. Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fa46d428c014e7b72a18634679815670418e67dc Author: Linmao Li Date: Thu Aug 6 20:59:56 2026 +0800 Bluetooth: MGMT: free the mesh send cancel command when it is cancelled [ Upstream commit 3c742feda8fcabf741a17bcf668b63c8f606f9c5 ] mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bb5ca1cc7744c41c59002bd6523714a685ae6595 Author: Linmao Li Date: Thu Aug 6 20:59:55 2026 +0800 Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths [ Upstream commit 120d8dc042e3d45073bb6e50ee7b058a0b182627 ] adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all. Fixes: c249ea9b4309 ("Bluetooth: Move Adv Instance timer to hci_sync") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4d7b1c834d2775b73c65e4888e01f5af8b477fe9 Author: Linmao Li Date: Thu Aug 6 20:59:54 2026 +0800 Bluetooth: hci_conn: fix the SCO setup context lifetime [ Upstream commit 42de40abe25db9211107af8896d0fd741f10648d ] hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f2b586d65f90cc7df96e7a3a0079ae55b7d349dc Author: Zijun Hu Date: Sat Aug 1 23:31:36 2026 -0700 Bluetooth: btintel: Fix diagnostics event detection [ Upstream commit ad0e7ac7da9a9a0095570bd6add3e27f259de104 ] For a diagnostics VSE, diagnostics_hdr[] sits at the start of the event payload, skb->data[2], but btintel_recv_event() wrongly guards its memcmp with @len, which is measured from skb->data[3] for the earlier INTEL_BOOTLOADER check. Fix by using (@len + 1) instead, which == (skb->len - HCI_EVENT_HDR_SIZE) exactly. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b495a3a9b33bc4e4613e685bf5c96c136caa22d8 Author: Pauli Virtanen Date: Sat Aug 1 21:37:23 2026 +0300 Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind [ Upstream commit 2b66c83ff1751d6bd3201b3017206262ab46dc05 ] hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths. Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Reported-by: syzbot+9c40ad7c6ed7165e46e8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c40ad7c6ed7165e46e8 Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 84ea9c99874804f5ca13f35bbc186ba93902f30f Author: HyeongJun An Date: Thu Jul 30 10:57:28 2026 +0900 Bluetooth: virtio_bt: avoid OOB read of build info string [ Upstream commit 502adc06ba76dee19c292ae4a07d74d202fe734d ] The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded "%.*s" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 ("Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()"), which fixed the identical pattern. Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1499d5e7e2cf1aca2e3ece4fd6d535cedf9e9c9e Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:59 2026 +0300 pinctrl: airoha: fix edge-triggered interrupts handling [ Upstream commit 3de4686cdf0ccf6d78ca96ccaea621cbcf69fc3a ] Edge-triggered interrupts are handled incorrectly because of * no irq_ack() handler was defined, * no handle_level_irq() handler was used, This patch probably fixes an issue Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit afd4d7aabb01c6e97320f8cd7a118a505fdabb68 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:58 2026 +0300 pinctrl: airoha: fix IRQ mask/unmask code [ Upstream commit 20b996280640f492ebdd41c2d2c991801df75e61 ] When using IRQCHIP_IMMUTABLE, airoha_irq_unmask() must manually call gpiochip_enable_irq() and airoha_irq_mask() must call gpiochip_disable_irq(). Without these calls, gpiolib never sets the GPIOD_FLAG_IRQ_IS_ENABLED bit. Because this bit is missing, gpiod_direction_output() will not realize the pin is actively used as an interrupt. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2c968c11592b478af4fbcb9453a0e1ac664c2e90 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:57 2026 +0300 pinctrl: airoha: add missed IRQ resource helpers [ Upstream commit a02fa031b9520e46e98bff17e12b472eba770670 ] Without hooking .irq_request_resources, gpiolib cannot set GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow userspace or another driver to reconfigure an active IRQ pin as an output Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit eb2587a252784f412a3c0a8c5de5ff337d097071 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:56 2026 +0300 pinctrl: airoha: fix getting gpiochip/pinctrl pointers in the IRQ handling code [ Upstream commit b8dd30554847bde27e8a4584dd447c1c3ac585ce ] airoha_irq_unmask(), airoha_irq_mask(), airoha_irq_type() functions impements brain damaged logic to retrieve gpiochip and pinctrl pointers. Details: gpiochip = irq_data_get_irq_chip_data(data); will initialize gpiochip variable with data->chip_data value. This value initialized inside gpiochip_irq_map() function static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hwirq) { struct gpio_chip *gc = d->host_data; ... irq_set_chip_data(irq, gc); ... } Thus gpiochip variable of 'struct airoha_pinctrl_gpiochip *' type will be initialized with a pointer to a variable of 'struct gpio_chip' type. Luckily, gpio_chip is the first element of airoha_pinctrl_gpiochip, so gpiochip pointer will get a correct value. This patch implements correct logic of getting gpiochip and pinctrl pointers. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f385f3d3248f087beab31e36f97ba1e78d218fbb Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:53 2026 +0300 pinctrl: airoha: add missed get_direction() function for gpio_chip [ Upstream commit d6392502a9e6b11c3a93eb4c987672a8c638d749 ] This patch adds missed get_direction() function for gpio_chip. Also it reimplements pinconf's get_direction() function using newly defined function. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 10e890b305e618bdb1ae94e389636dcbbd95ae02 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:52 2026 +0300 pinctrl: airoha: an7583: fix spi group pins [ Upstream commit ccc41d25590645096bdbf420b43e7c22627b3f59 ] pcm pins were used insted of spi pins. This patch fixes an issue. Thanks to Daniel Schwierzeck for noticing it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 458b07ec42819f7f9c1d1a6fe66004e68f5e9803 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:47 2026 +0300 pinctrl: airoha: an7583: fix muxing of non-gpio default pins [ Upstream commit aaa41d8010c04635e035a9d334885b07edc8af21 ] Current an7583 pinmux implementation have following issues: * pins 51 and 52 can't be set as pcie_reset, current pcie_reset code will sets pins to gpio mode instead. * there is no proper way to set pins 41--54 to gpio mode. * pins 41--53 can't be actually set as pwm pins. These pins must be muxed to gpio mode as well. This patch fixes above issues. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3fe11ae08e8cd2bf21073281f8d3524e2a588656 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:45 2026 +0300 pinctrl: airoha: an7581: fix mux/conf of pcie_reset pins [ Upstream commit 739bc85aed14b739dca5b7aff4241b778af80220 ] In the an7581 case * gpio47 and pcie_reset0 shares pin 60, * gpio48 and pcie_reset1 shares pin 61, * gpio49 and pcie_reset2 shares pin 62. but current driver treat them as pins 61--63. This is wrong. Also current an7581 pinmux implementation have following issues: * current pcie_reset pin function actually sets corresponding pins as gpios. * there is no proper way to set pcie_reset pins as gpios. * there is no way to set pcie_reset pins as pwm. This patch fixes above issues. WARNING: There is a contradiction in the Airoha documentation. AN7581 programming guide claims: - gpio44 and pcie_reset0 shares the same pin - gpio45 and pcie_reset1 shares the same pin - gpio46 and pcie_reset2 shares the same pin While AN7581 datasheet claims: - gpio47 and pcie_reset0 shares the same pin - gpio48 and pcie_reset1 shares the same pin - gpio49 and pcie_reset2 shares the same pin The datasheet should be considered as a more reliable source. Thanks to Benjamin Larsson for clarification. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ce7710c1151d7a7f9b1ad30bf605f30fb1b98d95 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:43 2026 +0300 pinctrl: airoha: an7583: fix I2C0_SDA_PD register bit order [ Upstream commit d560e28bdca824781898023496658404df01be9f ] I2C1_SCL_PD and RG_I2C1_SDA_PD bits are swapped, fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 229b61b5b20983a1a9561427f824dd2bfff1e34d Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:42 2026 +0300 pinctrl: airoha: an7581: fix pinconf of i2c_scl/i2c_sda pins [ Upstream commit 65ce9d5d781f872596194771d62ad6e1260fcf4f ] Pinconfs of i2c_sda/i2c_scl pins are swapped, this needs to be fixed. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit dec9a98b444f44805d8d16d8a1223dbbd9fe79d8 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:41 2026 +0300 pinctrl: airoha: fix mdio bitfield names [ Upstream commit a8454680a6ce75fbbd8086bcb654eacf7897bc0f ] Fix misprint in mdio bitfield name of GPIO_2ND_I2C_MODE register. While at it also fix an7583 mdio. It should use an7583 specific mdio bitfield. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 64c6f46708f1712f8428118806d76e9b74b1a042 Author: Aaron Tomlin Date: Thu Aug 6 11:39:24 2026 -0400 perf sched: Handle missing trace samples in pipe mode [ Upstream commit 44f8dd1ee1d55db399a443e1715cd8cdd3268362 ] For pipe mode streams, event attributes are received dynamically during event processing, meaning session->evlist is not populated prior to perf_session__process_events(). To handle pipe input correctly: - Register the missing .attr, .tracing_data, .build_id, and .feature callbacks in cmd_sched() - Promote the handlers array to file-scope (latency_handlers[]) and dynamically assign matching tracepoint handlers (or process_sched_ignore) inside perf_sched__process_tracepoint_sample() when evsel->handler is NULL; replace process_sched_wakeup_ignore() with process_sched_ignore() - Perform the trace check post-processing when handling pipe data Fixes: 27295592c22e ("perf session: Share the common trace sample_check routine as perf_session__has_traces") Reviewed-by: Ian Rogers Signed-off-by: Aaron Tomlin Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 01bcff12413680627e2b1a2cb00e66b121975383 Author: Aaron Tomlin Date: Thu Aug 6 11:39:23 2026 -0400 perf sched: Suppress latency table output when trace samples are missing [ Upstream commit 4a81d59a9d81e6db4e76f84a3d2638e64ff79533 ] When 'perf sched latency' is executed on a perf.data file that lacks tracepoint samples (i.e., a file recorded without the -R flag or containing only non-tracepoint events), perf_session__has_traces() correctly outputs an error message. However, perf_sched__read_events() subsequently falls through and returns 0 (success). Consequently, caller functions such as perf_sched__lat() assume event processing succeeded and proceed to render empty latency header tables and total summary statistics. Fix this behaviour by ensuring perf_sched__read_events() aborts early and returns a suitable error code when perf_session__has_traces() evaluates to false. Additionally, validate thread__get_runtime() against NULL in map_switch_event() to prevent potential null-pointer dereferences. Fixes: 27295592c22e ("perf session: Share the common trace sample_check routine as perf_session__has_traces") Reviewed-by: Ian Rogers Signed-off-by: Aaron Tomlin Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c4c136555ff90f1e2921cc42da43daac0ef9985e Author: Qu Wenruo Date: Tue Jul 28 12:09:26 2026 +0930 btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() [ Upstream commit 9102b179512e11644fb0489ae62010a09afa199c ] In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use "round_up(start + len, sectorsize)", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using "start + len", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead. Fixes: bc42bda22345 ("btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 91ed75a0a0cb09959571a285098fa5279a0eba21 Author: Qu Wenruo Date: Tue Jul 28 19:34:09 2026 +0930 btrfs: use aligned range for locking in extent_fiemap() [ Upstream commit 681e073614515b892cacef0eeec0c761a2c2ab87 ] The @end parameter for all extent io tree helpers is inclusive, but the call site in extent_fiemap() is passing an exclusive end into btrfs_lock_extent(), which will step into the next block unexpectedly. Pass the inclusive end into btrfs_lock_extent() and btrfs_unlock_extent(). Fixes: ac3c0d36a2a2 ("btrfs: make fiemap more efficient and accurate reporting extent sharedness") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 98e3747587f9f87f010d8d7e55786216249a94af Author: Johannes Thumshirn Date: Thu Jul 23 17:54:28 2026 +0200 btrfs: zoned: don't clobber the extent buffer when zeroing it out [ Upstream commit db4b9eefc8ee0bcaeee4d5e6a7313905f6a2fe7c ] On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an "unable to find ref" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them. Fixes: aa6313e6ff2b ("btrfs: zoned: don't clear dirty flag of extent buffer") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e2de2989adb3e58c2320e57c255f52e065667b5e Author: Johannes Thumshirn Date: Thu Jul 23 17:54:25 2026 +0200 btrfs: zoned: flush active metadata block group at btree_writepages() start [ Upstream commit ecc05eda9a346848ae01a6c8bfa3f0bec133bd8b ] btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 81241f734f0f662378f5ffc53882b012923e6fe5 Author: Yichong Chen Date: Wed Jul 22 10:54:35 2026 +0800 btrfs: retry verity reads for not-uptodate Merkle folios [ Upstream commit 8cc569696dac51fc62bb39b3b8f530582b916d29 ] btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read. Fixes: 06ed09351b67 ("btrfs: convert btrfs_read_merkle_tree_page() to use a folio") Reviewed-by: Boris Burkov Signed-off-by: Yichong Chen Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e6045f6e8d869966c47aec49696d8fe416b9bbfa Author: Leo Martins Date: Wed Jul 1 16:47:10 2026 -0700 btrfs: replace writeback inhibition xarray with a fixed inline buffer [ Upstream commit 67bd829a14b7d71ffea28147b98dadf9ee684568 ] Commit f9a48549a15a ("btrfs: inhibit extent buffer writeback to prevent COW amplification") tracks the extent buffers a transaction handle has inhibited in a per-handle xarray. Keying the tracking to the transaction handle is correct, but using an xarray for it causes two problems in production. First, a write_iops regression. Every COW calls btrfs_inhibit_eb_writeback() from btrfs_force_cow_block() and should_cow_block(), which does an xa_store() keyed by eb->start. The kernel test robot reported a 22.6% fio.write_iops regression on a single-task 4k randwrite workload (ftruncate ioengine, buffered IO) on btrfs. The cost is the per-COW xarray store done on every COW'd block. Replacing it with a non-allocating fixed buffer recovers the lost throughput, and that buffer does more per-COW bookkeeping yet still recovers, so the cost is the xarray operation itself rather than the extra tracking work. Second, an unbounded cleanup walk. btrfs_uninhibit_all_eb_writeback() iterates every eb the handle inhibited with xa_for_each(). A single handle that COWs a very large number of blocks (inode eviction, or truncate of a file with many extents, where btrfs_truncate_inode_items() loops over many search_again descents under one handle) makes that walk arbitrarily long. It runs in __btrfs_end_transaction() before num_writers is dropped, so it blocks the committing thread; this shows up as multi-second stalls and RCU stall reports. Replace the xarray with a fixed inline array on btrfs_trans_handle, managed with a CLOCK (second-chance) eviction policy. Inhibiting a buffer becomes an array append with no allocation and no tree walk, and the end-of-handle cleanup is bounded by the array size. The set that actually needs protection is the working set the handle revisits across search_again descents, the search path frontier, which is on the order of the tree height. It is not every block the handle ever COWs. should_cow_block() re-inhibiting an already tracked buffer marks it referenced, so revisited buffers survive eviction while write-once buffers are reclaimed first. A small fixed buffer is therefore enough where a non-evicting array would either overflow or have to grow without bound. BTRFS_INHIBITED_EBS_SLOTS is 8 and the reference bits pack into a u32. The CLOCK eviction is what justifies the extra complexity over a plain non-evicting array. The test workload stresses amplification: it removes 16 heavily fragmented 64 MiB files in one transaction while background writeback keeps writing out in-use metadata. A re-COW event is a buffer already COWed in the running transaction that was written back and then COWed again; the figure below is the ratio of re-COW events to first-COW events summed across the eviction (n=5, lower is better): tracking re-COW per first-COW no inhibition 6.1 non-evicting array, 32 slots 3.8 CLOCK array, 8 slots (this patch) 1.6 unbounded xarray (reverted) 1.4 The non-evicting array fills with write-once buffers and stops covering the buffers the handle keeps revisiting, so even at four times the slots it leaves most of the amplification. CLOCK evicts the cold buffers and keeps the revisited ones, recovering almost all of the unbounded benefit. The eviction policy, not the buffer size, is what closes the gap. eb->writeback_inhibitors and the WB_SYNC_ALL bypass in lock_extent_buffer_for_io() are unchanged, so fsync and commit behavior are unaffected. A reference is taken on each tracked buffer so it cannot be freed while the array points at it; eviction drops that reference and the inhibitor count. There's another testing report, showing 20% latency improvement on reflink and deduplication synthetic benchmark. Full detailed report at https://github.com/lcf0399/linux-regression-evidence/tree/main/btrfs-remap-writeback-inhibition-v2 . Link: https://lore.kernel.org/all/CANGjgd=fQkHht2PdDi-+EAdzWH7UtxxWhhJ7b80Rr17PbpgxOw@mail.gmail.com/ Reported-by: kernel test robot Fixes: f9a48549a15a ("btrfs: inhibit extent buffer writeback to prevent COW amplification") Closes: https://lore.kernel.org/oe-lkp/202603112240.f7605968-lkp@intel.com Tested-by: Chengfeng Lin Reviewed-by: Filipe Manana Reviewed-by: Sun YangKai Signed-off-by: Leo Martins Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d5602f96ff1e266f069b4d0d94f441050e057e06 Author: Sun YangKai Date: Thu Jul 9 16:23:35 2026 +0800 btrfs: check if root is readonly when setting posix acl [ Upstream commit 01c2f41fc441f75b3f9326443372faceb1cb6638 ] For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true. This happens because no function on the set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 ("btrfs: check if root is readonly while setting security xattr"). Always check if the root is read-only before performing the set acl operation. Fixes: 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") Reviewed-by: Johannes Thumshirn Reviewed-by: Filipe Manana Signed-off-by: Sun YangKai Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2073f3d97b0c5d34fe64812d1237e37bd79c17ec Author: Qu Wenruo Date: Sat Jun 20 14:37:02 2026 +0930 btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock [ Upstream commit 690c2accacb1aca91ab8186d15dee56da8723f31 ] [FALSE ALERTS] There is a bug report that the warning inside invalidate_and_check_btree_folios() got triggered during btrfs/298: BTRFS info (device sdd): first mount of filesystem f9bf732a-a19b-44b9-99a7-614ddff168e2 BTRFS info (device sdd): using crc32c checksum algorithm BTRFS error (device sdd): failed to find fsid cb2fdb42-b638-4f2f-badd-4127467ba674 when attempting to open seed devices BTRFS error (device sdd): failed to read chunk tree: -2 ------------[ cut here ]------------ WARNING: disk-io.c:3342 at invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs], CPU#4: mount/125993 CPU: 4 UID: 0 PID: 125993 Comm: mount Tainted: G W OE 7.1.0-rc7-custom+ #1 PREEMPT(full) Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 Call trace: invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs] (P) open_ctree+0x1f50/0x23b0 [btrfs] btrfs_get_tree+0x89c/0xc48 [btrfs] vfs_get_tree+0x30/0x110 vfs_cmd_create+0x58/0xe8 __arm64_sys_fsconfig+0x39c/0x518 invoke_syscall.constprop.0+0x48/0x120 el0_svc_common.constprop.0+0x40/0xe8 do_el0_svc+0x24/0x38 el0_svc+0x50/0x310 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 ---[ end trace 0000000000000000 ]--- BTRFS warning (device sdd): unable to release extent buffer 365985792 owner 3 gen 17 refs 3 flags 0x5 [CAUSE] In that invalidate_and_check_btree_folios() we wait for the eb to finish its read, then check if it's only held by us and the btree inode. If not, then do a warning as it may be still held, and could cause problems. But there is a small window where the check can lead to false alerts: Thread A (Read endio) | Thread B (Unmount) ----------------------------------+------------------------------------- end_bbio_meta_read() | | The eb has one extra ref held | | by the reader, and has | | EXTENT_BUFFER_READING flag set | invalidate_and_check_btree_folios() | | | |- clear_extent_buffer_reading() | | | | |- wait_on_bit_io(); | | | The EXTENT_BUFFER_READING flag is | | | cleared | | |- if (refcount_read(eb->refs) > 2) | | The eb is held by the read, us | | and btree inode, thus it | | will trigger the warning |- free_extent_buffer() | [FIX] Introduce a helper, free_extent_buffer_clear_reading(). If the new parameter, @clear_reading, is set, we will hold the spinlock at the beginning of free_extent_buffer_clear_reading() to make sure the EXTENT_BUFFER_READING flag is cleared inside the same critical section of decreasing refs. Now free_extent_buffer() will just call free_extent_buffer_clear_reading() with @clear_reading set to false, so no behavior change. But for end_bbio_meta_read(), it will not clear_extent_buffer_reading() directly, but pass @clear_reading as true. Then inside invalidate_and_check_btree_folios(), hold the refs_lock before reading refs. So that we eliminate the race window completely. Reported-by: Su Yue Link: https://lore.kernel.org/linux-btrfs/DC0C775E-13B3-47D9-9AB2-895BB11C029D@suse.com/ Fixes: 83f7e52b7ed1 ("btrfs: warn about extent buffer that can not be released") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit aaac9b352f7f53f5d2f7e58e612d67d2a2bf7094 Author: Qu Wenruo Date: Sat Jun 27 09:02:21 2026 +0930 btrfs: always wait for ordered extents to avoid OE races [ Upstream commit ec78575dde998c21be7e0cb2503b5620f34b6255 ] [BUG] Syzbot reported a bug that there can be conflicting OEs for the same range: BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- [CAUSE] Since commit ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes"), if the direct IO finished short, we will revert the isize back to the original one, so that append writes can be respected during the buffered fallback. Normally we rely on lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered extents. But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have reverted the isize during failed direct IO, we will not wait for any ordered extents. This means we can have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're inserting the OE for the buffered write, causing the above crash. [FIX] Make the OE wait to be unconditional, to handle the reverted isize situation. And since lock_and_cleanup_extent_if_need() now either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases, and rename it to remove the "_if_need" suffix. The following micro benchmark shows the runtime difference for btrfs_buffered_write(), doing `xfs_io -f -c "pwrite 0 1m"` workload, all values are the average runtime in nano seconds. function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 The overall runtime of btrfs_buffered_write() is still pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable. An alternative to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done. But that solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the OEs unconditionally or the next append buffered IO can still hit the same problem. So here we have to move the wait cost to buffered write, but at least the code is slightly more streamline. Reported-by: syzbot+ba2afde329fc27e3f22e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=ba2afde329fc27e3f22e Fixes: ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ac916391e1c70801649f7d6f85014f687983bc33 Author: Filipe Manana Date: Tue Jun 23 16:56:15 2026 +0100 btrfs: defrag: fix deadlock between defrag and delalloc space reservation [ Upstream commit ba02eab28041f9a4bbe9fc90c7249644fef6de0f ] While running fsstress with autodefrag and flushoncommit, hit a deadlock due to the fact that defrag reserves delalloc space while it's holding dirty and locked folios, besides the extent range lock. The stack traces are the following: [958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [958.627] Call Trace: [958.628] [958.628] __schedule+0x4be/0x10f0 [958.629] ? preempt_count_add+0x69/0xa0 [958.630] schedule+0x26/0xd0 [958.631] wait_current_trans+0x102/0x160 [btrfs] [958.632] ? __pfx_autoremove_wake_function+0x10/0x10 [958.633] start_transaction+0x374/0x900 [btrfs] [958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs] [958.635] flush_space+0xca/0x5e0 [btrfs] [958.636] ? _raw_spin_unlock+0x15/0x30 [958.637] ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs] [958.639] ? _raw_spin_unlock+0x15/0x30 [958.640] ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs] [958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs] [958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs] [958.644] process_one_work+0x19d/0x3a0 [958.644] worker_thread+0x1c4/0x330 [958.645] ? __pfx_worker_thread+0x10/0x10 [958.646] kthread+0xfc/0x130 [958.647] ? __pfx_kthread+0x10/0x10 [958.648] ret_from_fork+0x1f7/0x2c0 [958.648] ? __pfx_kthread+0x10/0x10 [958.649] ret_from_fork_asm+0x1a/0x30 [958.650] [958.651] task:kworker/u49:7 state:D stack:0 pid:52990 tgid:52990 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.653] Workqueue: writeback wb_workfn (flush-btrfs-334) [958.655] Call Trace: [958.655] [958.656] __schedule+0x4be/0x10f0 [958.657] ? __blk_flush_plug+0xe9/0x140 [958.658] schedule+0x26/0xd0 [958.658] io_schedule+0x42/0x70 [958.659] folio_wait_bit_common+0x12b/0x330 [958.660] ? folio_wait_bit_common+0x100/0x330 [958.662] ? __pfx_wake_page_function+0x10/0x10 [958.663] extent_write_cache_pages+0x599/0x830 [btrfs] [958.664] ? acpi_fwnode_get_reference_args+0x1fa/0x270 [958.665] btrfs_writepages+0x77/0x130 [btrfs] [958.666] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] [958.667] do_writepages+0xc6/0x160 [958.668] __writeback_single_inode+0x42/0x310 [958.669] writeback_sb_inodes+0x231/0x570 [958.670] wb_writeback+0x8a/0x340 [958.671] wb_workfn+0xbf/0x450 [958.672] ? finish_task_switch.isra.0+0xc1/0x350 [958.673] process_one_work+0x19d/0x3a0 [958.673] worker_thread+0x1c4/0x330 [958.674] ? __pfx_worker_thread+0x10/0x10 [958.675] kthread+0xfc/0x130 [958.676] ? __pfx_kthread+0x10/0x10 [958.676] ret_from_fork+0x1f7/0x2c0 [958.677] ? __pfx_kthread+0x10/0x10 [958.678] ret_from_fork_asm+0x1a/0x30 [958.679] [958.679] task:btrfs-cleaner state:D stack:0 pid:296750 tgid:296750 ppid:2 task_flags:0x208040 flags:0x00080000 [958.681] Call Trace: [958.682] [958.682] __schedule+0x4be/0x10f0 [958.683] schedule+0x26/0xd0 [958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs] [958.685] ? __pfx_autoremove_wake_function+0x10/0x10 [958.686] reserve_bytes+0x283/0x4c0 [btrfs] [958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs] [958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs] [958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs] [958.691] btrfs_defrag_file+0x903/0x1110 [btrfs] [958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs] [958.694] cleaner_kthread+0x97/0x1c0 [btrfs] [958.694] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] [958.696] kthread+0xfc/0x130 [958.696] ? __pfx_kthread+0x10/0x10 [958.697] ret_from_fork+0x1f7/0x2c0 [958.698] ? __pfx_kthread+0x10/0x10 [958.699] ret_from_fork_asm+0x1a/0x30 [958.700] [958.716] task:fsstress state:D stack:0 pid:296769 tgid:296769 ppid:296768 task_flags:0x400140 flags:0x00080000 [958.718] Call Trace: [958.719] [958.719] __schedule+0x4be/0x10f0 [958.720] ? preempt_count_add+0x69/0xa0 [958.721] schedule+0x26/0xd0 [958.722] wb_wait_for_completion+0x79/0xc0 [958.723] ? __pfx_autoremove_wake_function+0x10/0x10 [958.724] __writeback_inodes_sb_nr+0xc5/0xf0 [958.725] try_to_writeback_inodes_sb+0x55/0x70 [958.726] btrfs_commit_transaction+0x19d/0xeb0 [btrfs] [958.727] ? start_transaction+0x343/0x900 [btrfs] [958.728] btrfs_mksubvol+0x28b/0x4e0 [btrfs] [958.729] btrfs_mksnapshot+0x74/0xa0 [btrfs] [958.730] __btrfs_ioctl_snap_create+0x194/0x210 [btrfs] [958.732] btrfs_ioctl_snap_create_v2+0xef/0x150 [btrfs] [958.733] btrfs_ioctl+0x7ec/0x2a70 [btrfs] [958.734] ? __virt_addr_valid+0xe4/0x180 [958.735] ? __check_object_size+0x1cd/0x1f0 [958.736] ? kmem_cache_free+0x146/0x380 [958.737] ? _raw_spin_unlock+0x15/0x30 [958.738] ? do_sys_openat2+0x83/0xd0 [958.739] __x64_sys_ioctl+0x92/0xe0 [958.740] do_syscall_64+0x60/0x590 [958.741] ? clear_bhb_loop+0x60/0xb0 [958.742] entry_SYSCALL_64_after_hwframe+0x76/0x7e [958.743] RIP: 0033:0x7f4431e108db [958.744] RSP: 002b:00007ffcd147db20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [958.746] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f4431e108db [958.747] RDX: 00007ffcd147eb90 RSI: 0000000050009417 RDI: 0000000000000005 [958.749] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [958.751] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcd147fbf0 [958.752] R13: 00007ffcd147eb90 R14: 0000000000000005 R15: 0000000000000003 [958.754] What happens is the following: 1) The cleaner kthread is running autodefrag, and in defrag_one_range() it acquired all the folios for the range and locked them. Then it locked the extent range in the inode's iotree. It got two subranges from defrag_collect_targets(), the first one with folio A and the second one with folio B. After it defragged the first subrange, folio A remains locked and dirty - it's only unlocked when defrag_one_range() returns. When it attempts to defrag the second subrange (containing folio B), btrfs_delalloc_reserve_space() creates a space reservation ticket, due to lack of free metadata space and blocks waiting for the async metadata reclaim task to free space and wake it up; 2) The async reclaim metadata task attempts to commit the current transaction, but it blocks because there is another task that started the commit first; 3) A task creating a snapshot is committing the transaction and because the fs was mounted with flushoncommit, it calls try_to_writeback_inodes_sb(), which spawns a task to flush delalloc and waits for it to complete; 4) The task flushing delalloc (kworker/u49:7), finds that folio A for the inode being defragged is dirty, so it tries to lock it... But it blocks because folio A is locked by the defrag task (the cleaner kthread) which is blocked waiting for the reservation ticket to be served, but the async reclaim metadata task is blocked waiting for the transaction commit, which in turn is blocked waiting for the delalloc flush task, which is trying to lock folio A, resulting in a deadlock. The same type of problem can happen if the async reclaim task starts to flush delalloc, as that requires both locking the folio and the extent range in the inode's io tree, and in this case we don't need the fs to be mounted with flushoncommit. This type of problem has ocurred several times in the past with reflinks for example, where we had a dirty folio while holding the extent range locked and then starting a transaction blocked waiting for the async reclaim task due to lack of free metadata space. So fix this by reserving delalloc space before locking folios and locking the extent range in the inode's iotree. We can not simply unlock the folios for each subrange given by defrag_collect_targets() after we defrag it because the same folio may be present too in the next subrange (due to large folios). Fixes: 22b398eeeed4 ("btrfs: defrag: introduce helper to defrag a contiguous prepared range") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8249dfe46337d599e2087b772a2e32ef9f77282b Author: Johannes Thumshirn Date: Tue Jun 23 13:38:51 2026 +0200 btrfs: zoned: don't force read-only on transient -EAGAIN from reloc merge [ Upstream commit e549093c11a2fff8430df3dfbdb45eb9811a69a5 ] On a zoned FS, btrfs_delayed_refs_rsv_refill() returns -EAGAIN whenever the over-committed metadata plus the zone_unusable bytes exceeds the usable size in a metadata block-group to avoid heavy over-commit of metadata and early ENOSPC in one transaction. If this happens while doing reclaim, the transaction is getting aborted. Treat -EAGAIN as a soft, retryable condition in case of block-group reclaim. Reported-by: Damien Le Moal Fixes: 7bcb04de982f ("btrfs: zoned: cap delayed refs metadata reservation to avoid overcommit") Reviewed-by: Filipe Manana Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6da989018eee30fcfde2070d4a81ae7d45dee073 Author: Yang Xiuwei Date: Tue Jul 7 11:03:33 2026 +0800 scsi: sd: Fix sd_done() sense handling condition [ Upstream commit a640d4546b11be5709a82bdc63d7dafd8ddc6c9e ] Only enter the sense_key switch when the command returned CHECK CONDITION with valid, non-deferred sense. The old condition let deferred or invalid sense fall through and mis-handle the I/O. Fixes: 03aba2f79594 ("[SCSI] sd/scsi_lib simplify sd_rw_intr and scsi_io_completion") Reviewed-by: Damien Le Moal Signed-off-by: Yang Xiuwei Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260707030333.22245-4-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 5d7d1b8b525e5eff33a01d07dfcf7bdd3b6d790d Author: Yang Xiuwei Date: Tue Jul 7 11:03:32 2026 +0800 scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails [ Upstream commit bb31844d88b77138b67aa20c3600203baff40140 ] sd_set_special_bvec() allocates a special payload page for UNMAP and WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI midlayer does not call uninit_command() because RQF_DONTPREP is not set yet, leaking the page. Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after freeing the page. Fixes: 81d926e8b552 ("sd: split sd_setup_discard_cmnd") Reviewed-by: Damien Le Moal Signed-off-by: Yang Xiuwei Reviewed-by: John Garry Link: https://patch.msgid.link/20260707030333.22245-3-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 748a14a0d41cfe3017251c11b314f85045414942 Author: Yang Xiuwei Date: Tue Jul 7 11:03:31 2026 +0800 scsi: sd: Fix error handling in sd_probe() after large pool creation failure [ Upstream commit e3cc6ea1a745e7f5d326f919a428b244fa119d8f ] After device_add(&sdkp->disk_dev) succeeds, sd_large_pool_create() failure must unregister disk_dev and let scsi_disk_release() free sdkp. Going through out_free_index kfree()s an already registered device and leaks the sysfs entry. Fixes: 7179e626b76e ("scsi: sd: Enable sector size > PAGE_SIZE in SCSI sd driver") Reviewed-by: Damien Le Moal Signed-off-by: Yang Xiuwei Reviewed-by: John Garry Link: https://patch.msgid.link/20260707030333.22245-2-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 56e547a31acee3b2243217053ec3aeb778b5cbf2 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 077c42c5c04fbbe0219dab83fb004472ef7518bc Author: Zijun Hu Date: Thu Jun 25 22:19:49 2026 -0700 Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled devices [ Upstream commit 33c6a8d01889a84cc773c0c20c8323bce84af27d ] Devcoredump is not enabled for ATH3012 or QCA_ROME, but they unconditionally populate devcoredump fields in btusb_setup_qca(). Fix by populating devcoredump fields only when BTUSB_QCA_WCN6855 is set, which marks the first generation of QCA BT SoCs for which devcoredump is enabled. Fixes: 20981ce2d5a5 ("Bluetooth: btusb: Add WCN6855 devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 42deed40dd99fb0078b40bc41f3afe0bc46e36b5 Author: Zijun Hu Date: Thu Jun 25 22:19:48 2026 -0700 Bluetooth: btusb: Record matched usb_device_id into btusb_data [ Upstream commit ff50db7a522e7bd3bd1c4db6da715e4bdb53af97 ] Add @match_id to btusb_data to record the matched usb_device_id which will be used later. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 33c6a8d01889 ("Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled devices") Signed-off-by: Sasha Levin commit dce459875be52183626abaa6041e6c5b31cfcdc1 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 19f65ea34a5390356ae413be3682635ab0c25f2b Author: Zijun Hu Date: Thu Jun 25 22:19:46 2026 -0700 Bluetooth: btqca: Fix qca_set_bdaddr() waiting for wrong HCI event [ Upstream commit cf81f0a3db2a5c34ee6e4ea379c631fab6d13e01 ] qca_set_bdaddr() waits for HCI_EV_VENDOR when sending EDL_WRITE_BD_ADDR_OPCODE (0xFC14), but the controller responds with Command Complete event as confirmed by btmon on WCN7850: < 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) Fix by passing 0 as the event parameter to __hci_cmd_sync_ev() to wait for the command complete event instead. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Reviewed-by: Bartosz Golaszewski Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 35d534234e249edcd98b0c258e8a2e7c4ceeea5d 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 1d3880877efe0e308cb10db7441940f2aaac9714 Author: Ricardo Neri Date: Mon Jul 20 19:43:18 2026 -0700 sched/fair: Also gate overloaded status update for SD_ASYM_CPUCAPACITY [ Upstream commit 6060d61d13a10da8c90da4eadf4a421825149883 ] The argument sg_overloaded of update_sg_lb_stats() is only consumed when balancing at the root domain. It only makes sense to update it in such a case. Commit 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecessarily during lb") updated the logic accordingly but missed the case in which the root domain has the SD_ASYM_CPUCAPACITY flag. Fix this. Fixes: 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecessarily during lb") Reported-by: Chen Yu Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Link: https://patch.msgid.link/20260720-rneri-fix-cas-clusters-v6-2-bb500bf4afd4@linux.intel.com Signed-off-by: Sasha Levin commit 304844b5545f444d523286da8228a1cbc46ffffa Author: Adrian Hunter Date: Tue Jul 21 10:02:54 2026 +0300 perf/x86/intel/pt: Fix stop/start with no update [ Upstream commit 2e17bf3a469a41457a3bc31b1f8fd66b6ce94a6d ] If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured. Fixes: 52ca9ced3f707 ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-4-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 55a5bc0de3b4cbff039c419fa79a5b5375e20ee8 Author: Adrian Hunter Date: Tue Jul 21 10:02:53 2026 +0300 perf/x86/intel/pt: Use bitwise access for PERF_HES_STOPPED [ Upstream commit 265bb4ef75fa657f4957d72087a6a246b89d5f0d ] The Intel PT driver reads and writes event->hw.state as a whole value, assuming it is either 0 or PERF_HES_STOPPED. That is true today, but a subsequent fix needs to also track an open AUX output buffer using the PERF_HES_UPTODATE bit of the same field. When more than one bit can be set, whole-value assignments would overwrite the other bits and whole-value comparisons would fail to match. Convert all accesses to set, clear and test the PERF_HES_STOPPED bit individually, in preparation for that change. No functional change intended: event->hw.state currently only ever holds 0 or PERF_HES_STOPPED, so the bitwise forms are equivalent. Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-3-adrian.hunter@intel.com Stable-dep-of: 2e17bf3a469a ("perf/x86/intel/pt: Fix stop/start with no update") Signed-off-by: Sasha Levin commit b7402b47cb08b565c2ac123e1894c08e65a4c33c Author: Adrian Hunter Date: Tue Jul 21 10:02:52 2026 +0300 perf/x86/intel/pt: Factor out pt_config_enable() [ Upstream commit c6df517796189723ffbdd7679206c97d3642c2ef ] pt_config() enables tracing by allowing NMIs and pause/resume, issuing the necessary barriers, and calling pt_config_start(). A later change needs to re-enable tracing on a (re-)start path without repeating the full pt_config() setup (filters, RTIT_CTL, buffer configuration). Factor that enabling sequence out into a new helper, pt_config_enable(), so it can be called on its own. No functional change intended. Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-2-adrian.hunter@intel.com Stable-dep-of: 2e17bf3a469a ("perf/x86/intel/pt: Fix stop/start with no update") Signed-off-by: Sasha Levin commit f0f512b8d9ee71eb4afda00da8910107821dd92a Author: Yuho Choi Date: Thu Aug 6 21:57:34 2026 -0400 ACPI: video: Release PCI device reference after lookup [ Upstream commit 3d7ed9b8ef47b8bcae1fc3e12f7590a217862a89 ] video_detect_portege_r100() uses pci_get_device() only as a boolean check for the Trident CyberBlade XP4m32 device. pci_get_device() takes a reference on a matching PCI device, but the callback returns without releasing it. Drop the reference after selecting the vendor backlight quirk so the PCI device can be released normally. Fixes: 35a341c9b25d ("ACPI: video: Add acpi_backlight=vendor quirk for Toshiba Portégé R100") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260807015734.913361-1-dbgh9129@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1b58cfd22ca0411cafe33c57087bbd7fe74b8e89 Author: surendra Date: Mon Jul 20 16:06:06 2026 +0530 thermal/drivers/spacemit: Validate clamped trip thresholds [ Upstream commit 68b78ad1e3533c1330dc9b7517947491c1a909c3 ] k1_tsensor_set_trips() checks the requested trip temperatures before converting them to the sensor register representation. Distinct out-of-range temperatures can clamp to the same hardware value, leaving the sensor with an invalid low/high threshold pair. Validate the ordering after conversion and clamping. Fixes: 296a977f2bac ("thermal/drivers/spacemit/k1: Add thermal sensor support") Signed-off-by: surendra Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260720103606.93924-1-kr494167@gmail.com Signed-off-by: Sasha Levin commit ec320af6cc1ed6ffa674202f56b7384a794bddf0 Author: Kazuma Kondo Date: Thu Aug 6 11:21:11 2026 +0000 ACPI: PCI: Avoid misleading _OSC messages for non-PCIe host bridges without _OSC [ Upstream commit fa608d2875b57fac792a9e1c11aa1da91737f04a ] After commit 7d703df7f4f5 ("ACPI: bus: Split _OSC evaluation out of acpi_run_osc()"), the _OSC evaluation path now returns AE_ERROR to negotiate_os_control() instead of propagating AE_NOT_FOUND from acpi_evaluate_object(). This has not caused any functional issues so far, but it produces additional misleading messages for non-PCIe host bridges without _OSC on some Intel servers: kernel: ACPI: Enabled 2 GPEs in block 00 to 7F kernel: ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus fe]) kernel: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] + kernel: acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC] + kernel: acpi PNP0A03:00: _OSC: platform willing to grant [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC] + kernel: acpi PNP0A03:00: _OSC: platform retains control of PCIe features (AE_ERROR) kernel: PCI host bridge to bus 0000:fe Previously, negotiate_os_control() silently ignored AE_NOT_FOUND for non-PCIe host bridges without _OSC, but after the above change, it no longer does so. As a result, negotiate_os_control() logs messages as if the OS had negotiated with the platform via _OSC, even though the non-PCIe host bridge has no _OSC method and no such negotiation actually occurs. Skip _OSC negotiation for non-PCIe host bridges that do not define an _OSC method before attempting to evaluate it. Fixes: 7d703df7f4f5 ("ACPI: bus: Split _OSC evaluation out of acpi_run_osc()") Link: https://lore.kernel.org/linux-acpi/d0be949d-0e21-472e-a44b-cedb1dd8695d@nec.com/ Suggested-by: Rafael J. Wysocki Signed-off-by: Kazuma Kondo [ rjw: Adjust white space, drop comment and tweak the new message ] Link: https://patch.msgid.link/20260806112052.857684-1-kazuma-kondo@nec.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0afe0cf203a951b7f54c0ccf01bca323642b9dd1 Author: Peter Ujfalusi Date: Wed Aug 5 13:41:49 2026 +0300 ASoC: tas675x: sort the register default table [ Upstream commit 3521d209ca70bf77b8c1dcccab5ca4df9468877f ] reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). TAS675X_AC_LDG_CTRL_REG (0xb5), TAS675X_TWEETER_DETECT_CTRL_REG (0xb6), TAS675X_TWEETER_DETECT_THRESH_REG (0xb7) and TAS675X_AC_LDG_FREQ_CTRL_REG (0xb8) are listed before the 0x7c - 0xa0 block, which leaves 14 of the 69 entries unreachable. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 133c81f84471 ("ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver") Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805104149.9795-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d321dc10e4b020aaf6044c4513017ab8717f0a55 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 b6fc0825df46a1affe9d7e27747a0015b7567cb8 Author: Daniel Borkmann Date: Thu Aug 6 22:10:45 2026 +0200 bpf, arm64: Fix exception table metadata for arena load-acquire [ Upstream commit af22d273aa1f61fb86ec712b3ed785da73c3296e ] Same problem as on x86-64: add_exception_handler() decides whether an instruction is a load by its class, and a load-acquire is of BPF_STX class even though it reads from src_reg into dst_reg. As a result ... if (BPF_CLASS(insn->code) != BPF_LDX) dst_reg = DONT_CLEAR; ... drops the register to clear, and ... if (BPF_CLASS(insn->code) == BPF_LDX) arena_reg = bpf2a64[insn->src_reg]; else arena_reg = bpf2a64[insn->dst_reg]; ... hands ex_handler_bpf() the value register instead of the address register. A load-acquire from an arena pointer that faults on an unmapped page is therefore reported as a WRITE at a bogus address, and dst_reg keeps its previous value instead of being cleared to 0. Note that emit_atomic_ld_st() already picks src_reg as the address for BPF_LOAD_ACQ, so only the exception table metadata was out of sync with the emitted access. Same as on x86-64, use bpf_atomic_is_load_acq() so a load-acquire takes the load path. Fixes: 9bb12368d539 ("bpf, arm64: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/bpf/20260806201047.333389-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 76b16abbc5ea1339b9d1624ebd799a6a2c0ba35e Author: Daniel Borkmann Date: Thu Aug 6 22:10:44 2026 +0200 bpf, x86: Fix exception table metadata for arena load-acquire [ Upstream commit 4cf8def58b779ad2827f81760837b7a844d6c7d6 ] A load-acquire from an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but the entry is filled in as if it were a store, since populate_extable() decides based on instruction class alone and a load-acquire is of BPF_STX class: if (BPF_CLASS(insn->code) == BPF_LDX) { arena_reg = reg2pt_regs[src_reg]; fixup_reg = reg2pt_regs[dst_reg]; } else { arena_reg = reg2pt_regs[dst_reg]; fixup_reg = DONT_CLEAR; } For a load-acquire dst_reg holds the loaded value and src_reg holds the address, so both assignments in the else branch are wrong. On a fault over an unmapped arena page ex_handler_bpf() then: - computes the reported address from the value register instead of the address register - reports the access as a WRITE, since it derives the direction from fixup_reg == DONT_CLEAR - leaves dst_reg untouched, so the program continues with a stale value instead of the 0 that BPF_PROBE_* loads deliver The access itself is emitted correctly, emit_atomic_ld_st_index() uses src_reg as the address, so this is a broken probe contract and a wrong diagnostic rather than a memory safety issue. Use bpf_atomic_is_load_acq() helper so a load-acquire takes the load path. Fixes: 5341c9a4d833 ("bpf, x86: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-3-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit a7dad4c69e5f2a0d1f62ab7c9b1f4cf8e8c8fe1f Author: Daniel Borkmann Date: Thu Aug 6 22:10:43 2026 +0200 bpf, riscv: Add and use bpf_atomic_is_load_acq() helper [ Upstream commit e2577cd62060be91a3d7d11a56e5a61faae4b7f7 ] A load-acquire is the only BPF_STX class instruction that reads from src_reg into dst_reg, that is, it has the operand roles of a BPF_LDX. JIT code which tells loads from stores apart by instruction class alone has to special case it, for example when deciding which register holds the faulting address and which one to clear from an exception handler. riscv64 already does so, open coded as a bare insn->imm test. Add a bpf_atomic_is_load_acq() helper and convert riscv64 over to it, so that the x86-64 and arm64 JITs can use the same helper in subsequent patches. Unlike bpf_atomic_is_load_store(), which presumes that its argument is already known to be a BPF_ATOMIC instruction, the new helper is called from code which still sees all instruction classes, so it checks class and mode itself. Also, move bpf_atomic_is_load_store() to filter.h next to BPF_ATOMIC_OP, so that both helpers stay together. No functional change intended. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Stable-dep-of: 4cf8def58b77 ("bpf, x86: Fix exception table metadata for arena load-acquire") Signed-off-by: Sasha Levin commit 5f8ade6e9b7931fc9697394f1b2c4ae833f5ac18 Author: Daniel Borkmann Date: Thu Aug 6 22:10:42 2026 +0200 bpf: Reject load-acquire from pointers requiring fault protection [ Upstream commit 7db0a00445f1a40bacfe9b747405c11cb5f10fc9 ] A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled. Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED. This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread: [...] SEC("tp_btf/sched_switch") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm = next->mm; /* untrusted */ out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...] Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative): [...] ; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...] ; load_acquire(&mm->pgd) 53: movq %rsi, %rdi 56: movq 184(%rdi), %rax <-- no check, no extable entry [...] Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM. A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed. The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this. Fixes: 880442305a39 ("bpf: Introduce load-acquire and store-release instructions") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 7d199b6a0651abad3ca6d0877dbedbe8fe6ea9e2 Author: Ben Horgan Date: Thu Aug 6 15:46:31 2026 +0100 arm_mpam: Disable driver unbind to avoid UAF [ Upstream commit bb1a0f582d519c0461b0940116e2b52c5ba31459 ] When a user unbinds an MSC and that MSC is the only MSC left for a component then the corresponding mpam_component will be freed. If the user then goes on to read the schemata file in the resctrl filesystem then the mpam_component will be accessed from resctrl_arch_get_config() leading to a use after free. As the MPAM driver is not a module the unbind sysfs interface is the only way to trigger the remove. Instead of dealing with the complexity of allowing some unused MSC to unbind just remove the unbind sysfs interface. Fixes: f04046f2577a ("arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate") Signed-off-by: Ben Horgan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a29044c9c83513c7463de2adb84c169685562ad2 Author: Ben Horgan Date: Thu Aug 6 15:46:30 2026 +0100 arm_mpam: Fix a NULL pointer dereference on unbinding after an error interrupt [ Upstream commit fc996c39689bb15aa80e5366809434f7258fb703 ] If a user unbinds an MSC after mpam_disable() has been run in response to an error interrupt then a dereference of a NULL pointer occurs as mpam_disable() sets the drvdata to NULL. Add an early return to the driver remove callback to avoid this. Fixes: f04046f2577a ("arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate") Signed-off-by: Ben Horgan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 988e11b69ef9d4034e19c64407030fa948580c3d Author: James Clark Date: Fri Aug 7 10:14:59 2026 +0100 perf: arm_pmuv3: Zero initialize hw_id branch stack field [ Upstream commit 7c3b63386c27bed8d59a4b4c283d02860420eb0a ] PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future. Fixes: 58074a0fce66 ("perf: arm_pmuv3: Add support for the Branch Record Buffer Extension (BRBE)") Signed-off-by: James Clark Reviewed-by: Anshuman Khandual Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7e4f2702bbadbde887a5d8897297720a7f037ee5 Author: Yeoreum Yun Date: Sat Jul 25 12:36:37 2026 +0100 coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable [ Upstream commit 0a47f0be6557b4a851addd430383a4dc7ee08752 ] In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths. Fixes: 810ac401db1f ("coresight: etm4x: Add complex configuration handlers to etmv4") Suggested-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-6-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 275466e3b95b297232cdf212a92fe62b636608d1 Author: Yeoreum Yun Date: Sat Jul 25 12:36:35 2026 +0100 coresight: etm4x: fix leaked trace id [ Upstream commit 467e5862ccb0eed907002f4c6d3badfe34360940 ] If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(), the trace ID may be leaked because it is not released. To address this, call etm4_release_trace_id() when etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(). Fixes: 7ebd0ec6cf94 ("coresight: configfs: Allow configfs to activate configuration") Reviewed-by: Jie Gan Reviewed-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-4-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 5ac900f73ce1d4d8308f40752b51bc8a02b244d2 Author: Yeoreum Yun Date: Sat Jul 25 12:36:34 2026 +0100 coresight: etm4x: fix underflow for usage of (nrseqstate - 1) [ Upstream commit 1674d9bff8073bdee5dbc200f56fc3caa28d0566 ] According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") Suggested-by: Leo Yan Suggested-by: Suzuki K Poulose Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-3-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 8a0c540e0901d85d6ddb364326665490d52b65bd Author: Yeoreum Yun Date: Sat Jul 25 12:36:33 2026 +0100 coresight: etm4x: fix wrong check of etm4x_sspcicrn_present() [ Upstream commit 0e1cd4270b42a257c139165622091e1e8c7104a7 ] According to Embedded Trace Macrocell Architecture Specification ETMv4.0 to ETM4.6 [0], TRCSSPCICR is present only if all of the following are true: - TRCIDR4.NUMSSCC > n. - TRCIDR4.NUMPC > 0b0000. - TRCSSCSR.PC == 0b1. Comment for etm4x_sspcicrn_present() is align with the specification. However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC not nr_pe. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn") Reviewed-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-2-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit b6ec4bf1ec4446c0213c08ea493e48e6b83cd1af Author: Bruce Johnston Date: Mon Aug 3 14:02:39 2026 -0400 md/raid1: don't set array_frozen in raid1_takeover() [ Upstream commit dc386aa0ac0a3ec06c9a3ea9b064b073fb72a916 ] raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d. Fixes: b39f35ebe86d ("md: don't quiesce in mddev_suspend()") Link: https://issues.redhat.com/browse/RHEL-191802 Signed-off-by: Bruce Johnston Link: https://patch.msgid.link/20260803180240.1177104-1-bjohnsto@redhat.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bb7f92d58fca9a9f06f3f51a82481c5f0bbbd46c Author: Yu Kuai Date: Mon Aug 3 03:50:18 2026 +0800 md/md-llbitmap: stop daemon timer rearm on destroy [ Upstream commit 5553d64e01d9a995be6c3de38501c6dd4ceede3b ] llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-10-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 2f0722435ce3a844dbb66b9bb0a18229dcc8739c Author: Yu Kuai Date: Mon Aug 3 03:50:17 2026 +0800 md/md-llbitmap: prevent create failure bitmap UAF [ Upstream commit 2116c2f0a0e547615886900e2ed8c529c016499b ] llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-9-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 35b27002ae9c411c114d75fdcc1c9a1c010fbf64 Author: Yu Kuai Date: Mon Aug 3 03:50:16 2026 +0800 md: avoid stale clone I/O accounting timestamps [ Upstream commit 45102fc8330525d35675b1c193242bba101df5ee ] md_clone_bio() always allocates the clone from mddev->io_clone_set, even when queue I/O stats are disabled. In that case it does not call bio_start_io_acct(), but it also left md_io_clone->start_time untouched. The clone private data comes from a mempool and can contain data from a previous user. md_end_clone_io() checks start_time to decide whether it needs to call bio_end_io_acct(), so a stale non-zero value can make the completion path end accounting that was never started for this bio. Set start_time to 0 in the no-stats branch. This keeps the end path tied to whether bio_start_io_acct() actually ran. Fixes: c687297b8845 ("md: also clone new io if io accounting is disabled") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-8-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 4224dccd325a9380e8edfb66aad8bb5771c94222 Author: Yu Kuai Date: Mon Aug 3 03:50:15 2026 +0800 md: wait for behind writes before destroying bitmap [ Upstream commit 2a79365b2278f16e163e4024086105693b421601 ] __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-7-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit ccbdc483eb041eef809e9ff223d1ad63518a2c52 Author: Yu Kuai Date: Mon Aug 3 03:50:14 2026 +0800 md/raid5: round bitmap stripes with sector division [ Upstream commit 17ea021ae74987d6064c8195c4922fa025753892 ] raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024). Fixes: 9c89f604476c ("md/raid5: implement pers->bitmap_sector()") Reported-by: Mykola Marzhan Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-6-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 0fef3967ccb8e9655ea086cfef79a08b6453d375 Author: Esteban Urrutia Date: Wed Jul 15 02:37:47 2026 -0400 phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets [ Upstream commit f8b4493d5e7e19682abcf538a9faad012b5ef69e ] Some SoCs such as SM8475 write data to registers using this offset, specifically SW_CTRL2 and MX_CTRL2. Add pcs_lane1 offset to V5 offsets to support this. Signed-off-by: Esteban Urrutia Fixes: 0fd0b31965b0 ("phy: qualcomm: qmp-pcie: add support for SAR2130P") Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260715-sm8475-bup-pcie-v2-2-48bd91a19abf@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 03455404fb6cbfd65842695df26739853fc1516b Author: Loic Poulain Date: Wed Jul 22 15:45:19 2026 +0200 phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend [ Upstream commit 142c5593379273264474f31d5956b1a0065cd576 ] There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer. Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support") Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-6-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b85bbec72fa813b60e093c6bb36ae232b9b0eb5e 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 0f9789d1b63e7d9f868ac9c29564339a4c03ceb5 Author: Loic Poulain Date: Wed Jul 22 15:45:16 2026 +0200 phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend [ Upstream commit 8e3687f7e18fe84372e86875709d56c37e7525a8 ] There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer. Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support") Reviewed-by: Abel Vesa Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-3-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 328cf94be91159d99520eb3f5f719b14eb242a7f Author: Mohd Ayaan Anwar Date: Tue Aug 4 00:57:58 2026 +0530 phy: qcom: sgmii-eth: vote for both voltage rails with correct current loads [ Upstream commit 4f81684a1d1018d7d0e5579f08d95e7701279358 ] The SerDes PHY has two voltage supply rails, vdda-0p9 and vdda-1p2, that must both be enabled for calibration to succeed. Without them: qcom-dwmac-sgmii-phy 8909000.phy: QSERDES_COM_C_READY_STATUS timed-out qcom-ethqos 23040000.ethernet eth0: __stmmac_open: Serdes powerup failed The driver relied solely on the PHY framework's implicit enable of 'phy-supply', which only voted for a single rail and set no current load. Use devm_regulator_bulk_get_const() to acquire both supplies and set the peak current loads (46 mA for vdda-0p9, 15 mA for vdda-1p2) as required by the hardware. Fixes: 601d06277007 ("phy: qcom: add the SGMII SerDes PHY driver") Signed-off-by: Mohd Ayaan Anwar Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260804-b4-sgmiieth_serdes_regulator-v2-2-c4bc688177dd@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fae5aba953686579c16e15f38178912ec1de5bbd Author: Linkai Gong Date: Fri Jul 31 17:46:08 2026 +0800 soc: fsl: qe: check platform_driver_register() in qe_ic_of_init() [ Upstream commit fbdba2a67fa7c0e7570bcbf9f28b782d6100270d ] qe_ic_of_init() ignored the return value of platform_driver_register() and always returned success. Propagate the error to the initcall. Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to platform_device") Signed-off-by: Linkai Gong Reviewed-by: Maxim Kochetkov Link: https://lore.kernel.org/r/20260731094608.1883391-1-gonglinkai@kylinos.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit a22464c5df5827e884a5a7d3d8fb03870e5bb6c8 Author: Jan Kara Date: Wed Aug 5 17:35:48 2026 +0200 ext4: fix transaction overflow during writeback [ Upstream commit 46e8e31771f4f1c5e1cdec37a889a6730e42e9f1 ] Commit 95ad8ee45cdb ("ext4: correct the reserved credits for extent conversion") was correct to note that we need to reserve enough credits for all extents possibly underlying a large folio. However it was too eager to reduce the number of reserved credits. Extent conversion may not only need to touch several leaf extent blocks, it may also need to split extents - for example a single large unwritten extent may need to be split into many small written ones in case of sparse folio dirtying. This can thus result not only in extent leaf modifications but also in a need to allocate new extent tree nodes. As a result the reserved transaction credits were not sufficient in some corner cases. Use ext4_meta_trans_blocks() for correct upper bound credit estimate. Fixes: 95ad8ee45cdb ("ext4: correct the reserved credits for extent conversion") Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260805153605.166545-5-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit c391af5743a447760c341ad5f6c2d1e984dbc484 Author: Jan Kara Date: Wed Aug 5 17:35:47 2026 +0200 ext4: teach ext4_meta_trans_blocks() about number of allocated extents [ Upstream commit 25b2a7e8d420c49fc46f25b6f953603e4dae1dbf ] So far ext4_meta_trans_blocks() expects that each extent counted in @pextents will be allocated in the transaction we estimate credits for. This is correct for the use in ext4_chunk_trans_blocks() and ext4_chunk_trans_extent() however the use in atomic write path (ext4_convert_unwritten_extents_atomic() and ext4_iomap_alloc() for IOMAP_ATOMIC) unnecessarily overestimates the number of necessary credits as neither of them allocates any data. Add argument to ext4_meta_trans_blocks() for number of extents that are going to be allocated in the transaction. Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260805153605.166545-4-jack@suse.cz Signed-off-by: Theodore Ts'o Stable-dep-of: 46e8e31771f4 ("ext4: fix transaction overflow during writeback") Signed-off-by: Sasha Levin commit 53f2e4d2b896ea6c9f1b9e82e36608d9a664c08e Author: Muhammad Usama Anjum Date: Wed Jul 29 10:11:26 2026 +0100 selftests/mm: unpoison pages in memory-failure teardown [ Upstream commit 288058d8db5d35623228d84f48d9bea3707d5c85 ] The memory-failure tests call cleanup() only after all result checks. A failed ASSERT_* invokes fixture teardown and aborts the test, so it skips cleanup() and leaves the injected page hardware-poisoned. Invoke cleanup() from FIXTURE_TEARDOWN() instead. Guard it with self->injection_attempted so tests that exit before injection do not try to unpoison a page when no injection was attempted. Injection can poison a page before returning an error or delivering SIGBUS, so teardown must clean up after every injection attempt. This runs the existing HWPoison and HardwareCorrupted checks on both normal and assertion-failure paths. Link: https://lore.kernel.org/20260729091127.1001179-1-usama.anjum@arm.com Fixes: ff4ef2fbd101 ("selftests/mm: add memory failure anonymous page test") Signed-off-by: Muhammad Usama Anjum Reviewed-by: David Hildenbrand (Arm) Acked-by: Miaohe Lin Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit dc2bd517ac0bce4ec7498644bd16b6db502df8e2 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 7bfae60ab7a53d651c3c1844ac0cc22ee6497e03 Author: Simon Glass Date: Mon Aug 3 08:10:24 2026 -0600 pinctrl: rockchip: Restrict the RV1103B 2-bit drive type to bank 2 [ Upstream commit 35ff52e54b38b01914be62ece27899665a46af56 ] The RV1103B override in rockchip_get_drive_perpin() forces the 2-bit level drive type for every pin above 11, but only bank 2 has the 2-bit fields; banks 0 and 1 use the 8-bit level type for all pins, as the corresponding check in rockchip_set_drive_perpin() shows. Today this is harmless, since neither level type is decoded in the get function and both paths fail with -EINVAL. It becomes an active problem once decoding is added, as the pins of banks 0 and 1 would be truncated to 2-bit values. Add the missing bank check, matching the set path. Fixes: 6d3ea3120eaa ("pinctrl: rockchip: Add RV1103B pinctrl support") Link: https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=1 Assisted-by: Claude:claude-opus-5 Signed-off-by: Simon Glass Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ab698d7710b477bc36b67b41b65d472408f81ec3 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 1b10015957a636960cdbf91074c4dd9b569200e5 Author: Prathamesh Shete Date: Mon Jul 27 14:11:21 2026 +0000 pinctrl: tegra264: fix DAP2 DIN/DOUT pin assignment [ Upstream commit 27e5b8efc25b9238865288b7091ae6915c2f7c14 ] The dap2_din and dap2_dout pin groups were given swapped ball suffixes: DAP2_DIN was described as ball PV7 and DAP2_DOUT as ball PW0. On silicon DAP2_DIN is on ball PW0 (mux register 0x6050, drive register 0x6054) and DAP2_DOUT is on ball PV7 (mux register 0x6058, drive register 0x605c), as reflected by the board pinmux. Because the ball suffixes were swapped, the groups were also assigned the wrong primary mux functions (dap2_din -> I2S2_SDATA_OUT and dap2_dout -> I2S2_SDATA_IN), routing the I2S2 data-in and data-out signals to the wrong pins and breaking DAP2 audio. Rename the groups to dap2_din_pw0 and dap2_dout_pv7 and give each pad its correct function (dap2_din_pw0 -> I2S2_SDATA_IN, dap2_dout_pv7 -> I2S2_SDATA_OUT). The register offsets are already correct and are left unchanged. This matches the board pinmux. Fixes: c98506206912 ("pinctrl: tegra: Add Tegra264 pinmux driver") Signed-off-by: Prathamesh Shete Reviewed-by: Jon Hunter Tested-by: Jon Hunter Acked-by: Thierry Reding Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fb4824880b0dba0e7b3a497c46c642f979630392 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 0e4b5f8cad67eabf98da3f90b6443dcea5783ff3 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 39de65117fd9c31580c69e3d2838f7ddb5c7170d Author: Aksh Garg Date: Wed Aug 5 16:20:14 2026 +0530 PCI: cadence: Fix host/endpoint dependencies for cadence-plat driver [ Upstream commit 79752653c136493ae8c3b4260f9f80de0b91d0bf ] The cadence-plat driver has a single platform driver that can be built-in or a loadable module, but it calls two separate backend drivers depending on whether it is a host or endpoint. If one of the mode is build as built-in and another as loadable module, we end up with a situation where the built-in pcie-cadence-plat driver tries to call the modular host or endpoint driver, which causes a link failure: ld: error: undefined symbol: cdns_pcie_ep_setup >>> referenced by pcie-cadence-plat.c >>> drivers/pci/controller/cadence/pcie-cadence-plat.o:(cdns_plat_pcie_probe) in archive vmlinux.a ld: error: undefined symbol: cdns_pcie_host_setup >>> referenced by pcie-cadence-plat.c >>> drivers/pci/controller/cadence/pcie-cadence-plat.o:(cdns_plat_pcie_probe) in archive vmlinux.a Fix this by moving the 'select' of PCIE_CADENCE_HOST and PCIE_CADENCE_EP from the individual PLAT_HOST/PLAT_EP symbols into the common PCIE_CADENCE_PLAT symbol, conditioned on which backends (modes) are enabled. Fixes: 611627a4e5e4 ("PCI: cadence: Add module support for platform controller driver") Reported-by: Randy Dunlap Closes: https://lore.kernel.org/linux-next/589ea512-93c6-4e1c-83d7-ba45a0b35843@infradead.org/ Signed-off-by: Aksh Garg Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Randy Dunlap Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260805105014.3952686-1-a-garg7@ti.com Signed-off-by: Sasha Levin commit e399e9d7e291ccbeba6560fb8278c8d2aa744521 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 57a9b737e7939e65cc913df9a83e8dea556db7f7 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 36c99db9f364ac79b215f780b453c5c4cf406fb7 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 ece5ad121b2ac521a11bf693081c6e9c2fb6bc08 Author: Gerald Loacker Date: Sat Jul 25 18:56:03 2026 +0200 phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table [ Upstream commit 4fae43e33a7c10951fbdc6baf409d51bd66aaefb ] The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this rate. This is essential for RK3588 reusing this array and fully supporting rates up to 2500 Mbps. Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy") Reviewed-by: Michael Riesch Signed-off-by: Gerald Loacker Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-1-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5acdc4d5b58bd0730824938db79b5f08ef996d9c Author: Felix Gu Date: Mon Aug 3 23:15:17 2026 +0800 phy: sunplus: fix error handling in sp_uphy_init() [ Upstream commit 8b2683bc4cc18c581b7cd24f227cbe61abca7f4d ] Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked. Fixes: 99d9ccd97385 ("phy: usb: Add USB2.0 phy driver for Sunplus SP7021") Signed-off-by: Felix Gu Reviewed-by: Philipp Zabel Link: https://patch.msgid.link/20260803-sunplus-usb3-v1-1-5a562524c869@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5374f3d53376d35085e0727c8c1b945bf7123996 Author: Felix Gu Date: Mon Aug 3 20:43:24 2026 +0800 phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure [ Upstream commit b780b8929c759cfa7a892d58625a5ad46cb1cbd2 ] for_each_child_of_node_scoped() releases the node reference on scope exit, so the explicit of_node_put(np) in the devm_phy_create() error path drops it twice. Drop the redundant of_node_put() and let the scoped cleanup handle it. Fixes: b64b32791fb5 ("phy: renesas: rcar-gen2: Simplify with scoped for each OF child loop") Signed-off-by: Felix Gu Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260803-rcar-gen2-v1-1-9aa35c36d7d7@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 935f6e837a83b86b073a7601f699dc2c00e01322 Author: Biju Das Date: Thu Aug 6 11:22:27 2026 +0100 phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator [ Upstream commit 49c9b71b45081e5e5eeb507a2d6edb80d332dc59 ] devm_regulator_get_exclusive() initialises the regulator with enable_count = 1, requiring the consumer to disable it before release. The devm disable action was previously only registered when the caller explicitly requested enable, so when the regulator was left in its initial enabled state without an explicit enable call, the cleanup path skipped decrementing enable_count, triggering a WARN_ON during regulator release on device removal. Fix this by always registering the devm disable action based on the actual enabled state via regulator_is_enabled(), regardless of whether the caller requested an explicit enable. This covers both the explicitly enabled case and the initial state set by devm_regulator_get_exclusive(). Fixes: 24843404efe4 ("phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCs") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260806102236.149159-9-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3f2828c4788ae4e03ab0dae2b956da13b53fd975 Author: Meghana Malladi Date: Mon Jul 6 14:52:29 2026 +0530 arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node [ Upstream commit 197df050a10fe216971b45a79f07195c86a02236 ] MDIO clock index changed from 62:3 to 81:0 to match proper clock definition in the SoC device tree. Clock Id 81:0 belongs to ICSSG0 core clock, where as 62 belongs to EQEP2 device. See: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/clocks.html Fixes: c9087e3898a1d0 ("arm64: dts: ti: k3-am64-main: Add ICSSG nodes") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260706092229.82674-1-m-malladi@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 33145914688ed5a75b6ff9987a9ca84e4ccf5f26 Author: Takashi Iwai Date: Thu Aug 6 12:44:14 2026 +0200 ALSA: hda: cix-ipbloq: Avoid build with 32bit archs [ Upstream commit 2a611c4a1cbcb179cd8079a7ccadee390dac66f6 ] The cix-ipbloq driver has an assumption of 64bit DMA address, and building it for 32bit dma_addr_t leads to a sparse / compile warning. Simply disable the builds for 32bit archs for avoiding such reports. Fixes: d91e9bd10125 ("ALSA: hda: add CIX IPBLOQ HDA controller support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608061559.Kxqvi5LZ-lkp@intel.com/ Link: https://patch.msgid.link/20260806104431.1300304-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5826db2ddddb695d8f397d6cc20ba41c18a3ec01 Author: Jan Kara Date: Mon Aug 3 18:00:38 2026 +0200 ext4: fix spurious message about orphan cleanup on RO fs [ Upstream commit 5aa98f874c013bcce9bb84ffded2f0ef886e4e33 ] When orphan_file feature is enabled, ext4_orphan_cleanup() was always walking through the orphan file looking for orphan inodes. This is mostly harmless but for read-only filesystem it results in spurious "orphan cleanup on readonly fs" message and in other cornercases it could result in similar somewhat misleading messages. Skip orphan cleanup if the orphan file is empty to avoid confusing messages. Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Reported-by: Tigran Aivazian Signed-off-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260803160037.64285-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0fa116a17b69a28712cdf209318e345b676d7f6c Author: Harry Wentland Date: Thu Jul 16 16:49:06 2026 -0400 drm/amd/display: Resize MST HDCP per-connector arrays to 32 [ Upstream commit 261e0fe4e2c99f687114b64b10b98db964b475f4 ] AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors. Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size. Fixes: 82986fd631fa ("drm/amd/display: save restore hdcp state when display is unplugged from mst hub") Assisted-by: Copilot:claude-opus-4.8 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6e26232294dbcf5dd66e7f9d42038a84c4acb86c 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 61b45f9be60cc0fdc47821227c349378799d2252 Author: Steve Dunnagan Date: Fri Jul 24 14:04:12 2026 -0400 leds: gpio: Clear error pointers for skipped LEDs [ Upstream commit 942901eeda934f1bebf2605a781155e9d6bc7f6e ] gpio_led_get_gpiod() returns an error pointer when a platform-data LED's GPIO is unavailable. gpio_led_probe() skips registration in that case, but leaves the error pointer in led_dat->gpiod. The skipped entry remains included in priv->num_leds. During shutdown, gpio_led_shutdown() walks those entries and passes the error pointer to gpio_led_set(), producing: gpiod_set_value: invalid GPIO (errorpointer: -ENOENT) Clear led_dat->gpiod before skipping the LED so skipped entries do not retain error-valued descriptors. Fixes: 45d4c6de4e49 ("leds: gpio: Try to lookup gpiod from device") Suggested-by: Lee Jones Assisted-by: ChatGPT:GPT-5.5-Thinking Signed-off-by: Steve Dunnagan Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260724180412.43150-1-sdunnaga@redhat.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ad50c2c550ff20ac76461c95f22c5b23b4205e6c Author: Sven Peter Date: Sun Jul 19 15:00:32 2026 +0200 mfd: macsmc: Fix key count endianness annotation [ Upstream commit 0a29aa605286bcd01632eb6b61f59b9053312347 ] SMC firmware returns the value of the #KEY key in big-endian unlike most other keys. Reading it through apple_smc_read_u32() into a plain u32 and then converting with be32_to_cpu() makes sparse complain: drivers/mfd/macsmc.c:462:26: sparse: cast to restricted __be32 Read the raw value into a __be32 using apple_smc_read() instead. Fixes: e038d985c982 ("mfd: Add Apple Silicon System Management Controller") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607181046.OANjIoqR-lkp@intel.com/ Signed-off-by: Sven Peter Reviewed-by: Janne Grunau Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260719-b4-macsmc-be32-fix-v1-1-c7b1936307fa@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ad32c823abfb858756e1c155e4460aca3e6d76c7 Author: Qiang Yu Date: Thu Jul 23 17:20:47 2026 +0800 drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12 [ Upstream commit 4261cbc7b03f1f56e95aeaf1492b8690fa5a253e ] TA_CNTL2.TRUNCATE_COORD_MODE selects whether texture coordinate truncation is D3D9/GL/Vulkan conformant. gfx11 reads it and reports it to userspace via AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, but gfx12 never read it, so the flag was always reported as 0 and userspace fell back to the non-conformant path. Read it in gfx_v12_0_constants_init() like gfx11 does. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Signed-off-by: Qiang Yu Reviewed-by: Marek Olšák Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7b5f4362c41ac9a40cb7aee078ef81afd7dae052 Author: Alex Deucher Date: Fri Jun 26 16:33:56 2026 -0400 drm/gfx12: Program DB_RING_CONTROL [ Upstream commit 402ebe22b267783f3b05b714df224fad0223b278 ] This is needed to allocate occlusion counters across both gfx pipes. GFX 12 only has one gfx pipe, so no functional change since the default value is 1. Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher Stable-dep-of: 4261cbc7b03f ("drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12") Signed-off-by: Sasha Levin commit e54c7a2bce63d704f848af9c843c3d860e7c9d57 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 f81bcb7e83be124cea34491e38143657bc16b0db Author: Mark Brown Date: Wed Aug 5 22:32:23 2026 +0100 tools: Ensure tools copy of linux/filter.h exports the UAPI [ Upstream commit 7a1f400ff5e57f41e23c8145a54ea084039b023c ] Normally when there is an include/foo.h and an include/uapi/foo.h the non-UAPI copy includes the UAPI copy. This is the case for the in kernel copy of linux/filter.h but not for the copy in tools/ which results in build breaks for the newly added arm64 seccomp_ptrace_x0_bypass selftest. Add an explicit include of the uapi to fix the test and avoid future surprises. Fixes: 2fcbc4adf997 ("kselftest/arm64: Add seccomp ptrace x0 bypass test") Fixes: f143c11bb7b9 ("tools: bpf: Use local copy of headers including uapi/linux/filter.h") Signed-off-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 15327f1eb9cc97bac22b2717188d9c2b67098f73 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 77053624d03359a4e2ec47d7106639ec9a498c2b 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 d736ace2c491623c9ab5e73744085e93e9ae3ebe 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 be919eed5e52a0c493677a8e0657f147937b85c4 Author: Felix Fietkau Date: Tue Aug 4 08:26:08 2026 +0000 wifi: mac80211: skip default WMM setup for AP_VLAN links [ Upstream commit 4d8cfff012aaa971d50b01823b1015c1073c3ff6 ] AP_VLAN interfaces are never passed to the driver, so setting default WMM parameters on their links trips the check-sdata-in-driver warning in drv_conf_tx(), as well as in the BSS_CHANGED_QOS link info notification. Skip it, matching the existing AP_VLAN handling in this function. Fixes: 2259d14499d1 ("wifi: mac80211: set default WMM parameters on all links") Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260804082608.2011433-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8351d66344237f4a9f79d718f30414a1bd5d92be Author: Leon Romanovsky Date: Thu Aug 6 11:48:56 2026 +0300 RDMA/erdma: restrict the driver to little-endian systems [ Upstream commit a12d9145145b21c50531afb6e3f711b1f34e1465 ] The eRDMA device interface requires explicit byte ordering, but several DMA-visible values that should be little-endian remain native-endian. Command request payloads are copied verbatim, data-path SQE headers are written without cpu_to_le64(), and kernel doorbell records are assigned plain u64 values. The command completion path also reads a little-endian SQE header without conversion. These paths are byte-swapped on big-endian kernels and can break command processing during probe. Since complete big-endian support requires converting every device-visible structure, depend on !CPU_BIG_ENDIAN. Fixes: ca7fd6cff3b8 ("RDMA/erdma: Add driver to kernel build environment") Link: https://patch.msgid.link/20260806-missing-endianness-conversion-for-64-v1-1-896327c1aff1@nvidia.com Acked-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cd2396fc9684d2cfd3f3c3f09c79d6d9d725b0ca Author: Petr Pavlu Date: Thu Aug 6 11:10:16 2026 +0200 module/dups: Fix use-after-free in kmod_dup_req lifetime handling [ Upstream commit 5eecb11b543f9f417bcf0dea239ff99c6af65dbd ] The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting. Fixes: 8660484ed1cf ("module: add debugging auto-load duplicate module support") Reviewed-by: Aaron Tomlin Signed-off-by: Petr Pavlu Signed-off-by: Sasha Levin commit 2bdd4d5d2cae6f19e603b9d825ec54a089069ac8 Author: Petr Pavlu Date: Thu Aug 6 11:10:15 2026 +0200 module/dups: Inform duplicate requests about the result directly [ Upstream commit d258ed8a86bb46bbbbc84fb914478259a1e694a4 ] When kmod_dup_request_announce() announces the completion of a request_module() call to duplicate waiters, it queues a work item to invoke kmod_dup_request_complete(), and only that function calls complete_all(). This adds an arbitrary delay that is unnecessary and provides little benefit. Call complete_all() directly from kmod_dup_request_announce() instead. Signed-off-by: Petr Pavlu Stable-dep-of: 5eecb11b543f ("module/dups: Fix use-after-free in kmod_dup_req lifetime handling") Signed-off-by: Sasha Levin commit 5ede61dc58fd37960fd5f5184e8c08b23f2ab0b5 Author: Naveen Kumar Chaudhary Date: Thu Jun 4 23:15:02 2026 +0530 module: use strscpy() to copy module names in stats and dup tracking [ Upstream commit 93c29ebd1622fb0670701e1c1b3a978a5cac08b7 ] Both try_add_failed_module() and kmod_dup_request_exists_wait() use memcpy() with strlen() to copy module names into fixed-size char[MODULE_NAME_LEN] buffers. Neither performs a bounds check on the copy. Current callers always pass names originating from mod->name (itself char[MODULE_NAME_LEN]), so this is not exploitable today. However both functions accept a plain const char * with no documented length contract, making them latent buffer overflows if a future caller passes a longer string. Replace memcpy() with strscpy() in both sites, which bounds the copy to MODULE_NAME_LEN and always NUL-terminates. Signed-off-by: Naveen Kumar Chaudhary Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Stable-dep-of: 5eecb11b543f ("module/dups: Fix use-after-free in kmod_dup_req lifetime handling") Signed-off-by: Sasha Levin commit 561651d6a15588cee2040755f253faca2463415c 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 ad4492dcaf90a1d1a728ec5eef1a68ce5355027a 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 4397ea31e3b0d017c2b9b876b326df0b3eb845bf 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 545461671497ce4a5d3fc2dcb1d9665a170118db Author: Bard Liao Date: Tue Jul 28 20:46:35 2026 +0800 soundwire: cadence_master: add BRA_NumBytes[8] support [ Upstream commit f74b58902532bf397cdb62049433b5b2a32ddcec ] The header[0] bit definitions are: Header[0] bits 7 – 6: BRA_HeaderType Header[0] bits 5 – 2: BRA_DeviceAddress[3:0] Header[0] bit 1 BRA_Opcode 1 => Write, 0 => Read Header[0] bit 0 BRA_NumBytes[8] And the header[1] indicates the BRA_NumBytes[7:0]. The existing code doesn't handle BRA_NumBytes[8] therefore the maximum BRA number of a frame is limited to 255. Fixes: fe8a9cf75c1e ("soundwire: pass sdw_bpt_section to cdns BPT helpers") Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260728124639.1484973-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 55516986a3d81325c84f2d4ae9cd03116bc63599 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 0f77d1a0a25056146eea1f8619fa06ce287c91f7 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 35a125c9abbf70355dbda6dd38d8b37d84447b4b Author: Priya Bala Govindasamy Date: Mon Jul 20 18:00:58 2026 +0000 rust: cpufreq: Fix temporary write in Registration::bios_limit_callback [ Upstream commit 19c76bdd3fc02475c73c8576f6f4a55ff07886f1 ] In `Registration::bios_limit_callback`, the expression `&mut (unsafe { *limit })` creates a reference to a temporary copy of the value pointed to by `limit` on the stack. Therefore, writes made by `T::bios_limit` go to this temporary instead of the memory location pointed to by `limit`. Additionally, `limit` may be uninitialized, such as when `Registration::bios_limit_callback` is invoked by `show_bios_limit` in drivers/cpufreq/cpufreq.c. Therefore creating a reference to `limit` is unsound. Fix this by changing the signature of `T::bios_limit` to return the limit value. `Registration::bios_limit_callback` can then update `limit` directly. Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration") Reported-by: Dylan Zueck Reported-by: Yuan Tan Assisted-by: ChatGPT:gpt-5.4 Signed-off-by: Priya Bala Govindasamy [ Viresh: Fix rustfmtcheck warning ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 04ac4e270e3d30a1948aaacfbaffbc393cd03cdd Author: Priya Bala Govindasamy Date: Mon Jul 20 20:50:35 2026 +0000 rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table [ Upstream commit b5e4771f20a37fdf19eac0824bf062dffb4e291f ] The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()` as the last frequency entry in the frequency table. But the C API expects the last entry to have frequency set to `CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h. Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END` instead of `Hertz(c_ulong::MAX).as_khz()`. Fixes: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("rust: cpufreq: Add initial abstractions for cpufreq framework") Reported-by: Dylan Zueck Reported-by: Yuan Tan Assisted-by: ChatGPT:gpt-5.6-terra Signed-off-by: Priya Bala Govindasamy Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit eadc95c99cbe813a59662b43cfb8d9a0da5a413f 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 e71206a8a1d97f4517d4955c268f25183e0b5228 Author: Jernej Skrabec Date: Mon Aug 3 18:10:49 2026 +0200 drm/sun4i: Drop node references while building component list [ Upstream commit 08a91f2a0664b73c2af9295ecbd441e852abe33c ] Two references are leaked every time the display pipeline is walked: the output port node in sun4i_drv_traverse_endpoints(), which was never released since the driver was introduced, and each node taken out of the endpoint fifo in sun4i_drv_probe(), which stopped being released when the fifo was introduced. The latter is still safe to drop right after processing, since drm_of_component_match_add() takes its own reference. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Fixes: 8b11aaface2b ("drm/sun4i: Implement endpoint parsing using kfifo") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/759c74e3a22b97ca066ef7910ca4b91b852011e6.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit d9fb87926522d296151a4dfdb6a6c66c8db41dc7 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 68e0643bb227a3305df9f11159cca9943d08851d 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 c0d3219ffd4c0d42295e0dc949856067b7818b71 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 ef396e92c50e5fe7e58b09aff9a233e15d0d4bca Author: Jernej Skrabec Date: Mon Aug 3 18:10:45 2026 +0200 drm/sun4i: hdmi: Don't leak sync polarity bits into packet control [ Upstream commit f5c3b1b0d228624786d22973a20c908c84e1a576 ] sun4i_hdmi_enable() keeps using the same variable after it programmed the video timing polarity register with it. The leftover TX_CLK, HSYNC and VSYNC bits are then ORed into the packet control register, where each nibble selects the packet type sent in one slot. As a result, slot 0 selects packet type 3 instead of the AVI infoframe whenever the mode has positive HSYNC polarity, and the TX_CLK bits set nibbles which the driver never programs. Assign the packet types instead of ORing them into the stale value. Fixes: 9ca6bc246035 ("drm/sun4i: hdmi: Move mode_set into enable") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/51ba0918ce016a4b45313d5df1b6ce31b8c8731e.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit ae08a67bca7817e37c16c1ec51bce7f2ff9aaf2c 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 eb1dc0e2c7acb0c374badaf915891ca7d18d0a50 Author: Jernej Skrabec Date: Mon Aug 3 18:10:43 2026 +0200 drm/sun4i: tcon: Set output mux for DSI and LVDS [ Upstream commit 9c90199b39637ad94253c4fd8e7b1333ca1d3e0d ] DSI and LVDS skip output mux setup, so TCON TOP cannot route the selected mixer. Configure them like other channel 0 outputs. In practice this matters for D1, where channel 0 TCONs are fed through TCON TOP. The remaining set_mux implementations only handle TMDS and return an error for other encoder types, as before. Fixes: b9b52d2f4aaf ("drm/sun4i: Add support for D1 TCONs") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/7e9dad9eed2e91a79c4e1202caa8fed7c2427531.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit ac9f274dac95245584f8726822b70b299e0dbaed Author: Jernej Skrabec Date: Mon Aug 3 18:10:42 2026 +0200 drm/sun4i: tcon-top: Keep mixer routes distinct [ Upstream commit 62bac3202042a8cfd4d4969a6d057cebd8b7cc1a ] Both mixer selectors reset to TCON 0. Selecting the same TCON for both mixers causes black or corrupted output. When a route would collide, park the other mixer on another described TCON, or an unused selector if none exists. Since the TCON index is now used as a shift, also reject negative values. Tested on Orange Pi 3 with TCON_LCD0 and TCON_TV0. Link: https://lore.kernel.org/linux-sunxi/Zn8GVkpwXwhaUFno@titan/ Link: https://lore.kernel.org/linux-sunxi/20241108-tcon_fix-v1-1-616218cc0d5f@jookia.org/ Fixes: 05db311a792d ("drm/sun4i: tcon-top: Add helpers for mux switching") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/52eb247169b268054302afa71e598add0b04748d.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit a42daad53d09ed3f64e63f9de0f1cb9b4f2228bf Author: Jernej Skrabec Date: Mon Aug 3 18:10:41 2026 +0200 drm/sun4i: vi scaler: Restore opaque alpha in video modes [ Upstream commit 583d99165a85c3aaee924078c0f03c72e25644ac ] The DE3 mixer initialization clears the entire mixer register space. This also clears VSU_GLOBAL_ALPHA, despite its hardware reset value being 0xff. The VI scaler uses Video Normal mode for subsampled YUV formats. In this mode, VSU_GLOBAL_ALPHA provides the scaler output alpha. Leaving the register at zero causes the scaler to produce fully transparent output. Set VSU_GLOBAL_ALPHA to 0xff whenever configuring a DE3 or newer VI scaler. The register is ignored in UI scaling mode. Fixes: c50519e6db4d ("drm/sun4i: Add basic support for DE3") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/c48ba85b9e4478d51afde4f36839fd1c1d363b23.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit f587b2606d710bb43fd8946d6ade39b16ba1c1e7 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 4420c243e7892ff62e86fa27f820278e80024bb2 Author: Jernej Skrabec Date: Mon Aug 3 18:10:39 2026 +0200 drm/sun4i: Fix V3s YUV scanline size [ Upstream commit abffce8b1eb5e119efccc51fc6a18ba38e2f6db6 ] The VI scaler line buffer on V3s can hold 1024 pixels for subsampled formats, not 2048 as currently claimed. Since coarse horizontal scaling is engaged only once the source width exceeds that limit, YUV layers wider than 1024 pixels are passed to the scaler unchanged and the output is corrupted. Use the value from the vendor driver. Fixes: 2586de70c15c ("drm/sun4i: Add VI scaler line size quirk for DE2/DE3") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/75ad4947981f2dc33fd42c05ae0b0cedda7647bd.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 4dd6b79f7099c2ec5401632d26983eaf36d56df5 Author: Arnaldo Carvalho de Melo Date: Wed Aug 5 12:10:43 2026 -0300 perf c2c: Clean up registered formats on c2c_hists__init() and c2c_hists__reinit() failure [ Upstream commit 6d421f609bba7b0b1a11741ec4b19feadfd27051 ] When c2c_hists__init() or c2c_hists__reinit() calls hpp_list__parse() and it fails partway through, format structures registered via perf_hpp_list__column_register() and perf_hpp_list__register_sort_field() are left on the hpp_list. In c2c_hists__init(), only one of the callers, c2c_he__alloc_hists(), handled this with perf_hpp__reset_output_field(), while perf_c2c_report() did not, leaking the partially registered entries. In c2c_hists__reinit(), neither perf_c2c_report() nor resort_cl_cb() clean up on failure. Fix by adding cleanup inside both functions themselves, so all callers are protected, and remove the now redundant reset in c2c_he__alloc_hists(). Fixes: 78b275437873 ("perf c2c report: Add sample processing") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Assisted-by: Opencode:mimo-v2.5-free Assisted-by: Opencode:DeepSeek-V4-Flash-free Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 86f5cb2d1e612f68549ded2c66cf0defc4dbe4d2 Author: Arnaldo Carvalho de Melo Date: Wed Aug 5 12:10:42 2026 -0300 perf c2c: Fix error masking, OOM, and unchecked caller errors in hpp_list__parse() [ Upstream commit f53f5c2437c1bd76fc0063a30a069a5207de8802 ] hpp_list__parse() has three bugs: 1. The PARSE_LIST macro resets ret = 0 at the start of each invocation, so an error from output parsing is silently overwritten when the sort parsing block runs. The function returns success with partially initialized state. 2. When the caller passes a non-NULL output_ or sort_ string, but strdup() returns NULL due to OOM, NULL is passed to PARSE_LIST which treats it as empty input (the "if (!_list) break" branch). No error is returned. 3. When the called _fn function fails and returns something other than -ESRCH or -EINVAL (-ENOMEM, for instance) it was not bailing out of the strtok loop. Fix them by checking strdup() return values before proceeding and adding a cleanup label so that ret from each PARSE_LIST call is checked before the next runs, preserving the first error. The early exits now skip perf_hpp__setup_output_field(), which means c2c_hists__reinit() can return a non-zero value in cases that previously always succeeded silently. Both callers discarded its return: resort_cl_cb() continued into hists__collapse_resort() on a broken list, and perf_c2c__report() proceeded with uninitialised hists. Fix the full chain: check and propagate the error in resort_cl_cb() -- hists__iterate_cb() already stops iteration and returns the callback error -- and check both c2c_hists__reinit() and hists__iterate_cb() in perf_c2c__report(). Also turn PARSE_LIST into a function, using a switch to catch other errors, converting the called functions to return an appropriate errno instead of -1 on failure. Also make the two callers that iterate sort_dimension__add() and output_field_add() handle the newly propagated errors: setup_sort_list() and setup_output_list() only checked for -EINVAL and -ESRCH, so an -ENOMEM from a failed allocation was silently overwritten by the next loop iteration. Break out of the loop and propagate any other error. The hpp_list__parse() fixes were developed with AI assistance from Claude:claude-sonnet-4.6, and the setup_sort_list()/setup_output_list() caller fixes with AI assistance from Opencode:mimo-v2.5-free and Opencode:DeepSeek-V4-Flash-free. Fixes: 2d388bd0c9d3 ("perf c2c report: Add stdio output support") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-sonnet-4.6 Assisted-by: Opencode:mimo-v2.5-free Assisted-by: Opencode:DeepSeek-V4-Flash-free Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 510b305f35aa66c56caf84ce1b5538dfad6820c5 Author: Alexey Charkov Date: Wed Aug 5 17:45:09 2026 +0400 clk: rockchip: rk3576: fix source muxes for SPI0..SPI4 [ Upstream commit 586ff159ec02533c17dd928641529cb0b52e9c62 ] The TRM defines available source muxes for SPI0..SPI4 as - b00: clk_gpll_div6_src - b01: clk_gpll_div8_src - b10: clk_cpll_div10_src - b11: clk_xin_osc0_func Which doesn't match what the current clock driver implements, making it impossible to derive some SPI clock rates such as 37.125 MHz (which requires clk_gpll_div8_src as the source mux). Add a correct mux definition per TRM and point SPI0..SPI4 clocks at it. Fixes: cc40f5baa91b ("clk: rockchip: Add clock controller for the RK3576") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260805-rk3576-spi-clk-v1-1-2f040d0d163b@flipper.net Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 976f1be72740cfbc351d3841fd21186dda3ea723 Author: Leon Hwang Date: Wed Aug 5 23:08:09 2026 +0800 bpf: Fix sleepable check for tracing/lsm prog [ Upstream commit 00244bdaa423d93f4571f3f6854378ce3365e524 ] When CONFIG_FUNCTION_ERROR_INJECTION is disabled, a sleepable tracing prog is allowed to attach to '__x64_'-alike prefix symbols. It is because the verifier does not verify whether the symbol is a kernel function or a bpf prog. That said, a sleepable tracing prog is allowed to attach to a bpf prog target whose name has '__x64_'-alike prefix. For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP prog, and copies buffer from a user pointer with bpf_copy_from_user() helper. After attaching the XDP prog to lo interface, the kernel BUG could be triggered by 'ping -c 1 -W 1 127.0.0.1': [ 3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324 Fix it by disallowing sleepable prog always when its target btf is not a kernel's btf. Fixes: 16d9c5660692 ("bpf: Always allow sleepable programs on syscalls") Signed-off-by: Leon Hwang Signed-off-by: Andrii Nakryiko Acked-by: Viktor Malik Link: https://lore.kernel.org/bpf/20260805150810.34907-2-leon.hwang@linux.dev Signed-off-by: Sasha Levin commit f523359c4789bb0396d2d642464a6e2fd4f2299d Author: Jiri Olsa Date: Mon Aug 3 23:01:46 2026 +0200 bpf: Clear buf on error in __bpf_get_task_stack [ Upstream commit f5d242825ca417bb6afe35fde6e8880f97ca43fb ] Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM argument and we should initialize the buf on every return path. Adding missing buf memset for __bpf_get_task_stack fail paths. This provides deterministic buffer contents, which is useful when the buffer is used directly as a map key. Fixes: 06ab134ce8ec ("bpf: Refcount task stack in bpf_get_task_stack") Fixes: b992f01e6615 ("bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()") Reported-by: Sashiko Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-10-jolsa@kernel.org Signed-off-by: Sasha Levin commit 34cbcb333f30e25579513a4bd7c6b8ffd3a470ec Author: Jiri Olsa Date: Mon Aug 3 23:01:45 2026 +0200 bpf: Remove trace_in argument from __bpf_get_stack [ Upstream commit 58cfc2201d964163fe9c4a703136eb64db799f08 ] Now with the new callchain_* helper functions we can process trace_in case directly in bpf_get_stack_pe function and remove it from __bpf_get_stack which makes things easier for preemption fix in following change. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-9-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit 27ed6cf4c0ac5767d18100cd1b8de4c057c79f38 Author: Jiri Olsa Date: Mon Aug 3 23:01:44 2026 +0200 bpf: Factor callchain_finalize function from __bpf_get_stack [ Upstream commit 014fbe5902dccdaef69114abdcdb15e3dbe55e34 ] The new callchain_finalize function calls the build-id retrieval (if needed) and zeroes the buffer. This makes things easier for preemption fix in following change. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-8-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit b61aacc66a1f6845ebc1450a406b1795af53ffc3 Author: Jiri Olsa Date: Mon Aug 3 23:01:43 2026 +0200 bpf: Factor callchain_store function from __bpf_get_stack [ Upstream commit cbb99938e7935c9f62c891573a4b09690e5e22de ] The new callchain_store function stores trace entries buffer into user supplied buffer. It covers both just-ip and buildid data. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-7-jolsa@kernel.org Stable-dep-of: f5d242825ca4 ("bpf: Clear buf on error in __bpf_get_task_stack") Signed-off-by: Sasha Levin commit b5a2907bdeced0949bcddc84b95ba7d4cb93841b Author: Cen Zhang Date: Wed Jun 24 17:53:10 2026 +0800 ocfs2: o2hb: quiesce negotiate handlers and timeout work [ Upstream commit 011291b70ba4832e136b7b581825b2bc0f525bf6 ] Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600 Link: https://lore.kernel.org/20260624095310.763763-3-zzzccc427@gmail.com Fixes: 34069b886f95 ("ocfs2: o2hb: add NEGO_TIMEOUT message") Fixes: e76f8237a2f7 ("ocfs2: o2hb: add NEGOTIATE_APPROVE message") Signed-off-by: Cen Zhang Assisted-by: Codex:gpt-5.5 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 073f51e39bed354452a057d38a4cc3952727c304 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 2e689bb5643cffb1b0cd7145236125b7f27bd6e0 Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:12 2026 -0300 perf libbfd: Fix memory leaks and NULL fclose in BPF disassembly [ Upstream commit fe3ab00d55aa56b4d55cbc1150448f0aadd6732c ] symbol__disassemble_bpf_libbfd() has four resource management bugs: 1. free(prog_linfo) leaks internal arrays. bpf_prog_linfo contains raw_linfo, raw_jited_linfo, nr_jited_linfo_per_func, and jited_linfo_func_idx pointers that are only freed by the proper destructor bpf_prog_linfo__free(). 2. open_memstream(&buf, &buf_size) allocates a dynamic buffer that the caller must free after fclose(). The function calls fclose(s) but never free(buf), leaking the stream buffer on every call. 3. args->line = strdup(srcline) is immediately consumed by disasm_line__new(args) which internally calls strdup(args->line) again via annotation_line__init(). The first strdup result is then overwritten by args->line = buf + prev_buf_size without being freed. 4. If open_memstream() fails, the error path jumps to 'out:' which calls fclose(s) with s == NULL — undefined behavior. Fix by using bpf_prog_linfo__free(), initializing buf to NULL, adding free(buf) after fclose(s), guarding fclose() against NULL, and removing the redundant strdup since annotation_line__init() makes its own copy. Fixes: 6987561c9e86eace ("perf annotate: Enable annotation of BPF programs") Reported-by: sashiko-bot Cc: Song Liu 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 61fab78599058b850f2b35e2156643e82c7a85e0 Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:11 2026 -0300 perf bpf: Add PROG_TAGS to required arrays in __bpf_event__print_bpf_prog_info() [ Upstream commit 38ba525335c4399b15c9be0f81de304e94ccb462 ] synthesize_bpf_prog_name() unconditionally dereferences prog_tags[sub_id] (line: u8 (*prog_tags)[BPF_TAG_SIZE] = (void *)(uintptr_t)(info->prog_tags)) but __bpf_event__print_bpf_prog_info() only requires JITED_KSYMS and JITED_FUNC_LENS in its required_arrays bitmask. If a crafted perf.data has the PROG_TAGS bit cleared (or the array was invalidated by bpil_offs_to_addr() bounds checking), info->prog_tags contains either zero or a raw file offset. Dereferencing it causes a NULL pointer dereference or an arbitrary memory read. Add PERF_BPIL_PROG_TAGS to required_arrays so the function returns early when prog_tags was not present or failed validation. Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()") Reported-by: sashiko-bot Cc: Song Liu 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 5161e7ef5b388005719c8441c734c9d3a7411dcf Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:10 2026 -0300 perf header: Use write lock when translating BPF prog info pointers [ Upstream commit 60f2f5b7650bb8779af3087ef429fad4ed74a5c8 ] write_bpf_prog_info() holds a read lock while temporarily mutating info_linear via bpil_addr_to_offs()/bpil_offs_to_addr(). Between these two calls, the pointers in info_linear contain file offsets instead of heap addresses. Concurrent readers holding the same read lock see the file offsets and dereference them as pointers. Use down_write()/up_write() instead of down_read()/up_read() to exclude concurrent readers during the addr-to-offset-to-addr translation window. Fixes: 63ac7968a1fb ("perf bpf: Save bpf_prog_info information as headers to perf.data") Reported-by: sashiko-bot Cc: Song Liu 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 731edc4d0d01b522a1ef54629346679fec2e2198 Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:09 2026 -0300 perf libbfd: Validate BPF prog info arrays before pointer cast [ Upstream commit 01765b456f850aed7475b37111f1c50bf76aaf51 ] symbol__disassemble_bpf_libbfd() casts info_linear->info.jited_prog_insns and info_linear->info.jited_ksyms to pointers without checking whether bpil_offs_to_addr() actually converted the file offsets. A crafted perf.data with PERF_BPIL_* bits unset but non-zero counts causes raw file offsets to be dereferenced as pointers. Add bitmask checks for PERF_BPIL_JITED_INSNS and PERF_BPIL_JITED_KSYMS before the casts, matching the validation added to bpf-event.c call sites. Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") Reported-by: sashiko-bot Cc: Song Liu 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 8040663c1dfdf15bd10761823f3c167fcdcd6860 Author: Farhan Ali Date: Wed Jul 29 11:11:16 2026 -0700 vfio/pci: Avoid mapping BARs for devices with non-mappable BARs [ Upstream commit 6edd69813b2d8c30c24a86052065a5dbf390a3cd ] vfio_pci_core_map_bars() calls pci_iomap() to set up BAR resources, but not all devices support having their BARs mapped by the CPU. The non_mappable_bars flag indicates that a PCI device's BARs cannot be accessed by the CPU. The ISM device on s390 is one such device. The BAR size for an ISM device is 256 TiB, and attempting to map the BAR will lead to warnings: vmalloc_node_range for size 281474976714752 failed: Address range restricted to 0x2110bab00000 - 0x21903ab00000 Use pdev->non_mappable_bars to skip pci_iomap() for such devices. This flag is set by the PCI core at enumeration time and already serves the same purpose in vfio_pci_probe_mmaps(). Fixes: 05f2a68b407a ("vfio/pci: Set up BAR resources and maps in vfio_pci_core_enable()") Reported-by: Christian Borntraeger Signed-off-by: Farhan Ali Reviewed-by: Niklas Schnelle Reviewed-by: Matthew Rosato Link: https://lore.kernel.org/r/20260729181116.1373-1-alifm@linux.ibm.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 720408d98d9fb3c91a12090436734c8c61f04545 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 8d7cbc6df9632d334b21c4be66ccdde76a08fb13 Author: Xie Yuanbin Date: Tue Jul 28 03:03:22 2026 +0100 ARM: 9484/1: enable interrupts when unhandled user faults are triggered [ Upstream commit e79ca91165d4fd18549c536abdb86101e889052f ] PREEMPT_RT requires interrupts to be enabled when sending signals. When do_DataAbort()/do_PrefetchAbort() triggers unhandled user faults, that is `inf->fn()` return a non-zero value, and the interrupts are not enabled within the hook function, force_sig_fault() will be called with interrupts disabled. This can be triggered by user programs executing the bkpt instruction, with kernel config CONFIG_PERF_EVENTS=n. Enable interrupts in do_DataAbort()/do_PrefetchAbort() when unhandled user faults are triggered to fix the issue. Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") Link: https://lore.kernel.org/20260629123349.134224-1-xieyuanbin1@huawei.com Suggested-by: Russell King Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Linus Walleij Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 8de56782d6e5ba7a9f8c820342dccde65502f93f Author: Karl Mehltretter Date: Fri Jul 24 08:05:31 2026 +0100 ARM: 9483/1: select HAVE_POSIX_CPU_TIMERS_TASK_WORK [ Upstream commit 8a58a41100ea377e978d99600ec24a9bd0273662 ] Commit c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") enabled PREEMPT_RT on ARM but did not select HAVE_POSIX_CPU_TIMERS_TASK_WORK. This leaves CONFIG_POSIX_CPU_TIMERS_TASK_WORK disabled, so CPU timers expire in hard IRQ context. On PREEMPT_RT this makes run_posix_cpu_timers() take the sleeping sighand->siglock: BUG: sleeping function called from invalid context at spinlock_rt.c:48 rt_spin_lock from lock_task_sighand lock_task_sighand from run_posix_cpu_timers run_posix_cpu_timers from update_process_times ARM handles TIF_NOTIFY_RESUME on all return-to-user paths, including v7-M. ARM32 KVM host support was removed by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support"), so the select need not be conditional on KVM. Select it to defer POSIX CPU timer expiry to task context. Reproduced with setrlimit(RLIMIT_CPU, ...) and a busy loop. The same path is used by setitimer(ITIMER_PROF or ITIMER_VIRTUAL) and POSIX CPU timers created with timer_create(). Assisted-by: Claude:claude-fable-5 Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") Signed-off-by: Karl Mehltretter Reviewed-by: Arnd Bergmann Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Russell King Signed-off-by: Sasha Levin commit da64b150e4b7bee615b33ab21f3137c31ec36922 Author: Linus Walleij Date: Sat Jul 4 21:15:55 2026 +0100 ARM: 9481/2: breakpoint: CFI breakpoints only on demand [ Upstream commit 8ed9bff906cf8036531d1559f10e82733a52b41f ] This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() "unhandled fault" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected. Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/ Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints") Reported-by: slipher Suggested-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Sasha Levin commit fa1b33fdab3e79dce83721ead3220200a2dbec22 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 c92686867638cda954fdb2bdbac8a75e3aa6eaae Author: Cheng Xu Date: Thu Jul 30 20:43:54 2026 +0800 RDMA/erdma: Hold QP references for AE and CM processing [ Upstream commit a52eeff32024f190b3bdc99088c7becccd4fa60b ] AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260730124357.12976-2-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4545f355654d044d35a31cd01cc46f491a8a7c36 Author: Cheng Xu Date: Thu Jul 30 20:43:53 2026 +0800 RDMA/erdma: Hold CQ references when processing EQ events [ Upstream commit 98df2aee1459ee1c62c70cbe9b370d2a532aea36 ] EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260730124357.12976-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 795f70fe748bdcb9f02a26ad865a9bfe1c208870 Author: Yuntao Wang Date: Wed Jul 29 15:17:37 2026 +0800 kbuild: fix modules.builtin(.modinfo) targets in the top-level Makefile [ Upstream commit 69ef27076d19297c0bf3bd22171fab8d87464a09 ] Commit 7a342e6c7735 ("kbuild: move modules.builtin(.modinfo) rules to Makefile.vmlinux_o") moved the modules.builtin(.modinfo) rules from link-vmlinux.sh to Makefile.vmlinux_o, and added the corresponding targets to the top-level Makefile. Commit 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") later moved these rules from Makefile.vmlinux_o to Makefile.vmlinux, but left the corresponding targets in the top-level Makefile unchanged. These modules.builtin(.modinfo) targets in the top-level Makefile should be moved alongside the vmlinux target, since they are now generated by Makefile.vmlinux. However, simply removing these trivial targets might be a better choice, as it makes the Makefile cleaner and avoids the need to keep them in sync across multiple files, reducing the chance of future mistakes. Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") Signed-off-by: Yuntao Wang Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260729071737.818007-1-yuntao.wang@linux.dev Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 3c5adf387155a5a1a6918ea0bbefc20b0f7d9dfc Author: Robertus Diawan Chris Date: Wed Jun 24 11:47:42 2026 +0700 modpost: prevent leak when early return no suffix .o in read_symbols() [ Upstream commit 9a5b76027ed91680e10f90111d9cba300f96d1ab ] The allocation for elf info symsearch and hdr from parse_elf() haven't been released when return because of modname didn't have suffix ".o". And it seems like the suffix ".o" check did not depends on parse_elf() to succeed first. So, move the suffix ".o" check before checking parse_elf() result to prevent resource leak when the modname didn't have suffix ".o" and return early. This is reported by Coverity Scan as "Resource leak". Fixes: 8c9ce89c5b63 ("modpost: simplify mod->name allocation") Signed-off-by: Robertus Diawan Chris Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260624044742.144852-1-robertusdchris@gmail.com Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit f3b6624d94210e15fe3d65abf40fd4cb6ff844cd 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 1b18270e3d8819c1567e3b777a0639985dec3e5f Author: Rafael J. Wysocki Date: Mon Aug 3 20:11:10 2026 +0200 intel_idle: Avoid using deep idle states during initialization [ Upstream commit 9eadbed788df453289b5927327bd22edb542f472 ] Commit c0f691388992 ("intel_idle: Use subsys_initcall_sync() for initialization") effectively made intel_idle initialize earlier which turns out to interfere with USB EHCI probing on some platforms [1]. Investigation led to the conclusion that this was related to allowing package idle states to be used earlier than before. Work around that issue by making intel_idle set a CPU latency QoS request to prevent package idle states from being used on all platforms supported by it for the duration of the device_initcall() initialization phase. Fixes: c0f691388992 ("intel_idle: Use subsys_initcall_sync() for initialization") Reported-by: Julian Silver Tested-by: Julian Silver Closes: https://lore.kernel.org/linux-acpi/3353bdf3-4f33-44b1-809b-b0378bee5816@gmail.com/ Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5120454.31r3eYUQgx@rafael.j.wysocki Signed-off-by: Sasha Levin commit 36fb592af353c55832e2cafe3fcfc3291be05f19 Author: Marek Marczykowski-Górecki Date: Mon Aug 3 05:08:02 2026 +0200 xen/xenbus: check otherend_id only after it has been initialized [ Upstream commit c76cbf348c7df077f93fa99a1225a527ce64cfa1 ] When device just got initialized (for example on module load), the otherend_id field is initialized only after xenbus_read_otherend_details() gets called. If xenstore watch triggers xenbus_dev_changed() before that, it might consider still zeroed otherend_id field (not matching actual xenstore content) as a sign of device state reset. It can happen because xenstore watch are handled in another thread (xenwatch), which can run in parallel to the initial device probe running at module load. In that case, it would call device_unregister(), which would deadlock against device probe from module init. Fix this by considering dev->otherend_id change only after dev->otherend is set (which happen after otherend_id is initialized). Fixes: e2dcf9065536 "xen/xenbus: better handle backend crash" Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260803030822.4104093-2-marmarek@invisiblethingslab.com> Signed-off-by: Sasha Levin commit 4fa8915f40f744c6db2a3c25b2ae7d2dd64c77b4 Author: Rafael J. Wysocki Date: Tue Aug 4 22:11:27 2026 +0200 thermal: hwmon: Remove hwmon class device along with its parent [ Upstream commit 2b57e24d34b2dfc43c81942bb359d6315bf302fb ] The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is "acpitz" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed. To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock. Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new "unlock" label. Link: https://lore.kernel.org/linux-pm/20260402021828.16556-1-liujia6264@gmail.com/ Fixes: f6b6b52ef7a5 ("thermal_hwmon: Pass the originating device down to hwmon_device_register_with_info") Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/5094738.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit 422a416041172af1ac610736d5f556d22b31b115 Author: Daniel Borkmann Date: Tue Aug 4 22:19:16 2026 +0200 bpf: Check load-acquire src ptr type before the load [ Upstream commit b87803391baa7e0bef60549d8841f12e549ad057 ] check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest). Fixes: c03bb2fa327e ("bpf: Fix out-of-bounds read in check_atomic_load/store()") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260804201917.253491-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 8fd17b394719a8053bfe757579c2a20f6910d47a Author: Eliot Courtney Date: Tue Aug 4 14:41:12 2026 +0900 gpu: nova-core: correct FRTS vidmem offset calculation [ Upstream commit 5c9deba5578db5a3ea05be8a3e4a59ecb08ee76f ] Currently, the frts vidmem offset is calculated based on the non-wpr heap size and pmu reservation size, but this is not right. The layout actually looks like this: | non-wpr heap | WPR2 .. FRTS | PMU reserved | ... | VGA workspace | It's just by coincidence + generous alignment that the values happened to match. Instead, define a per-architecture reserved size at the end of the framebuffer and use this plus the PMU reserved size to calculate the frts vidmem offset. Fixes: d317e4585fa3 ("gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot") Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-1-ac858b6a1935@nvidia.com [acourbot: add comment clarifying reason for testing pmu_reserved_size.] [acourbot: make fb_end_reserved_size() return u64.] Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 018169883d483720a929939ef332ab279902274f Author: John Hubbard Date: Wed Jun 3 16:50:34 2026 -0700 gpu: nova-core: clean up FSP FRTS comments [ Upstream commit 848bf57e98e1678ce7a49eb4e0bf0502da95dc07 ] Two comments in the FSP Chain of Trust message setup had drifted from the code. One referred to a variable name that no longer exists, and another described the unused sysmem FRTS fields as future work rather than explaining why they are zero. Update both to describe the code as it stands. Signed-off-by: John Hubbard Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260603235034.131354-3-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot Stable-dep-of: 5c9deba5578d ("gpu: nova-core: correct FRTS vidmem offset calculation") Signed-off-by: Sasha Levin commit b666585dfaf4169e2297edb39c52e579bc7fb9e6 Author: Zhi Wang Date: Thu Jun 4 14:43:32 2026 +0300 gpu: nova-core: factor out common FSP message header [ Upstream commit 56006044df9c65e8e179b236851bcdf4406f2164 ] Extract common MCTP + NVDM headers into FspMessageHeader, rename FspMessage to FspCotMessage, and update FspResponse to use the shared header. This prepares for adding new FSP message types. Signed-off-by: Zhi Wang Link: https://patch.msgid.link/20260604114339.1565660-3-zhiw@nvidia.com Signed-off-by: Alexandre Courbot Stable-dep-of: 5c9deba5578d ("gpu: nova-core: correct FRTS vidmem offset calculation") Signed-off-by: Sasha Levin commit c93fc0f7ba188d40174327f1983947e6fdd16cdf Author: Mika Westerberg Date: Tue Jul 28 13:27:28 2026 +0300 thunderbolt: stream: Fix possible short reads/writes [ Upstream commit af73a21a8eb460744d733fa5e2627935ed125081 ] Since copy_page_{to|from}_iter() advances the iterator and makes iov_iter_count() reflect the remaining bytes, subtracting nbytes from it makes it count it twice resulting in possible short reads/writes on a read/write spanning multiple frames. Fix this by using iov_iter_count() directly. Fixes: 6db21d817b43 ("thunderbolt: Add support for USB4STREAM") Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit de9eac1099f1065115a4abd5f3681a502699c280 Author: Mika Westerberg Date: Tue Jul 28 13:24:27 2026 +0300 thunderbolt: stream: Restore consumer if copying from iter fails [ Upstream commit 039701ea3d76ec004863fd7437fb56a9146cb094 ] In tbstream_dev_alloc_tx() if copying data from iterator fails we leave the consumer pointer as is wasting one entry in the ring. Fix this by restoring the consumer back in case of failure. Fixes: 6db21d817b43 ("thunderbolt: Add support for USB4STREAM") Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit ede92f86b6c454295e65bc16153caa76a61f3561 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:26 2026 +0200 arm64: dts: qcom: talos-evk: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit b426fedcef8c277574bd7beed0ae9d482c03605a ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 0f9e6db8a223 ("arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-28-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7b08069029696ecde81d32837eb5037f36391a4f Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:25 2026 +0200 arm64: dts: qcom: sa8155p-adp: Fix swapped USB and UFS QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 3b50c16faa8452fd7ff021919c669c7b38227ca4 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB and UFS QMP PHYs on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 12dd4ebda47a ("arm64: dts: qcom: Fix usb entries for SA8155p adp board") Fixes: 5b85e8f2225c ("arm64: dts: qcom: sa8155p-adp: Add base dts file") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-27-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 458864b9ef1ca8e98f84efc16150949b22e349c0 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:24 2026 +0200 arm64: dts: qcom: eliza-mtp: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 6b1195eeb204b455973fb05e10563a63bdd71c57 ] The QMP PHY expects the vdda-phy supply to be the lower voltage (~0.8V) and the vdda-pll supply to be the higher voltage (~1.2V), as used by the UFS QMP PHY on this SoC. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.15V to vdda-phy and 0.72V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 49dab7311f57 ("arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-26-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c12cf2252ddee393fb5e9f07fc4033532872a9c5 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:23 2026 +0200 arm64: dts: qcom: lemans: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 932113c3c77814b4001ad37ea4383b93bc385284 ] The QMP PHY expects the vdda-phy supply to be the lower voltage (~0.8V) and the vdda-pll supply to be the higher voltage (~1.2V), as used by the PCIe and UFS QMP PHYs on this SoC. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.14V to vdda-phy and 0.72V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 76326da895b8 ("arm64: dts: qcom: lemans: Refactor ride/ride-r3 boards based on daughter cards") Fixes: 7bd68ef80661 ("arm64: dts: qcom: lemans-evk: Enable first USB controller in device mode") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-25-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4a65a0ffc748afd219ddc2b7509c36bc029ef834 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:22 2026 +0200 arm64: dts: qcom: glymur: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit c3c6b388edba50aad0d41b0b2a5e50482e320611 ] The QMP PHY expects the vdda-phy supply to be the lower voltage (~0.8V) and the vdda-pll supply to be the higher voltage (~1.2V), as used by the DisplayPort QMP PHY on this SoC. But these two supplies are swapped for the USB QMP PHYs on this board, feeding 1.2V to vdda-phy and 0.72V/0.83V to vdda-pll. Fix it by swapping the two supplies back. Fixes: c8b63029455b ("arm64: dts: qcom: glymur-crd: Enable USB support") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-24-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 74d6524b34635758999fdbbcc0f373b47d307fe3 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:21 2026 +0200 arm64: dts: qcom: kaanapali: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit c1dfdea72a9f59b1bdad64b8ec9f918b6c1a721f ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: b2f036a67580 ("arm64: dts: qcom: kaanpaali: Add USB support for MTP platform") Fixes: 01d15f5f6996 ("arm64: dts: qcom: kaanpaali: Add USB support for QRD platform") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-23-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eb262afc7231e2c4c8488a114eb8262e5867f73c Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:20 2026 +0200 arm64: dts: qcom: sar2130p: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 9d883d21fc12c873eee2f864f706c38a289bef59 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 6339e41fa39b ("arm64: dts: qcom: sar2130p: add QAR2130P board file") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-22-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 407b05cf21eac29654b622effad09e9143c28ec8 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:19 2026 +0200 arm64: dts: qcom: sm8750: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 50c9658bc622888f9664a052fd98ef6026883ea5 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 2340f29e2b06 ("arm64: dts: qcom: sm8750: Add USB support for SM8750 MTP platform") Fixes: 530f824a4e18 ("arm64: dts: qcom: sm8750: Add USB support for SM8750 QRD platform") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-21-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 83db0e7a95f2fbb0b88ec531d8ecb5447e6fbc9c Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:18 2026 +0200 arm64: dts: qcom: sm8650: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 464fba94ac2e35b336e19c34336a07946da7128f ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 6fbdb3c1fac7 ("arm64: dts: qcom: sm8650: add initial SM8650 MTP dts") Fixes: a834911d50c1 ("arm64: dts: qcom: sm8650: add initial SM8650 QRD dts") Fixes: 01061441029e ("arm64: dts: qcom: sm8650: add support for the SM8650-HDK board") Fixes: df260487f33c ("arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-20-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bfd0c3600b6edcb176259f5dd70574eeed7e31ae Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:17 2026 +0200 arm64: dts: qcom: purwa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 7c1d0ef2969e16a97bd03e8340f35a78c889120d ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 64a0277c9876 ("arm64: dts: qcom: Add PURWA-IOT-SOM platform") Fixes: d3f600dc452d ("arm64: dts: qcom: Add Lenovo ThinkBook 16 G7 QOY device tree") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-19-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 069f1a1523d0245de0ae80b59d89c6aa9b0706ee Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:16 2026 +0200 arm64: dts: qcom: hamoa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 4458dcd38295c8bd13957637ba98132ba3f089b0 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 5098ae93ce44 ("arm64: dts: qcom: Add HAMOA-IOT-SOM platform") Fixes: af241225893a ("arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X") Fixes: ae5cee8e7349 ("arm64: dts: qcom: x1e80100-crd: Fix USB PHYs regulators") Fixes: 20676f7819d7 ("arm64: dts: qcom: x1e80100-qcp: Fix USB PHYs regulators") Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Fixes: 6516961352a1 ("arm64: dts: qcom: Add support for X1-based Asus Zenbook A14") Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree") Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14") Fixes: 0d72ccaa1e84 ("arm64: dts: qcom: Add support for X1-based Surface Pro 11") Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Fixes: 8cf65490cdb0 ("arm64: dts: qcom: Add dts for Medion SPRCHRGD 14 S1") Fixes: f5b788d0e8cd ("arm64: dts: qcom: Add support for X1-based Dell XPS 13 9345") Fixes: 7b8a31e82b87 ("arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows") Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-18-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8aad733a4bb8806b5e7b8647dc686a49ab90ff09 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:15 2026 +0200 arm64: dts: qcom: sc8180x: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 8e1877c41c2ee4ad245e1c26c98f3b4cb2585162 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 2ce38cc1e8fe ("arm64: dts: qcom: sc8180x: Introduce Primus") Fixes: 20dea72a393c ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-17-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 88ac1561a1ef2193ae731fa2808f57a666b8e165 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:14 2026 +0200 arm64: dts: qcom: sc7280: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit b3038aac412d14538f135e6509e657997fd6825d ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 97a5b73b7058 ("arm64: dts: qcom: sc7280-idp: Add device tree files for IDP2") Fixes: 116f7cc43d28 ("arm64: dts: qcom: sc7280: Add herobrine-r1") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-16-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a9783bec0db412f286a77e149fef765843bcd7f6 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:13 2026 +0200 arm64: dts: qcom: sc7180: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 2c45c4df3079acba14920b14286cebfea24ec603 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 0b766e7fe5a2 ("arm64: dts: qcom: sc7180: Add USB related nodes") Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Fixes: 4a9f8f8f2ada ("arm64: dts: qcom: Add Acer Aspire 1") Fixes: de8eed359759 ("arm64: dts: qcom: Add support for ECS LIVA QC710") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-15-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4cd993d91c8b7a7327a57d1362a60a62110867cf Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:12 2026 +0200 arm64: dts: qcom: sm7225-fairphone-fp4: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit a3b3a060b696d964c769a7d9dc5835c79e4fe964 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Reviewed-by: Luca Weiss Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-14-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dfc8d77f80789cd88f9a0dee60b1e10cd22bd4e9 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:11 2026 +0200 arm64: dts: qcom: qcs6490: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 83185fc5f51e7fa2d02f02e2504ad7b002c2d1d8 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts") Fixes: 1cde54c54b83 ("arm64: dts: qcom: qcs6490: Add Thundercomm AI Mini PC G1 IoT") Fixes: f055a39f6874 ("arm64: dts: qcom: Add qcs6490-rubikpi3 board dts") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-13-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 221300448bd1d883a67bf14a04d86d37e196a450 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:10 2026 +0200 arm64: dts: qcom: qcm6490: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit f6a787a5e238599f3543c3dccf0abd6030dd48e3 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 9af6a9f32ad0 ("arm64: dts: qcom: Add base qcm6490 idp board dts") Fixes: a319cf4a4b09 ("arm64: dts: qcom: qcm6490: Introduce the Particle Tachyon") Fixes: eee9602ad649 ("arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5") Fixes: 249666e34c24 ("arm64: dts: qcom: add QCM6490 SHIFTphone 8") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Reviewed-by: Luca Weiss Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-12-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 93c1c78f9dc26b057e02113e530b0fdf5e2fff13 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:09 2026 +0200 arm64: dts: qcom: qcs8550-aim300: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit c0ea3b6339881c2a5fff0830557b1279d9681036 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 0b12da4e28d8 ("arm64: dts: qcom: add base AIM300 dtsi") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-11-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 85f59f34757bd0269a5d00b86a979dbe7676b24f Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:08 2026 +0200 arm64: dts: qcom: sm8550: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit f35723d6b6a2f6d6fc3cf2fc3ff556436f76ebd4 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: b5e25ded2721 ("arm64: dts: qcom: sm8550: add support for the SM8550-HDK board") Fixes: 772e6bc4a0a9 ("arm64: dts: qcom: sm8550-mtp: Add USB PHYs and HC nodes") Fixes: d228efe88469 ("arm64: dts: qcom: sm8550-qrd: add QRD8550") Fixes: 39c596304e44 ("arm64: dts: qcom: Add SM8550 Xperia 1 V") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-10-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 64e223194230e2b9b90cb2e1d730544d590b34d9 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:07 2026 +0200 arm64: dts: qcom: sm8450: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 6469731fb66f40ab873bf4c9fd97d295b390e87f ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.91V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 067b2b3616cd ("arm64: dts: qcom: Add SM8450 HDK DTS") Fixes: 27a0d0b846d9 ("arm64: dts: qcom: sm8450-qrd: Enable USB nodes") Fixes: 1620676b85f1 ("arm64: dts: qcom: sm8450-nagara: Separate out Nagara platform dtsi") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-9-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d843ed6b412a6bff324b8d69409adb6b59a0b3b1 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:06 2026 +0200 arm64: dts: qcom: sm8350: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 65cd57115c379ff0d0a200ad5a857afb8042a63c ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 9208c19f2124 ("arm64: dts: qcom: Introduce SM8350 HDK") Fixes: c16160cfa565 ("arm64: dts: qcom: add minimal DTS for Microsoft Surface Duo 2") Fixes: 054b40a6111f ("arm64: dts: qcom: sm8350-mtp: enable USB nodes") Fixes: 5a077120bcf6 ("arm64: dts: qcom: sm8350-sagami: Wire up USB regulators and fix USB3") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-8-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d143fb29b0ca28bf03016c6220cfbc1818de6416 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:05 2026 +0200 arm64: dts: qcom: sm8250: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit d57a10f2ebcf327bdecf8bb26e9f330b17b0b1a6 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 91ed0e90fc49 ("arm64: dts: qcom: add sm8250 hdk dts") Fixes: 221f0ef37f55 ("arm64: dts: sm8250-mtp: enable USB host nodes") Fixes: 69cdb97ef652 ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)") Fixes: 264beb3cbd0d ("arm64: dts: qcom: sm8250-xiaomi-pipa: Add initial device tree") Fixes: 52c90664f122 ("arm64: dts: qcom: qrb5165-rb5: Add USB support") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-7-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9063b2373ac8c405be828a87441c33f4fb391543 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:04 2026 +0200 arm64: dts: qcom: sm8150: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 3a0c5af9fb0e835e90c4f2439dc4534301be8856 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 0ab1b2d10afe ("arm64: dts: qcom: add sm8150 hdk dts") Fixes: b33d2868e8d3 ("arm64: dts: qcom: sm8150: Add USB and PHY device nodes") Fixes: d1f781db47a8 ("arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo") Fixes: d0a6ce59ea4e ("arm64: dts: qcom: sm8150: Add support for SONY Xperia 1 / 5 (Kumano platform)") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-6-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1b3154a198b73fa661277af9bcb3f5ca7fd30540 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:03 2026 +0200 arm64: dts: qcom: sdm850: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit ef7b567f54c72a91dec3fb0bd5d80b8e956f7cd8 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: aab69794b55d ("arm64: dts: qcom: Add support for Huawei MateBook E 2019") Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630") Fixes: d4b341269efb ("arm64: dts: qcom: Add support for Samsung Galaxy Book2") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-5-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6071a3b06acefb62b6db06bb9fb0ed44835d7250 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:02 2026 +0200 arm64: dts: qcom: sdm845: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit ce18e4c1cfc77c2eda5f0b9839edac1b0e929c54 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c") Fixes: a678adbf2d22 ("arm64: dts: qcom: Add support for Pixel 3 and Pixel 3 XL") Fixes: 28ae8aa3923c ("arm64: dts: qcom: add device tree for LG G7 and LG V35") Fixes: cfe10d38aa1a ("arm64: dts: qcom: sdm845-mtp: Add nodes for USB") Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Fixes: 45882459159d ("arm64: dts: qcom: sdm845: add device tree for SHIFT6mq") Fixes: dd6459a0890a ("arm64: dts: qcom: split beryllium dts into common dtsi and tianma dts") Fixes: be497abe19bf ("arm64: dts: qcom: Add support for Xiaomi Mi Mix2s") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-4-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3db02fe87c95f3becb99a8675fe76b0338909126 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:01 2026 +0200 arm64: dts: qcom: sa8540p: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 1960614611142e4b57f8a4e276f36ff8b6db2a1d ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on these boards, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 519183af39b2 ("arm64: dts: qcom: add SA8540P and ADP") Fixes: 6be310347c9c ("arm64: dts: qcom: add SA8540P ride(Qdrive-3)") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-3-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 15ad83a26241e9fde82564d1ff260b305c4f1c70 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:00 2026 +0200 arm64: dts: qcom: sc8280xp-blackrock: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit ff7155df9a9543af1eb9722563e6dcda33c1a97d ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 16a7fed11714 ("arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-2-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8d951c93e4b19fb2990b7570de7b059465631f19 Author: Sayali Patil Date: Wed Jul 8 12:29:07 2026 +0530 selftests/mm: fix ternary operator precedence in ksm_tests [ Upstream commit 4e1fbffb3333626682a011db7c4b4e9e40ba96d4 ] The KSM selftest uses conditional expressions to skip accesses to merge_across_nodes on systems without NUMA support. However, the ternary operator is combined with logical OR without parentheses: a || numa_available() ? 0 : b || c Due to operator precedence rules, this is parsed as: (a || numa_available()) ? 0 : (b || c) instead of the intended: a || (numa_available() ? 0 : b) || c Add parentheses around the conditional expressions to ensure the correct evaluation order. Link: https://lore.kernel.org/ce859430287ed2642848c933a90eb9a69da361f0.1783446924.git.sayalip@linux.ibm.com Fixes: 9aa1af954db0 ("selftests: vm: check numa_available() before operating "merge_across_nodes" in ksm_tests") Signed-off-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0df56ab44ecf08d8569f3be3cbd382070ecf64d5 Author: Sayali Patil Date: Wed Jul 8 12:29:06 2026 +0530 selftests/mm: fix ksm NUMA merge test for systems with memoryless NUMA nodes [ Upstream commit 15828a150c5806869b7feb9e38ad2c0284fbf18a ] The KSM NUMA merge test allocates identical pages on different NUMA nodes and verifies KSM behavior with merge_across_nodes enabled and disabled. On systems with memoryless NUMA nodes, for example: #numactl -H available: 2 nodes (0,4) ..... node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 node 0 size: 14825 MB node 0 free: 1382 MB node 4 cpus: node 4 size: 0 MB node 4 free: 0 MB the test may attempt to allocate memory on a node without memory, causing numa_alloc_onnode() to fail and resulting in a spurious test failure. The test currently checks numa_num_configured_nodes() to determine whether sufficient NUMA nodes are available. However, configured nodes do not necessarily have memory. Reuse the existing get_first_mem_node() and get_next_mem_node() helpers to locate NUMA nodes that actually contain memory, and skip the test when fewer than two such nodes are available. Before patch: --------------------------- running ./ksm_tests -N -m 1 --------------------------- mbind: Invalid argument ok 1 KSM NUMA merging Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 ksm_tests -N -m 1 --------------------------- running ./ksm_tests -N -m 0 --------------------------- mbind: Invalid argument not ok 1 KSM NUMA merging Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 [FAIL] not ok 2 ksm_tests -N -m 0 # exit=1 After patch: --------------------------- running ./ksm_tests -N -m 1 --------------------------- At least 2 NUMA nodes with memory must be available ok 1 SKIP KSM NUMA merging Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 [PASS] ok 1 ksm_tests -N -m 1 --------------------------- running ./ksm_tests -N -m 0 --------------------------- At least 2 NUMA nodes with memory must be available ok 1 SKIP KSM NUMA merging Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 [PASS] ok 2 ksm_tests -N -m 0 Link: https://lore.kernel.org/78a3b0e3fb94004c0710872c5bab6f7381b7d63c.1783446924.git.sayalip@linux.ibm.com Fixes: e3820ab252dd ("selftest/vm: fix ksm selftest to run with different NUMA topologies") Co-developed-by: David Hildenbrand (Arm) Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Sayali Patil Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cd3c3baaa2564f6a752c2311c262b531212c321d Author: Sayali Patil Date: Wed Jul 8 12:29:05 2026 +0530 selftests/mm: handle EINVAL when configuring gigantic hugepages [ Upstream commit 5c4c48ff5aa1240a689d6508326a0ce42a71e9c4 ] Patch series "selftests/mm: avoid false failures in hugetlb and KSM tests", v3. This series fixes issues in the hugetlb and KSM MM selftest categories that can report failures when the prerequisites for the tests are not satisfied. Patch 1 updates the hugetlb selftest helpers to handle -EINVAL when attempting to configure gigantic HugeTLB pages via nr_hugepages. PowerPC hash MMU pSeries systems expose gigantic hugepage sizes but do not allow runtime allocation of such pages, causing the sysfs write to fail. Handle this case gracefully and continue running the test instead of aborting. Patch 2 fixes the KSM NUMA merge test on systems with memoryless NUMA nodes. The test currently relies on the number of configured NUMA nodes and may attempt allocations on nodes that have no memory, resulting in spurious failures. Use the existing helpers to identify NUMA nodes that contain memory and skip the test when fewer than two such nodes are available. Patch 3 fixes a pre-existing operator precedence issue in ksm_tests, where a ternary expression combined with logical OR operators could be evaluated differently than intended. Added parentheses to ensure the correct evaluation order. These changes improve handling of unsupported test configurations and unmet test prerequisites, avoiding spurious failures. This patch (of 3): Some MM selftests attempt to configure the amount of HugeTLB pages of different sizes by writing to nr_hugepages. PowerPC hash MMU pSeries systems advertise gigantic hugepage sizes but do not support runtime allocation of such pages, writes to the corresponding nr_hugepages file fail with -EINVAL. This causes the test to bail out even though the failure is due to a platform limitation rather than the functionality being tested. Ignore -EINVAL when configuring nr_hugepages so that tests continue to run on systems where gigantic hugepage allocation is unsupported. Before patch: ------------------------- running ./hugetlb-madvise ------------------------- TAP version 13 1..1 [INFO] detected hugetlb page size: 16777216 KiB [INFO] detected hugetlb page size: 16384 KiB ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 Bail out! /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages write(0) failed: Invalid argument Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 [FAIL] After patch: ------------------------- running ./hugetlb-madvise ------------------------- TAP version 13 1..1 [INFO] detected hugetlb page size: 16777216 KiB [INFO] detected hugetlb page size: 16384 KiB ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] Link: https://lore.kernel.org/cover.1783446924.git.sayalip@linux.ibm.com Link: https://lore.kernel.org/2e3b585cbb30b2fc495dcd49d75de6f6da61861c.1783446924.git.sayalip@linux.ibm.com Fixes: 27477b28b74f ("selftests/mm: hugepage_settings: add APIs to get and set nr_hugepages") Co-developed-by: David Hildenbrand (Arm) Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Sayali Patil Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 229ac3773516725bf10417dbe84a2218a0d8b9be Author: Hongfu Li Date: Thu Jul 9 16:18:43 2026 +0800 selftests/mm: fix memleak in migration benchmark [ Upstream commit f421d67d2c2367ca4b4b16f3a241a390b3ed501a ] Several early return paths in run_migration_benchmark() skip hmm_buffer_free(), leaking the buffer. Replace with a single cleanup label. Link: https://lore.kernel.org/20260709081843.1451202-1-lihongfu@kylinos.cn Fixes: 271a7b2e3c13 ("selftests/mm/hmm-tests: new throughput tests including THP") Signed-off-by: Hongfu Li Reviewed-by: David Hildenbrand (Arm) Reviewed-by: SJ Park Acked-by: Balbir Singh Reviewed-by: Lorenzo Stoakes Reviewed-by: Balbir Singh Reviewed-by: Lorenzo Stoakes (ARM) Cc: Hongfu Li Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2c2218560b6e28a63ff7834ba26d09ff8efdee39 Author: Pu Lehui Date: Mon Aug 3 01:39:34 2026 +0000 bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed [ Upstream commit 6655c409707ec8ce9ce0850ffe4fe02331fd4d9c ] A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error. Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260803013934.4036646-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 6282d47b24b0c98d08d02807d676a7f67b4c052e 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 cd07aef510ac6a2873e01f9ddddc5492490b0067 Author: Krzysztof Wilczyński Date: Mon Jul 20 21:15:41 2026 +0000 PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers [ Upstream commit 747b9bbbbdfdee51aee2456388f9b94b5086de4d ] Currently, the legacy I/O and memory sysfs handlers do not check security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and legacy_mem files unprotected when the kernel is locked down. Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") added the check to pci_write_config(), pci_mmap_resource(), and pci_write_resource_io() to prevent userspace from programming DMA-capable hardware that could be used to modify kernel code, but did not cover the legacy handlers. As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove. Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and pci_mmap_legacy_io(). These generic handlers cover both architectures that define HAVE_PCI_LEGACY (such as Alpha and PowerPC). Fixes: eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") Signed-off-by: Krzysztof Wilczyński [bhelgaas: add Link] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260720211541.1509744-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 2fae17fd4fe3a2fdf868a6c9b8bda0d466ea8871 Author: Krzysztof Wilczyński Date: Mon Jul 20 20:46:24 2026 +0000 PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap [ Upstream commit bad94d3d18c600cfe2c24c17b1825db4b8795e3e ] Currently, mmap() of a resourceN file for an I/O BAR fails with -ENODEV on architectures where arch_can_pci_mmap_io() is 0, such as x86, because the attribute has no mmap callback there and the error comes from the generic kernfs dispatch. This is a side effect of commit e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space"), which removed the mmap callback from the I/O resource attribute on these architectures. Previously the request reached the architecture mmap code and failed with -EINVAL, and the same commit deliberately kept -EINVAL for the identical operation on the procfs interface, so the two PCI userspace interfaces have disagreed ever since. Add a pci_mmap_resource_io_unsupported() callback that returns -EINVAL and use it as the mmap handler of the I/O resource attribute when arch_can_pci_mmap_io() is 0, so the failure is produced deliberately by PCI code, consistent with the procfs interface and with the behaviour before e854d8b2a82e. Architectures where arch_can_pci_mmap_io() is non-zero keep the real pci_mmap_resource_uc() handler and are unaffected. The mmap() fails either way. Only the reported error changes from -ENODEV to -EINVAL. Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260720204624.1503794-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit fdfb3a1f5c06ee81e35f7c021addb665a6ae692f Author: Jackie Dong Date: Tue Aug 4 20:36:37 2026 +0800 ALSA: hda/realtek: ALC269 fixup for Yoga/Legion Mic noise [ Upstream commit 6cd3d2c82651a9e77aa5b1b9c12aa918c0d6c0a9 ] Lenovo Yoga Pro 7 15ASH11 and Legion 7 15ASH11 use the same audio subsystem implementation and support only analog microphone. Limit Amp-In Vals to 0x00 and 0x01 for the internal microphone to reduce recording noise. Values 0x02 and 0x03 introduce significant noise on them. Fixes: 17065203e1bc ("ALSA: hda/realtek:ALC269 fixup for Yoga Pro 7 15ASH11 mic mute LED") Signed-off-by: Jackie Dong Link: https://patch.msgid.link/20260804123637.21001-1-xy-jackie@139.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8d8d3d4a6483e6395c0011e327aa87f8c7d2a389 Author: Imran Shaik Date: Sat Jul 18 18:26:19 2026 +0530 arm64: dts: qcom: agatti: Add missing CX power domain to DISPCC [ Upstream commit 26d7b23caa4b1d8208e28c5981a85cf83e658e7c ] Add the missing power-domains property to associate DISPCC with CX rail. This is to ensure the genpd performance state votes on the GDSC to get propagated to the CX rail and to avoid the rail under-voltage conditions. Fixes: a2b32096709d ("arm64: dts: qcom: qcm2290: Add display nodes") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-12-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b681c740e6d645f7d7477e9208db57917c6c0fbc Author: Christoph Hellwig Date: Tue Aug 4 05:39:25 2026 -0700 block: handle nogenerate/noverify properly in fs-integrity [ Upstream commit 3bf9a21e7bccfd8c35b440efd114c61cc9838a41 ] Check the BIP_CHECK flags before generating or verifying PI information, otherwise this can be incorrectly called for non-PI metadata and cause generation of incorrect metadata and crashed in the verification handler. The new behavior matches that of the block layer auto-generated metadata. Fixes: 0bde8a12b554 ("block: add fs_bio_integrity helpers") Signed-off-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Reviewed-by: Anuj Gupta Link: https://patch.msgid.link/20260804123928.736596-4-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7ccd6b6448cdc7e6232ddab84a04e26763761bd6 Author: Christoph Hellwig Date: Tue Aug 4 05:39:24 2026 -0700 block: lift BIP_CHECK_FLAGS to include/linux/bio-integrity.h [ Upstream commit 738f01912a1ad68c81a6aed06cac94e09b5f609d ] To allow for users outside of bio-integrity-auto.c. Also add a little comment explaining it. Signed-off-by: Christoph Hellwig Reviewed-by: Anuj Gupta Reviewed-by: Kanchan Joshi Link: https://patch.msgid.link/20260804123928.736596-3-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 3bf9a21e7bcc ("block: handle nogenerate/noverify properly in fs-integrity") Signed-off-by: Sasha Levin commit 70af551b7fcdf1203e31cf9421cf11dbb9b3d82b Author: Christoph Hellwig Date: Tue Aug 4 05:39:23 2026 -0700 block: remove bip_should_check [ Upstream commit 6c13180dba60f835d6909e2a3b4f50862de156c6 ] There is no benefit in using this helper over the simple flags check. Signed-off-by: Christoph Hellwig Reviewed-by: Anuj Gupta Reviewed-by: Kanchan Joshi Link: https://patch.msgid.link/20260804123928.736596-2-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 3bf9a21e7bcc ("block: handle nogenerate/noverify properly in fs-integrity") Signed-off-by: Sasha Levin commit 6e959e7691c642c08a5e12395986bdbb3f8dfd1a Author: Yang Xiuwei Date: Thu Jul 30 09:09:10 2026 +0800 ublk: clear auto buf reg before updating io->buf in batch commit [ Upstream commit af0955c8f26aa0f02e534084bc9948a69c9e7ce0 ] ublk_batch_commit_io() stored the new auto_buf into io->buf before calling ublk_clear_auto_buf_reg(). Clear takes the unregister index from io->buf.auto_reg, so it could drop the new slot and leave the old registered buffer behind. Fixes: 1e500e106d5a ("ublk: handle UBLK_U_IO_COMMIT_IO_CMDS") Signed-off-by: Yang Xiuwei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 30810bdf273b4c93f8731b96a7204f33e052180d Author: Andreas Kemnade Date: Thu Jul 2 17:27:11 2026 +0200 drm/omap: dsi: Do not copy isr table [ Upstream commit 97c03b32b28a9f7f13f768f2b06e1eaafe850e66 ] To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. Fixes: 4ae2ddddf44cd ("OMAP: DSS2: DSI: Add ISR support") Signed-off-by: Andreas Kemnade Link: https://patch.msgid.link/20260702-dsi-uaf-v2-1-dbb4aa0f0b8e@kemnade.info Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 04e4d18e7fea9e64ecef26a45f4c9fcafeee7c13 Author: Inochi Amaoto Date: Mon May 11 14:38:17 2026 +0800 riscv: dts: sophgo: cv180x: Allow the DMA multiplexer to set channel number for DMA controller [ Upstream commit 5011466bade64483bb52bc4a926719d6794e6dab ] Change the DMA controller compatible to the sophgo,cv1800b-axi-dma, which supports setting DMA channel number in DMA phandle args. This dts change does not break backward compatibility as a fallback compatiable string is added. Fixes: 514951a81a5e ("riscv: dts: sophgo: cv18xx: add DMA controller") Reported-by: Anton D. Stavinskii Closes: https://github.com/sophgo/linux/issues/9 Tested-by: Anton D. Stavinskii Link: https://patch.msgid.link/20260511063818.463877-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit 7ae71629357d0a6d0bdadb929c7b296d5b7e61c2 Author: Ning Ding Date: Mon Aug 3 04:26:08 2026 -0700 bpf: Invalidate RCU pointers after final spin unlock [ Upstream commit 180c7000712db77063b3a26f4c97e7dd9038f449 ] In a sleepable BPF program, a spin lock can provide the only RCU protection for a kptr. The final bpf_spin_unlock() ends that protection, but the verifier leaves the pointer valid. Another CPU can then free the object before the pointer is used. A capability-limited runtime PoC triggered a task_struct use-after-free in __bpf_get_task_stack(). Record whether the program is in an RCU-protected context before releasing the lock. Invalidate RCU-protected pointers only when the unlock leaves the final such context. This preserves valid pointers in non-sleepable programs and inside an explicit RCU read-side section. Fixes: 5861d1e8dbc4 ("bpf: Allow bpf_spin_{lock,unlock} in sleepable progs") Assisted-by: Codex:gpt-5.6-sol Assisted-by: ChatGPT:GPT-5.6-Pro Signed-off-by: Ning Ding Link: https://lore.kernel.org/bpf/20260803112615.3362122-2-dingning04@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 7565e44507634514e3e1899d3acad3de43f7a2c1 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 530a9d5ef831a0049dad9a6b2b92d02301352c38 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 0e7459abff46e28e64367057038ef8607e63f599 Author: Dmitry Antipov Date: Thu Jul 9 09:01:01 2026 +0300 ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full() [ Upstream commit d48ace65322001b41bb5322442a21425ef4407d4 ] This reverts commit 58b6fcd2ab34 ("ocfs2: mark inode bad upon validation failure during read"). Since 'make_bad_inode()' resets inode type to S_IFREG, doing this for directory inode during active VFS lookup is likely to confuse the latter, including VFS_BUG_ON_INODE() triggered in this case. Link: https://lore.kernel.org/20260709060101.207262-1-dmantipov@yandex.ru Fixes: 58b6fcd2ab34 ("ocfs2: mark inode bad upon validation failure during read") Signed-off-by: Dmitry Antipov Suggested-by: Al Viro Reported-by: syzbot+d222f4b7129379c3d5bc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d222f4b7129379c3d5bc 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 9f4129b6905b7d638bbc9eb8013c3989cbe30b7e Author: Cen Zhang Date: Sun Jul 5 10:53:11 2026 +0800 ocfs2: validate external xattr entries when reading metadata [ Upstream commit 2cf82b46d5e43be0dfbaac7fa1073cec2fc1f5e6 ] ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Link: https://lore.kernel.org/20260705025311.3429854-3-zzzccc427@gmail.com Fixes: cf1d6c763fbc ("ocfs2: Add extended attribute support") Fixes: 0c044f0b24b9 ("ocfs2: Add xattr bucket iteration for large numbers of EAs") Signed-off-by: Cen Zhang Assisted-by: Codex:gpt-5.5 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 3fd45b24879fa4885b66a582a6e47eda67f11310 Author: Cen Zhang Date: Sun Jul 5 10:53:10 2026 +0800 ocfs2: validate inline xattrs during inode block validation [ Upstream commit 8914a3330b72378136c2c02d6328a826f6abdad7 ] Patch series "ocfs2: validate xattr entry bounds", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0 Link: https://lore.kernel.org/20260705025311.3429854-1-zzzccc427@gmail.com Link: https://lore.kernel.org/20260705025311.3429854-2-zzzccc427@gmail.com Fixes: cf1d6c763fbc ("ocfs2: Add extended attribute support") 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 67201231eeccd9973b1856a2c065b4b4a4a73fe8 Author: Calvin Owens Date: Mon Jul 6 10:19:07 2026 -0700 pps-gpio: remove dead capture_clear code [ Upstream commit b899e0279f90c3ce4099d68b989dd27861cc5c4f ] The capture_clear field is never set, and all code conditional on it being set has been unreachable since the platform data logic was removed from pps-gpio in ee89646619ba ("pps: clients: gpio: Get rid of legacy platform data"). I think the only logical thing to do here is to remove it all, since no in-tree code ever actually used it in the first place, and it has been completely dead code for over five years (since v5.13). Sashiko asked some questions about the gpiod_get_value() call which caused me to look deeper and figure this out, but it did not actually notice capture_clear is never set. Link: https://lore.kernel.org/f70196bafcf75d9782dd36ed784e42345b6e8a1b.1783355507.git.calvin@wbinvd.org Fixes: ee89646619ba ("pps: clients: gpio: Get rid of legacy platform data") Signed-off-by: Calvin Owens Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=1 Acked-by: Rodolfo Giometti Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 77a6bdb97e02acd23d69d65e68313cd2043d7ab5 Author: Michael Byczkowski Date: Mon Jun 1 17:44:09 2026 -0700 pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded handler [ Upstream commit 93781560b2fdd26fa8499d64db8a95a07e1dc902 ] Split the pps-gpio interrupt handler into a primary (hardirq) handler that captures the PPS timestamp at interrupt entry, and a threaded handler that processes the event. This produces the same two-part handler structure on both PREEMPT_RT and non-RT kernels. On non-RT kernels the threaded portion runs immediately after the primary, with no behavioral change compared to the previous single-handler implementation. On PREEMPT_RT, where interrupt handlers are force-threaded by default, the previous single-handler implementation captured the timestamp inside the threaded portion, after IRQ-thread scheduling delay. With the split, the timestamp is captured in true hardirq context as it is on non-RT kernels, eliminating a significant source of PPS jitter on RT systems. Link: https://lore.kernel.org/2e32729029fbf6977ecf04665eb00f2efd3e2c17.1780359378.git.calvin@wbinvd.org Signed-off-by: Michael Byczkowski Signed-off-by: Calvin Owens Reviewed-by: Sebastian Andrzej Siewior Tested-by: Michael Byczkowski Tested-by: Calvin Owens Acked-by: Rodolfo Giometti Signed-off-by: Andrew Morton Stable-dep-of: b899e0279f90 ("pps-gpio: remove dead capture_clear code") Signed-off-by: Sasha Levin commit a31e768d2e4afe72c6e4175a26e26ab8fc7f0831 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 13d0dfd5d5f3594ecda60c531293df8d03a9b7da 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 70d7bb7a0be033e5ebe8a2c48974692b1318891c Author: Cen Zhang Date: Tue Jun 16 15:49:31 2026 +0800 ocfs2/cluster: keep heartbeat local node stable [ Upstream commit 688bc88e2046dd6ce81ce18079b5254cb8dadc0e ] o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30 Link: https://lore.kernel.org/20260616074931.3774929-1-zzzccc427@gmail.com Fixes: a7f6a5fb4bde ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang 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 Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 653d22269a8b83b491f7f186a5d7872f14e6ddca Author: Yang Xiuwei Date: Thu Jul 30 09:09:09 2026 +0800 ublk: validate auto buf reg before taking uring_cmd [ Upstream commit ca5a01eee34c7cbe0f531a613b0292a3ad1a419b ] With UBLK_F_AUTO_BUF_REG, invalid sqe->addr can fail after ublk_fill_io_cmd() has set UBLK_IO_FLAG_ACTIVE. The uring_cmd is completed while the tag stays active, which can hang teardown. Split validation from buffer apply so the check has no side effects, then take the uring_cmd and store the already-validated buffer. Apply the same order in FETCH so io->buf is not written before __ublk_fetch() state checks. Fixes: 52460dda3a77 ("ublk: move auto buffer register handling into one dedicated helper") Suggested-by: Caleb Sander Mateos Signed-off-by: Yang Xiuwei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit af9a009ed49676f67b0bbee4af268444a1eea95b Author: Caleb Sander Mateos Date: Wed Jul 29 11:10:40 2026 -0600 ublk: check for ublk_unmap_io() returning 0 [ Upstream commit 24fd3706178f1ae5501fd1ff9036e170ed0665ba ] If the userspace ublk server passes an unmapped address as the data buffer for a completed ublk read, ublk_unmap_io() will return 0 indicating no bytes could be copied. Currently, this will result in calling blk_update_request() with nr_bytes=0, which doesn't seem supported. Fail the I/O with BLK_STS_IOERR in this case instead. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260729171041.45061-3-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5ac6019cb78e98c9608fda72726b36ddf8474dd7 Author: Caleb Sander Mateos Date: Wed Jul 29 11:10:39 2026 -0600 ublk: check import_ubuf() return value [ Upstream commit 3831568792af75b6523fa93bb91560e29189cf55 ] import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages(). Fixes: 981f95a571e3 ("ublk: cleanup ublk_copy_user_pages") Reported-by: Ming Lei Signed-off-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260729171041.45061-2-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b783da6e32c27844eb0e75e3930c74f6703b7e85 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 7a578afab9e93177e29f09e393bfcc54708f30b4 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 29db15ba44936d0ce1a55988c291dd2bb7947dc6 Author: Tao Cui Date: Mon Jul 20 17:37:24 2026 +0800 block/blk-iolatency: account per-cpu latency stats over possible CPUs [ Upstream commit e0698304bd4a833d6d5a7b6582515e36b1ec3ea7 ] iolatency_check_latencies() and iolatency_ssd_stat() iterate a blkg's per-cpu latency stats with for_each_online_cpu(). When a CPU that has accumulated io.latency samples goes offline, its bucket is skipped: the check loop (which also resets) neither sums nor clears it, and the show path under-reports. On re-online the stranded samples are flushed into a later check window, which can trigger a spurious throttle/scale adjustment. Fixes: d70675121546 ("block: introduce blk-iolatency io controller") Fixes: 1fa2840e56f9 ("blk-iolatency: use a percentile approache for ssd's") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-3-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 834fbb747ced4680a3ec3915dc555871fc5ad0de 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 d8c872901e6459339374e9eea80aa919176c2ccd Author: Zheng Qixing Date: Sun Aug 2 19:25:19 2026 +0800 blk-cgroup: skip dying blkg in blkcg_activate_policy() [ Upstream commit 5e9220389920f33b6a804d50c548cd0cd1b04634 ] When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed. Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") Signed-off-by: Zheng Qixing Reviewed-by: Tang Yizhou Signed-off-by: Yu Kuai Reviewed-by: Tao Cui Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260802112525.3933753-4-yukuai@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2cf9f50a38c1839e549a08e22aa35e8d69e2c8fd Author: Zheng Qixing Date: Sun Aug 2 19:25:18 2026 +0800 blk-cgroup: fix race between policy activation and blkg destruction [ Upstream commit 5313d4d41739b0cb63000747c97bb1217ac45f3e ] When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility. Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") Signed-off-by: Zheng Qixing Reviewed-by: Tang Yizhou Signed-off-by: Yu Kuai Reviewed-by: Tao Cui Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260802112525.3933753-3-yukuai@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f97022fefe6eb06ee18549d603420440f2959802 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 c20cf591d9231481fff26d6a84d785cf1a8027d4 Author: Zxyan Zhu Date: Wed Jul 29 15:42:36 2026 +0800 net: stmmac: Skip PHY attach if custom PCS is in use [ Upstream commit af4d934164457f0578bf90e92ae0fcc5348260cb ] When a platform provides a custom PCS via the pcs_init callback, the MAC's phylink_pcs is already configured. In this case, no traditional PHY device is needed. Without this, stmmac_init_phy() falls through to the no-phy-node path and errors out with "no phy found" when the DT has no phy-handle for such interfaces. Skip the PHY attach when priv->hw->phylink_pcs is set and phy_addr is invalid. Fixes: f0ef433fc264 ("net: stmmac: introduce pcs_init/pcs_exit stmmac operations") Signed-off-by: Zxyan Zhu Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260729074237.2624940-2-zxyan0222@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ad0fd538503a24b0d3805fbfd012f8fb8021c81 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 0649178f3cedbd7ec53b952288e3440140b60c8d 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 fe73809bc314f23933c9a1fb57c0082f9138f918 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 b75ee915ab99f68c9d9f09b69b95aa09d7a4f2cd Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:05 2026 -0300 perf arm-spe: Reject zero nr_cpu in metadata to prevent division by zero [ Upstream commit d67241d43b709af4d13051bb8494892b654aba41 ] arm_spe__alloc_metadata() reads nr_cpu from the auxtrace_info priv array without validation. When a crafted perf.data provides nr_cpu=0, the per_cpu_sz calculation divides by zero: per_cpu_sz = (metadata_size - (hdr_sz * sizeof(u64))) / (*nr_cpu); Reject nr_cpu <= 0 early, before the division. The caller already treats NULL return with metadata_ver != 1 as a parse failure. Fixes: 7842a4b6ff698 ("perf arm-spe: Support metadata version 2") 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 e25897916844762beaf59b0bbbf365f8dedb8f5b 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 bbf8a944b007c163d192ef957af49ee371eb20c1 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 68b37d885e88679bd7fe116371a43f11bb62e24b 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 d18a40a72b5024772a58400c6af3cf0628156efb 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 ef81d735d57963cd7bc8c96986d6e0fd6386932e 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 d10a68ac87683f2cd5fe12927710b38531111322 Author: Chao Huang Date: Wed Jul 22 17:36:54 2026 +0800 HID: i2c-hid: goodix: Disable VDD on VDDIO enable failure [ Upstream commit 8e2c560faea0220664169f7be4b498915ea1469f ] If enabling VDDIO fails after VDD has been enabled, the power-up path returns without disabling VDD. This leaves the regulator enabled and its enable count unbalanced. Disable VDD before returning the VDDIO error. Fixes: eb16f59e8e58 ("HID: i2c-hid: goodix: Add mainboard-vddio-supply") Signed-off-by: Chao Huang Reviewed-by: Douglas Anderson Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b5fc0267ed8408cb7e4c6134c83b27eba447b442 Author: Rosalie Wanders Date: Thu Jul 9 16:12:03 2026 +0200 HID: sony: add missing __packed to struct with static_assert() [ Upstream commit 091c05c184f3a75a275ccc7ae29e17125dfaa661 ] Fixes: 4b9c410e7d6d ("HID: sony: fix style issues") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607091026.R9Pxd3PG-lkp@intel.com/ Signed-off-by: Rosalie Wanders Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 93c5cc35bcd9f62db589a21945b49691dccdd99d Author: Vicki Pfau Date: Wed Jul 29 21:12:33 2026 -0700 HID: steam: Reject short reads [ Upstream commit 33ff7b49c38b39b1f3d27db508ac0720fb25c08a ] Steam Controller FEATURE reports encode the size of the message in the message itself. Previously we were trusting that the size reported matched the size we actually read, leading to a potential issue with short reads. Instead, we should actually verify the length of the read. Fixes: c164d6abf384 ("HID: add driver for Valve Steam Controller") Reported-by: syzbot+75f3f9bff8c510602d36@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=75f3f9bff8c510602d36 Signed-off-by: Vicki Pfau Link: https://syzkaller.appspot.com/bug?extid=75f3f9bff8c510602d36 Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit dc766ca718ab56266560248f2aa2fc414f249c0f Author: Vicki Pfau Date: Wed Jul 29 21:12:31 2026 -0700 HID: steam: Improve logging and other cleanup [ Upstream commit de435b770cd9492b803346b84df69fe345b845f2 ] Adds more logging as appropriate, reindents an enum to match surrounding style, as well as cleaning up some places where we can use guard() instead of doing locking and unlocking manually. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit fdc4ef7a4bfe7b3fb3f77c0a20ef10858643f8cf Author: Vicki Pfau Date: Wed Jul 29 21:12:27 2026 -0700 HID: steam: Add support for sensor events on the Steam Controller (2015) [ Upstream commit 2eb7cf02b52156ebd19c7c14a7f5228c6adfcf97 ] Sensor support was added for the Steam Deck previously, but Steam Controller sensor events were never added. This adds that missing support, bringing Steam Controller support much closer to feature parity with things like SDL and Steam itself. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit 5181f83da9227cf12873bb83610c75f9cc96efe0 Author: Vicki Pfau Date: Wed Jul 29 21:12:26 2026 -0700 HID: steam: Rename some constants that got renamed upstream [ Upstream commit 6afec3c8fff2af0050ca802c9b731303ce0e2b8e ] SETTING_MOUSE_POINTER_ENABLED was renamed to SETTING_LIZARD_MODE upstream. SETTING_GYRO_MODE was renamed to SETTING_IMU_MODE in an older commit, but the associated enum was overlooked. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit de102444a5385a2b09baf7d563f0b4af4b3ddcf0 Author: Vicki Pfau Date: Wed Jul 29 21:12:25 2026 -0700 HID: steam: Refactor and clean up report parsing [ Upstream commit 3d3c6ab5b07e16ed73070076e4b7f5130da2404f ] This switches from a parsing style where each button or axis is parsed individually out of a report using !!(byte & BIT(x)) style. This commit switches it to a mostly unified approach of defining a list of individual mappings in an array and passing it to a function that handles all of the extraction. Theoretically this is more lines, but in practice it results in (subjectively) cleaner code. Some exceptions still need to be made for things like handling the lizard mode toggle key, but in general there's a lot less manual code. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit 7b5ae8d815f7a080274d92ec74acc08267560ef0 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 b85d1000eb8842768970f2fd0a8fd362472d02d5 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 4eff0ad8128b8000c5529e9f9cf338c4e865e482 Author: 谢致邦 (XIE Zhibang) Date: Tue Jun 30 05:04:21 2026 +0000 HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver [ Upstream commit fd7c67d05fb695b1deb07f9e213dd7e80e3a8427 ] Move the _DSM call that gets the HID descriptor address from i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI and the new PRP0001 driver can use it. While refactoring, move the blacklist check and the _DSM call to the top of probe() to avoid a pointless alloc when the device is blacklisted or does not implement the _DSM. Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but lack "hid-descr-addr" from the _DSD and provide the HID descriptor address only through an ACPI _DSM. The OF driver fails to probe them because it requires hid-descr-addr. Add a new driver that handles these devices by calling the shared _DSM helper. Link: https://lore.kernel.org/tencent_F6FC553D1BB737FC00062AD0FEF43C580F0A@qq.com Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 13378c9ac0a1bcdf49ba158e4199594aafb589cd Author: Haoxiang Li Date: Tue Jun 23 14:52:00 2026 +0800 HID: logitech-hidpp: Fix FF device cleanup on init failure [ Upstream commit dd5be4d9ce2dfc4d4a4527ef7d31d21a78e3cdac ] hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue. If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds. Fixes: ff21a635dd1a ("HID: logitech-hidpp: Force feedback support for the Logitech G920") Signed-off-by: Haoxiang Li Reviewed-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5c288cc441a2cf7bc755e6cd504038641e94a2ac Author: Denis Benato Date: Fri Jun 19 00:11:01 2026 +0000 HID: asus: fix a off-by-one in mcu_parse_version_string() validation [ Upstream commit 2a767bd3e0b7277718a9a604cbe53e42830f025d ] In mcu_parse_version_string() a size validation for response is stricter that it needs to be: relax the check by one byte. The device always answer with a greater byte count so this does not introduce visible changes. Fixes: ("hid-asus: check ROG Ally MCU version and warn") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 744b3f930c1173ad57f49b614fc875d8d2715396 Author: Denis Benato Date: Fri Jun 19 00:10:59 2026 +0000 HID: asus: refactor the two workqueues and init sequence [ Upstream commit 47669bec44fe12fe2c7adf2b299e980d7935a2ce ] Multiple issues have been found within the hid-asus driver: - unchecked size in asus_raw_event() - unclean teardown of asus_probe on failure - possible use-after-free in asus_probe - multiple workqueue used for jobs where one was enough - sleeping calls in atomic context - packets of incorrect size being sent to the keyboard controller Join the two workqueues into one reusing the stopping mechanism of the brightness workqueue, use the joined workqueue to also move the asus_wmi_send_event() sleeping call away from atomic context and add a size check in asus_raw_event(). Fixes: f631011e36b8 ("HID: hid-asus: Implement fn lock for Asus ProArt P16") Fixes: 1489a34e97ef ("HID: asus: Implement Fn+F5 fan control key handler") Fixes: b34b5945a769 ("HID: asus: listen to the asus-wmi brightness device instead of creating one") Reported-by: sahiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260613154732.60A4B1F000E9@smtp.kernel.org/ Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b712b4135ce45bc241a544bd469205c0766e5baf Author: Niklas Cassel Date: Thu Jul 30 15:31:26 2026 +0200 PCI: dwc: ep: Fix unmap potentially unmapping the wrong iATU [ Upstream commit 9de09b807a1942d179ac5dbcb4982b5301dcc8fd ] The MSI path in dw_pcie_ep_raise_msi_irq() keeps its outbound iATU window mapped across writes as a cache. The MSI-X path in dw_pcie_ep_raise_msix_irq() maps and unmaps a window around every write. Both use the same local aperture, ep->msi_mem_phys, as the CPU side address that the iATU translates to the host's MSI or MSI-X target. If dw_pcie_ep_raise_msi_irq() has cached its mapping and dw_pcie_ep_raise_msix_irq() is then called, dw_pcie_ep_map_addr() allocates a fresh outbound window for the MSI-X target. It does not notice that ep->msi_mem_phys is already mapped by the MSI window, because dw_pcie_ep_outbound_atu() only looks for a free window and does not deduplicate by address. The controller now has two iATU windows whose outbound_addr[] entry equals ep->msi_mem_phys. When dw_pcie_ep_raise_msix_irq() later calls dw_pcie_ep_unmap_addr() to tear down its own window, the lookup in dw_pcie_find_index() walks ob_window_map in ascending index order and returns the first match. That is the MSI window, since it was mapped first. The MSI window is torn down, the MSI-X window is left in place, and ep->msi_iatu_mapped is never cleared. The next MSI writel() therefore takes the cached fast path, writes into an aperture whose iATU has been disabled, and the interrupt is silently lost. To fix this issue, unmap the cached MSI iATU in dw_pcie_ep_raise_msix_irq() before the MSI-X map, and clear ep->msi_iatu_mapped so that the next MSI writel() reprograms the window. This guarantees that at most one iATU window maps ep->msi_mem_phys at any time, so the subsequent dw_pcie_find_index() call unambiguously returns the MSI-X window. Fixes: 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping") Reported-by: Sashiko Signed-off-by: Niklas Cassel [mani: commit log] Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/linux-pci/20260729051542.DC2741F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260730133123.1420413-6-cassel@kernel.org Signed-off-by: Sasha Levin commit 5aed69e20fd3d4b4129d0f2f81c5631eaa6bfc87 Author: Linmao Li Date: Tue Jul 28 19:19:24 2026 +0800 platform: arm64: qcom-hamoa-ec: reject incomplete responses [ Upstream commit 1b04f556e8428a3865a95627ab7a0acb5d9b93a5 ] qcom_ec_read() accepts short positive transfers, while both callers unconditionally consume every field in their fixed-size response. A short transfer can therefore make them use trailing stack bytes that were not returned by the device. The first response byte contains the number of payload bytes, excluding the byte count itself. A complete response of resp_len bytes must therefore report resp_len - 1 payload bytes. The existing check only rejects counts that do not fit in the response buffer and still accepts an incomplete payload. Require both the SMBus transfer length and the EC-provided payload count to match the expected response size. Fixes: 5c44f48e91de ("platform: arm64: Add driver for EC found on Qualcomm reference devices") Signed-off-by: Linmao Li Reviewed-by: Bryan O'Donoghue Reviewed-by: Anvesh Jain P Link: https://patch.msgid.link/20260728111924.4106898-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 914704c7b318bdaa42dce4e55f6c492190fee3b5 Author: Niklas Cassel Date: Thu Jul 30 15:31:25 2026 +0200 PCI: dwc: ep: Flush cached MSI write before unmapping the iATU [ Upstream commit 1b01d725d8b42450b86a857bab3c46856c740166 ] The MSI-X path already flushes any posted MSI-X write before tearing down its iATU mapping. That was added by commit c22533c66cca ("PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry") to make sure the write reaches the Root Complex before the outbound window that translates it disappears. The MSI path has the same problem but no equivalent flush. When the Endpoint driver caches an MSI target address and later observes that the Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing iATU entry and reprograms it for the new address. Between the last MSI writel() and the unmap there may still be a posted write sitting in the fabric, and unmapping the iATU entry can drop or misroute that write. Fix this by reading back from the mapped MSI window before the unmap. The readback drains any posted MSI writes through the same iATU entry that mapped them, which is the same logic the MSI-X path uses. Fixes: 468711a40d5d ("PCI: dwc: ep: Refresh MSI Message Address cache on change") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-pci/20260729214859.B9E2B1F00A3A@smtp.kernel.org Signed-off-by: Niklas Cassel [mani: commit log] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260730133123.1420413-5-cassel@kernel.org Signed-off-by: Sasha Levin commit 79588f2c754940217459f0cb64e4a52b3b3a4aaa Author: Niklas Cassel Date: Thu Jul 30 14:20:47 2026 +0200 misc: pci_endpoint_test: Check SUCCESS bit for doorbell status [ Upstream commit 37ddcce6904c20c6a7debe4751f6a82f218c3bae ] The pci-epf driver sets STATUS_DOORBELL_ENABLE_SUCCESS as the final step of pci_epf_test_enable_doorbell(), and STATUS_DOORBELL_DISABLE_SUCCESS as the final step of pci_epf_test_disable_doorbell(). A missing SUCCESS bit therefore unambiguously means that the operation did not complete, whereas the FAIL bit is only set on an explicit failure path. The host side test in pci_endpoint_test_doorbell() currently keys off the FAIL bit. That covers explicit failures but misses two cases. The first case is when the wait for the completion IRQ times out. No IRQ arrives, the Endpoint never updates STATUS, and neither SUCCESS nor FAIL is set. The enable path already handles this correctly because it also fails when the wait times out without an IRQ. The disable path does not have that extra guard and would wrongly treat the timeout as success. The second is a buggy EPC that raises two IRQs in response to a single DOORBELL_ENABLE command. The second wait_for_completion_timeout() returns immediately with 'left' non zero, but the endpoint has not yet written STATUS, so SUCCESS is clear and FAIL is also clear. The current FAIL only check treats this as success. So check the SUCCESS bit instead. That matches the Endpoint's contract because SUCCESS is the last write on the success path, and it correctly reports failure for both timeouts and the spurious IRQ case without relying on the FAIL bit being set. Fixes: eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case") Signed-off-by: Niklas Cassel [mani: commit log] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260730122045.1382749-5-cassel@kernel.org Signed-off-by: Sasha Levin commit 6228722c27304e4682cddc1fede03898f87e4414 Author: Shukai Ni Date: Tue Jul 28 16:33:50 2026 +0200 dm-integrity: replace forgeable discard filler with a keyed sector marker [ Upstream commit 68c5c42567bc462139128968ebbfadd0aefff519 ] The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic. Add a new "allow_discards_keyed" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum(). Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Co-developed-by: Jo Van Bulck Signed-off-by: Jo Van Bulck Signed-off-by: Shukai Ni Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5c5a795bf6248fe96f96dd9fd79d66bbb4a92077 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 3dbf85ef40b6366ba15e882f7536cdc98bea579a Author: Karl Mehltretter Date: Fri Jul 31 20:18:42 2026 +0200 tty: skip cdev_del() when no cdev is registered [ Upstream commit c3b5623fd97648f2747444aa8932ae604662df93 ] TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference. Only delete the cdev when the slot is not NULL. Fixes: a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly dynamic") Fixes: da4c279942b0 ("serial: enable serdev support") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-4-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 06b376432974fe5f25f2843a8e8438c6a1cf3d50 Author: Karl Mehltretter Date: Fri Jul 31 20:18:41 2026 +0200 serial: core: clear freed pointers on uart_register_driver() failure [ Upstream commit 61a2fb25551be0375bc16ef2a70c987dfca26183 ] uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped. Drivers that use drv->state as an "already registered" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port(). This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again. Clear both pointers on their failure paths, as uart_unregister_driver() already does. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 9e845abfc8a8 ("serial: fix NULL pointer dereference") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-3-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c2aec15f78b2e6ccd9b94216a901248511355982 Author: Karl Mehltretter Date: Fri Jul 31 20:18:40 2026 +0200 serial: core: do fallible allocations before the console can be registered [ Upstream commit 1a0e4fbce5d9c1bc179a35a2fd9ed142664299e3 ] serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed. Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds. Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration. Fixes: 266dcff03eed ("Serial: allow port drivers to have a default attribute group") Fixes: f7048b15900f ("tty: serial_core: Add name field to uart_port struct") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260719070454.D6FA21F000E9@smtp.kernel.org/ Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-2-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ad24c1d0b939d814a3020f96a667ac2d0394289 Author: Karl Mehltretter Date: Fri Jul 24 23:33:48 2026 +0200 serial: amba-pl011: keep console clock enabled for atomic writes [ Upstream commit c0e8cfef754645856374e82c8effd54b7d82002b ] pl011_console_write_atomic() runs from nbcon atomic context, where sleeping is not allowed. It calls clk_enable(), which takes the common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: clk_enable_lock() first tries spin_trylock_irqsave(), but on contention falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on an RT kernel with a clk-backed pl011 can trip: BUG: sleeping function called from invalid context at spinlock_rt.c:48 __might_resched from rt_spin_lock rt_spin_lock from clk_enable_lock clk_enable_lock from clk_enable clk_enable from pl011_console_write_atomic ... from vprintk_emit This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits before the lock. In addition, write_atomic() may be invoked from NMI context and is documented to avoid locking. Removing clk_enable() from the callback also avoids a potentially unsafe NMI acquisition of the common-clock enable_lock. An nbcon atomic-capable console must be printable from any context, so the clock cannot be gated between writes. Enable the clock while the console is available for output: use clk_prepare_enable() in pl011_console_setup(), release it via clk_disable_unprepare() in the console .exit() callback, and drop the per-write clk_enable()/clk_disable() pairs from write_atomic() and write_thread(). When printk suspends consoles, drop the reference after uart_suspend_port() stops console access and restore it before uart_resume_port() -- but only if suspend actually marked the port suspended (a wake-capable tty stays running and must keep its clock), and keep it when console_suspend_enabled is false so no_console_suspend works. The active power cost of keeping the clock enabled is platform-dependent: none where the UART clock is a fixed always-on oscillator, real where it is a gateable clock branch, which then cannot be gated (nor possibly can its parent clocks) while the console is available for output. When serial core actually suspends the port, the reference is released so the clock provider can gate the clock tree. Fixes: 2eb2608618ce ("serial: amba-pl011: Implement nbcon console") Suggested-by: John Ogness Link: https://lore.kernel.org/all/8733xeaxix.fsf@jogness.linutronix.de/ Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260724213348.77418-3-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0bcf3335dd3b4b575a1835877762ddadd8f9388b 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 10232a59e076a25a6d983a00f7c307e002ae2c5c 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 6390b2a352fcf885e993a0884752f0838743dcbf Author: Christophe Leroy (CS GROUP) Date: Thu Jul 30 12:09:40 2026 +0200 soc: fsl: qe: implement get_direction() [ Upstream commit e460ef309f44b39480209970f1dd462f051d6f30 ] The lack of get_direction() callback in this driver causes GPIOLIB to emit a warning. Implement it. Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/30b3f278a10b46252783458c81dc438df176f86c.1785405882.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 77159db9c6f1c5d580bbe2a12ec1911991abbd81 Author: Christophe Leroy (CS GROUP) Date: Thu Jul 30 14:29:36 2026 +0200 soc: fsl: qe: properly scan GPIO nodes at startup [ Upstream commit e2414b289c2b68afab361def612ca3791cd70d12 ] Before commit 156460811def ("soc: fsl: qe: Change GPIO driver to a proper platform driver") qe_add_gpiochips() was walking the device tree to find all nodes with compatible "fsl,mpc8323-qe-pario-bank". After that commit the discovery is handled by the platform core, therefore it is necessary to call of_platform_default_populate() on the par_io node. Fixes: 156460811def ("soc: fsl: qe: Change GPIO driver to a proper platform driver") Reviewed-by: Herve Codina Link: https://lore.kernel.org/r/a1db12ef75bf881dd5fba893a37db0c8517eca1b.1785414349.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 7b0093b638c8f2b94b0778a69fd1ccad54299b29 Author: Saket Kumar Bhaskar Date: Mon Aug 3 10:58:43 2026 +0530 powerpc/irq: Fix missing r2 clobber in PCREL inline assembly [ Upstream commit 00be69070d91d2be978e752bb117a0a4db0e1281 ] In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ... 3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31 With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs> ... 85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2 Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled. [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10fc2cda485cd22e209a31d786bed1984bdf3982.1785732393.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 066e5e9962dd4ef8a3556ce201e4cfb655c0d550 Author: Saket Kumar Bhaskar Date: Thu Jul 30 11:16:03 2026 +0530 powerpc64/bpf: Fix build break for arch_bpf_timed_may_goto [ Upstream commit e1e5e682511eda648aa91372542cc8f665ad0bff ] With CONFIG_PPC_KERNEL_PCREL enabled, calling bpf_check_timed_may_goto() using a bl instruction results in a link-time failure: arch/powerpc/net/bpf_timed_may_goto.o: in function `arch_bpf_timed_may_goto': (.text+0x28): call to `bpf_check_timed_may_goto' lacks nop, can't restore toc Use CFUNC() macro instead of direct 'bl' to properly annotate the call to bpf_check_timed_may_goto(). On PCREL builds, CFUNC() expands to 'bl name@notoc', informing the linker that TOC restoration is not needed, avoiding the "lacks nop, can't restore toc" linker error. Fixes: b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f75e5aa911afb984a94c0e85d58b1be5fb428548.1785387718.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit ce3976251120970225bc5fec39a62dddea79c20e Author: Madhavan Srinivasan Date: Thu Jul 30 11:16:02 2026 +0530 powerpc64/bpf: Fix build break in bpf_jit_emit_func_call_rel() [ Upstream commit e8ee988c0087248324dbd3da486d22045e4a4079 ] With CONFIG_PPC_KERNEL_PCREL enabled, build breaks with below error: CC mm/dmapool.o CC fs/readdir.o arch/powerpc/net/bpf_jit_comp64.c: In function 'bpf_jit_emit_func_call_rel': arch/powerpc/net/bpf_jit_comp64.c:475:13: error: unused variable 'ret' [-Werror=unused-variable] 475 | int ret; | ^~~ Commit b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") introduced "ret" at function scope, but it is only used within its respective conditional blocks. Same holds true for reladdr. Move both variable declarations to the scopes where they are actually used: "reladdr" to the CONFIG_PPC_KERNEL_PCREL block and "ret" to the non-PCREL else block. Fixes: b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/e8e582fb425db165a72f00e3337cdf4c6ae383ad.1785387718.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 19b54740e2e1102c7d48553d9e0347c1f6af22b0 Author: Mukesh Kumar Chaurasiya (IBM) Date: Fri Jul 31 13:45:21 2026 +0530 powerpc/syscall: Fix syscall skip handling for seccomp and ptrace [ Upstream commit 69cb2be898be6d5826cacd1a628f6945a24480b6 ] After enabling GENERIC_ENTRY on PowerPC, syscall_enter_from_user_mode() returns -1 as a sentinel to signal that seccomp or ptrace has intercepted the syscall and already set a return value via syscall_set_return_value(). system_call_exception() was not handling this sentinel, and since -1UL is >= NR_syscalls, the code fell into the out-of-range path and returned -ENOSYS, overwriting the errno already placed in regs->gpr[3]. The naive fix of checking r0 == -1L before the NR_syscalls bounds check is ambiguous: a user legitimately calling syscall(-1) also produces r0 == -1L, and a tracer intercepting such a call would have its injected return value silently discarded. Fix this by introducing a thread flag that is set whenever syscall_set_return_value() explicitly updates the return value. In system_call_exception(), check and clear this flag before dispatching the syscall, and return the preset value directly when it is present. This ensures that an explicitly supplied return value always suppresses syscall execution, regardless of the syscall number. This handles all seccomp actions correctly: - SECCOMP_RET_ERRNO, SECCOMP_RET_TRACE (no tracer), SECCOMP_RET_USER_NOTIF: all call syscall_set_return_value(), flag is set, injected value returned. - SECCOMP_RET_TRAP, SECCOMP_RET_KILL: call syscall_rollback() and deliver a signal; flag is not set, but the process is dying so the return value is irrelevant. The fix covers both ppc32 and ppc64 with no #ifdefs. Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Reported-by: Michal Suchánek Closes: https://lore.kernel.org/all/ajpp-_XnbF3UTM_E@kunlun.suse.cz/ Tested-by: Michal Suchánek Reviewed-by: Michal Suchánek Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260731081521.1852133-1-mkchauras@gmail.com Signed-off-by: Sasha Levin commit de2d453f6f71d62684a434fee3f149bd9390adf3 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 c554a8d376d5aea1b237ed6bef6f9fbfc550e67f Author: Gou Hao Date: Mon Jul 27 18:42:13 2026 +0800 powerpc/xive: propagate IPI init errors to prevent use-after-free [ Upstream commit 411a3c016e7a95f5fa105a0587e07d0647a77727 ] When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Fixes: cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-4-gouhao@uniontech.com Signed-off-by: Sasha Levin commit e4c0451aa61549f18475c24aec01f0fa1c43e633 Author: Gou Hao Date: Mon Jul 27 18:42:12 2026 +0800 powerpc/xive: add error return value to xive_smp_probe() [ Upstream commit ab5ae5dceb86614f6c9e7488f91b652000edfdc5 ] xive_smp_probe() calls xive_init_ipis() which can fail, but its return value is currently ignored. Change xive_smp_probe() to return int so that errors can be propagated to callers. This is a preparatory patch for the next one. No functional change yet; the return value is always 0 at this point. Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-3-gouhao@uniontech.com Stable-dep-of: 411a3c016e7a ("powerpc/xive: propagate IPI init errors to prevent use-after-free") Signed-off-by: Sasha Levin commit 0a2be2ca7ad7bf2176e29576ef8c4306a4724d1c Author: Gou Hao Date: Mon Jul 27 18:42:11 2026 +0800 powerpc/xive: make xive IPI allocation NULL-safe [ Upstream commit f068fca7e8b7014014296b0e458ba9c5aa77f954 ] __GFP_NOFAIL should not be used in new code [1]. xive_init_ipis() allocates the xive_ipis array with __GFP_NOFAIL, which makes the subsequent NULL check unreachable dead code. Remove __GFP_NOFAIL so the allocation can fail, and make all xive_ipis access paths NULL-safe: - Return XIVE_BAD_IRQ from xive_ipi_cpu_to_irq() when xive_ipis is NULL. - Set xive_ipis to NULL after kfree() in the error path to prevent use-after-free. - Guard xive_setup_cpu_ipi() and xive_cleanup_cpu_ipi() against xive_ipi_irq == XIVE_BAD_IRQ to avoid dereferencing an uninitialized or already-freed xive_ipis array. No functional change when allocation succeeds. Link: https://lore.kernel.org/all/20260725202632.dcb325658896a470df91cf57@linux-foundation.org/ [1] Fixes: 7dcc37b3eff9 ("powerpc/xive: Map one IPI interrupt per node") Signed-off-by: Gou Hao Suggested-by: Andrew Morton Suggested-by: Cédric Le Goater Suggested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Cédric Le Goater Reviewed-by: Andrew Morton Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-2-gouhao@uniontech.com Signed-off-by: Sasha Levin commit 7e4b44abf682b6790ef204e0c166bdc656c11a64 Author: Troy Mitchell Date: Wed Jul 29 02:26:42 2026 -0700 pinctrl: spacemit: validate pins in pinconf callbacks [ Upstream commit 41c59b22370d2e1785e0e80f8ad7bd9946a1ca82 ] Pin 0 is a valid pin ID, but spacemit_pinconf_get() rejects it by testing the numeric ID rather than the result of the descriptor lookup. It also fails to reject nonzero IDs absent from the SoC pin table before computing their register addresses. Check the descriptor and use its pin ID for the register lookup. spacemit_pinconf_group_set() validates only the first group member when generating the configuration. If a later member is invalid, spacemit_pin_set_config() returns -EINVAL, but the callback ignores it and reports success after partially updating the group. Validate every group member before writing any registers so malformed groups fail without being partially applied. Fixes: a83c29e1d145 ("pinctrl: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell Reviewed-by: Yixun Lan Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 09f47abc95ee9e819e7e93cd68c1c23abe11c842 Author: Surendra Singh Chouhan Date: Wed Jul 29 13:24:37 2026 +0530 pinctrl: generic: free maps on pinctrl_generic_to_map() failure [ Upstream commit 17007cd700601777d9ee203a13d97e64ece3a10f ] pinctrl_generic_to_map() parses DT configuration and allocates pinctrl maps via pinctrl_utils_reserve_map(). If subsequent steps (such as pinctrl_utils_add_map_mux(), pinctrl_generic_add_group(), pinconf_generic_parse_dt_config(), or pinctrl_utils_add_map_configs()) return an error, *maps may contain partially allocated map entries. Returning the error directly without freeing *maps leaks the allocated mapping memory across all drivers that rely on pinctrl_generic_to_map(). Fix this by calling pinctrl_utils_free_map() and resetting *maps, *num_maps, and *num_reserved_maps in the error path of pinctrl_generic_to_map(). Fixes: aaaf31be0426 ("pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()") Signed-off-by: Surendra Singh Chouhan Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9ab072a1469f175297115ed0cf6add88cca146f0 Author: Yulin Lu Date: Tue Jul 28 15:29:06 2026 +0800 pinctrl: eswin: Fix Handling of PIN_CONFIG_PERSIST_STATE [ Upstream commit f9af1329b98a478f4bba605ec6db429ef0e38d54 ] The EIC7700 pinctrl driver does not handle PIN_CONFIG_PERSIST_STATE specifically, and returns -EOPNOTSUPP from the default case. Since all pins on the EIC7700 SoC are persistent over suspend, the correct behaviour is to accept this parameter and return success. Add an explicit case for PIN_CONFIG_PERSIST_STATE that returns 0 to prevent errors when this parameter is set. Signed-off-by: Yulin Lu Fixes: 5b797bcc00ef ("pinctrl: eswin: Add EIC7700 pinctrl driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 91a6f4283099c64805b222019d8c6ad692918dd2 Author: Josh Poimboeuf Date: Sun Aug 2 20:24:28 2026 -0700 objtool/klp: Fix symbol resolution for duplicate data symbols [ Upstream commit 15fa203ef91e8a303c322eaaa8ca01a6ddaf94dc ] find_sympos() calculates a sympos used by livepatch to disambiguate duplicately-named symbols. For function symbols, there's a hack which counts .text.unlikely symbols before other .text symbols, matching the linker script's section ordering. Not only is the hack fragile, data symbols can have the same problem. So for example, adding a reference to pwq_cache in ep_unregister_pollwait() can trigger a corrupt sympos and a relocation to the wrong pwq_cache symbol in the livepatch module, resulting in a crash or undefined behavior. Remove the existing hack in favor of a fully deterministic solution, using the new .klp.symid table to derive the symbol-to-id mapping from the original vmlinux.o and the id-to-address mapping from the corresponding vmlinux, which can then be used to determine the exact sympos associated with the original vmlinux. Modules don't need any special treatment: the .ko has the same section/symbol ordering as the original whole-archive symbol table. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Ben Procknow Reported-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: live-patching@vger.kernel.org Link: https://lore.kernel.org/20260710153042.3156788-1-joe.lawrence@redhat.com Link: https://lore.kernel.org/20260724221730.3126529-1-joe.lawrence@redhat.com Link: https://patch.msgid.link/919785e3bf2245db02ff6391e735d9cb139170b1.1785727106.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 9f08c40740410d5b857192bd75113b9a1182ee1d Author: Josh Poimboeuf Date: Sun Aug 2 20:24:27 2026 -0700 objtool/klp: Add .klp.symid for sympos disambiguation [ Upstream commit 029223d301620bc4e1086696047b0d5d6eba5edd ] Livepatch identifies a duplicate-named symbol by its position (sympos) among same-named kallsyms entries, which for vmlinux are counted in ascending address order in the final linked kernel. That order can't be reliably derived from vmlinux.o: the final link reorders sub-sections (.text.unlikely*, .data..*, etc). Bridge the gap with a new .klp.symid section which can be used to correlate symbols between vmlinux.o and vmlinux so that klp-diff can reliably determine the sympos. The table can't survive --gc-sections: keeping it alive would keep every duplicate-named symbol's section alive, so the reference kernel would stop matching the one which ships. klp-build rejects CONFIG_LD_DEAD_CODE_DATA_ELIMINATION instead. Nothing is lost today: x86_64 is the only HAVE_KLP_BUILD arch and doesn't select HAVE_LD_DEAD_CODE_DATA_ELIMINATION, arm64 and s390 have never selected it either, and on powerpc, it's still EXPERIMENTAL and disabled by every distro kernel. This is the build-time half of reliable vmlinux sympos computation; "objtool klp diff" will consume the table in a subsequent commit. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: live-patching@vger.kernel.org Link: https://patch.msgid.link/64d50f077b569f47883c015cdb7079edb068efe8.1785727106.git.jpoimboe@kernel.org Stable-dep-of: 15fa203ef91e ("objtool/klp: Fix symbol resolution for duplicate data symbols") Signed-off-by: Sasha Levin commit 20938e167757d3c778135822470b56ce972a466b Author: Josh Poimboeuf Date: Sun Aug 2 20:24:25 2026 -0700 objtool/klp: Fix false module dependencies caused by dead relocs [ Upstream commit 5ca8c91d1ea6534842e7e0065d15104d802506cd ] When creating a klp reloc, klp-diff keeps the original relocation but converts the referenced symbol to an UNDEF/WEAK placeholder tombstone symbol, which gets fully disabled later by klp post-link. The tombstone symbol is only needed to avoid confusing objtool when it does the final run on the patch module. However, for references to exported symbols, modpost sees the reference to the tombstone symbol as a real reference to an exported symbol, resulting in a false module dependency getting created. Further, for a reference to a tombstone symbol which is exported into a module namespace, e.g. via EXPORT_SYMBOL_FOR_KVM_INTERNAL(), modpost can't satisfy the dependency, resulting in a warning like the following: module ... uses symbol kvm_flush_remote_tlbs from namespace module:kvm-amd,kvm-intel, but does not import it. Rename the placeholder tombstone symbols to ".klp.tombstone." so modpost no longer recognizes them. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Ben Procknow Reported-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: live-patching@vger.kernel.org Link: https://lore.kernel.org/20260720145658.1103243-5-joe.lawrence@redhat.com Link: https://patch.msgid.link/9548393f4d89ec3b498f4f69aa6ef6b9bb7150fe.1785727106.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 8844c2efd92ca54d74e1f7df185aa186e4fea6c8 Author: Joe Lawrence Date: Sun Aug 2 20:24:24 2026 -0700 objtool/klp: Normalize Module.symvers paths to module names [ Upstream commit 8668bf91e0508abeb8e98b4edd89032be02228a1 ] Module.symvers contains build-tree object paths as module identifiers (e.g., "arch/x86/kvm/kvm") rather than runtime module names ("kvm"). Objtool's clone_reloc_klp() uses this field directly for exported symbols, while unexported symbols correctly go through __find_modname(). This means that exported symbol relocations may land in a .klp.rela section named with the build path rather than the module name. That is a crash waiting to happen: the kernel's livepatch loader silently skips this relocation because it doesn't match the expected klp_object name. The unresolved relocation sits in the newly activated code, crashing when executed. Normalize export->mod at Module.symvers read time using the same logic as __find_modname() (refactored into a shared normalize_modname() helper). Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Ben Procknow Signed-off-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Miroslav Benes Cc: live-patching@vger.kernel.org Link: https://patch.msgid.link/dbe1b72931bd3c31b751fd0729613d9f2226fff6.1785727106.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit ce962f04312fa9906a62d1f859fc3faf9ecbc426 Author: Josh Poimboeuf Date: Sun Aug 2 20:24:23 2026 -0700 objtool/klp: Fix module name normalization for paths with dots [ Upstream commit 165affd6f095323d953b0ed5823ec4d0db3b7d0d ] When .modinfo has no "name=" tag, __find_modname() falls back to converting the object's build-tree path to a runtime module name by stripping directory components, converting '-' to '_' and truncating the file extension. It does all that in a single pass over the entire path, so the first dot anywhere in the path ends the name. For an object built in a directory whose name contains a dot, e.g. "drivers/foo-1.0/bar.o", the result is a bogus module name. Strip the directory components up front so only the basename is scanned for the extension separator. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Sashiko Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: live-patching@vger.kernel.org Link: https://patch.msgid.link/9017b4609553bed16674e8f924d34691cbc2b2c1.1785727106.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit e82f260a74dea8cdd7857f2cc66f73d0da522bb3 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 af8087f16714f7620c4db3e732baaa1b2337948f Author: Jiayuan Chen Date: Tue Jul 28 14:05:16 2026 +0800 bpf: Fix mmap_lock deadlock on arena lock failure [ Upstream commit 0b10b945479c954393d62ee3229d2f224a4ca91c ] Reported by the Sashiko AI review. arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock: do_user_addr_fault() { fault = handle_mm_fault(...); // calls arena_vm_fault() if (fault & VM_FAULT_RETRY) goto retry; // re-locks mmap_lock mmap_read_unlock(mm); } Return VM_FAULT_SIGBUS instead, for two reasons: 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does. 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again. So returning VM_FAULT_RETRY here is overkill. Fixes: b8467290edab ("bpf: arena: make arena kfuncs any context safe") Signed-off-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260728060517.95183-1-jiayuan.chen@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit db3439ad11ac5e52decdefe784c98b21c3757848 Author: Zhao Li Date: Fri Jul 31 15:11:03 2026 +0800 wifi: cfg80211: stop PMSR before P2P and NAN teardown [ Upstream commit 6c5fc504d0d6934132637aa3db4b9b58148eaa78 ] PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not. Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result. Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260731071103.73563-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit eef374088450bb91626e133c7172b8a0e969a522 Author: Johannes Berg Date: Sun Aug 2 11:12:17 2026 +0300 wifi: mac80211: disconnect on CSA to channel 0 [ Upstream commit cf57f0a674cc3e3cda1a789359cc1238b61b9d7d ] The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present. Fixes: 21c3f8f95554 ("wifi: mac80211: refactor STA CSA parsing flows") Signed-off-by: Johannes Berg Reviewed-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260802111213.3bc833515e40.I255c37c31ca8b0b34e351cf254e16b6071dd8fb3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f26e1b16904555e171292e183c3cfc1c38159fc5 Author: Jason Huang Date: Wed Jul 22 16:26:08 2026 +0800 wifi: brcmfmac: fix P2P action frame handling without device vif [ Upstream commit 1b1edb9ebed49099bdc924cef49a9aea8b552199 ] Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search. Fixes: 30fb1b272909 ("brcmfmac: use actframe_abort to cancel ongoing action frame") Fixes: 6eda4e2c5425 ("brcmfmac: Add tx p2p off-channel support.") Signed-off-by: Jason Huang Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260722082608.412472-1-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5f00970da7da0342eb27f053627d9e4d193a8f92 Author: Namhyung Kim Date: Thu Jul 30 16:59:46 2026 -0700 perf build: Fix a build error on 32-bit x86 [ Upstream commit dbd2505061349bbee9c3282472f14ae27da8adfd ] The commit d7507a94a072 ("KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM") added "ull" suffix to SVM exit codes and it makes the 32-bit build fail like below. In file included from util/kvm-stat-arch/kvm-stat-x86.c:4: util/kvm-stat-arch/../../../arch/x86/include/uapi/asm/svm.h:137:32: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295' [-Werror=overflow] 137 | #define SVM_EXIT_ERR -1ull | ^ util/kvm-stat-arch/../kvm-stat.h:131:17: note: in definition of macro 'define_exit_reasons_table' 131 | symbols, { -1, NULL } \ | ^~~~~~~ util/kvm-stat-arch/../../../arch/x86/include/uapi/asm/svm.h:249:11: note: in expansion of macro 'SVM_EXIT_ERR' 249 | { SVM_EXIT_ERR, "invalid_guest_state" } | ^~~~~~~~~~~~ util/kvm-stat-arch/kvm-stat-x86.c:12:45: note: in expansion of macro 'SVM_EXIT_REASONS' 12 | define_exit_reasons_table(svm_exit_reasons, SVM_EXIT_REASONS); | ^~~~~~~~~~~~~~~~ As the exit_code was unsigned long, the compiler complained about the truncation. Let's convert it to u64 to suppress the error. Fixes: fac520e43a60 ("tools headers: Sync KVM headers with the kernel sources") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit cb04dd061d333ff7f6d616b41e34fb6f91b3cf5b Author: Zhao Li Date: Thu Jul 23 09:10:01 2026 +0800 wifi: mac80211: skip unused probe response countdown offsets [ Upstream commit fd2bf5e718108c00732eb07fd94a5d8830f62a9f ] mac80211 copies cfg80211's variable-length countdown offset list into a zero-initialized fixed-size array, leaving unused entries at zero. The beacon branch already skips those zero entries, but the AP probe-response branch writes through them unconditionally. When a probe-response template has no countdown offset, the write through an unused zero entry overwrites resp->data[0], corrupting the first byte of the template. cfg80211 already bounds explicitly supplied non-zero offsets in nl80211_parse_counter_offsets(), so this is a zero-sentinel bug, not an out-of-bounds write. Skip zero probe-response offsets, matching the beacon path. Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp") Link: https://lore.kernel.org/all/20260708195911.84365-6-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260723011001.76851-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ef65c02a5a1fa975fdbb4ff864b77f0a10e22be5 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 4e0a67fbe3d9e2e1d6f81dfc607184c6b0abd3dd Author: Zhao Li Date: Fri Jul 31 12:02:44 2026 +0800 wifi: nl80211: clean up color-change beacon data on errors [ Upstream commit 927ee844c47ac2aef22c8f7a35f098ff576b398b ] nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data. Fixes: dc1e3cb8da8b ("nl80211: MBSSID and EMA support in AP mode") Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260731120244.82628-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c8ae335c4823ee3702f002c057b9708755d6a7c8 Author: Zhao Li Date: Thu Jul 30 01:36:07 2026 +0800 wifi: mac80211: send TWT teardown to peer after setup TX failure [ Upstream commit a28fcce6ee74be8a4526e6cfa16dc7786d62a784 ] When an AP's TWT Setup response is not acknowledged, ieee80211_s1g_tx_twt_setup_fail() asks the driver to tear down the local agreement and sends a TWT teardown action as the peer notification. It uses the response SA as the destination, but ieee80211_s1g_send_twt_setup() built that response with SA set to the AP's address. The teardown is therefore queued with DA, SA and BSSID all set to the AP address and never reaches the station. The in-tree driver callbacks update local hardware state and emit no action frame. The station receives no notification that mac80211 asked the driver to remove the agreement and can keep following the TWT schedule, leaving the peers' power-save state desynchronized. Address the teardown to the response DA, the station to which the failed response was sent. This also matches the station lookup the transmit status path already performs on the same frame. Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260729173607.13340-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 40120891f29d5bb2a8602b592ee924cbdc6534e0 Author: Davidlohr Bueso Date: Wed Jul 15 12:14:52 2026 -0700 perf/cxlpmu: Fix 64-bit write to 32-bit HDM filter register [ Upstream commit ea434e8fd3a539e9c53285b10d3c7e539e228591 ] The HDM decoder filter configuration register is 32 bits wide, but the driver programs it with a 64-bit writeq(). The filter value never exceeds 32 bits, so the upper half of the write is always zero and lands in the adjacent Filter ID 1 (Channel/Rank/Bank) configuration register at offset+4. Fixes: 5d7107c72796 ("perf: CXL Performance Monitoring Unit driver") Signed-off-by: Davidlohr Bueso Reviewed-by: Richard Cheng Reviewed-by: Dave Jiang Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6a1e24977e503425e96fb9aa0671a4b4be19dad2 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 88493d0d4c81e2f7ab4acc076657470410ab0691 Author: Mark Brown Date: Fri Jul 31 21:50:52 2026 +0100 kselftest/arm64: Don't write to P0 in irritator on SME only systems [ Upstream commit 2b989c411ab98fa76b7bb3b87ba7a2a4c3b5e946 ] Commit 3e360ef0c0a1f ("kselftest/arm64: Corrupt P0 in the irritator when testing SSVE") added corruption of P0 to the sve-test case in order to ensure that the predicate registers were covered as part of the corruption. On SME only systems this results in an illegal instruction since signal handlers are run out of streaming mode and the predicate registers do not exist out of streaming mode without SVE. Switch to entering and exiting streaming mode in the irritator, this will reset all relevant registers to 0 if they somehow weren't already by the signal entry. Fixes: 3e360ef0c0a1f ("kselftest/arm64: Corrupt P0 in the irritator when testing SSVE") Reported-by: Mark Rutland Signed-off-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f433869f23841a50455c4087d85540d5b4d37cde Author: Will Deacon Date: Thu Jul 30 14:26:50 2026 +0100 arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry [ Upstream commit 88b839ce497ccb1ff92f7ae742c78dd2937ba572 ] Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path. Cc: Kees Cook Cc: Jinjie Ruan Cc: Mark Rutland Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1] Reported-by: Yiqi Sun Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/ Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Tested-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b568c2097a690af3cafa723b13c3dc6c4b57f0f0 Author: Karl Mehltretter Date: Wed Jul 29 02:42:55 2026 +0200 kselftest/arm64: fp-ptrace: Fix checks for inactive SVE and SSVE regsets [ Upstream commit bd290e7fc245f9f85607f305fe8213c6c47a416c ] The checks on the header size reported for the inactive regset of the NT_ARM_SVE/NT_ARM_SSVE pair compare it against sizeof(sve), but sve is a struct user_sve_header *, so this is 8 rather than the intended 16. The kernel carried the identical typo when filling in the header, so kernel and test agreed on the wrong value and the test passed. Compare against sizeof(*sve), stop after the header checks for an inactive regset since it has no payload to compare, and prefill the buffer with a sentinel to verify that reading an inactive regset leaves everything after the header untouched. This also covers the getter's return value, which determines how many bytes ptrace copies back to userspace. Fixes: 864f3ddcd715 ("kselftest/arm64: fp-ptrace: Adjust to new inactive mode behaviour") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b19c3fd8e2abbf04353bb947234270a2074d47a5 Author: Karl Mehltretter Date: Wed Jul 29 02:42:54 2026 +0200 arm64/fpsimd: ptrace: Fix inactive SVE and SSVE regsets [ Upstream commit c3f83d021162571bcd87b062ec9e587828d2b7f3 ] sve_init_header_from_task() takes header as a pointer, so for the inactive mode header->size = sizeof(header); stores 8 rather than sizeof(struct user_sve_header), which is 16. Userspace sees an impossible size smaller than the header it describes. The inactive-mode check in sve_get_common() compares header.size against sizeof(header) as well, but there header is a struct, so the check can never fire. Reads of NT_ARM_SVE and NT_ARM_SSVE for the inactive mode therefore still return the other mode's FPSIMD data, exactly the situation the check was added to prevent. Fix the size, and make the check return the remaining membuf space instead of 0, which regset_get() would interpret as the entire (zero-filled) buffer having been populated. Fixes: b93e685ecff7 ("arm64/fpsimd: ptrace: Do not present register data for inactive mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bd89a1988f44d453c4c0acb1fc79f10e28aa9988 Author: Shanker Donthineni Date: Fri Jul 31 18:52:43 2026 +0100 arm_mpam: Apply T241-MPAM-6 to 63-bit counters [ Upstream commit 2c43aced9be353f8428678a75495ca9d631dc927 ] T241-MPAM-6 causes all MBWU counter formats to count 64-byte requests instead of bytes. Commit dc48eb1ff27c excluded the 63-bit MSMON_MBWU_LWD format while scaling the shorter counters. Systems selecting the preferred 63-bit counter consequently report bandwidth values that are 64 times too small. Apply the scale to both the sampled value and overflow correction for the 63-bit format. Unsigned arithmetic retains modulo-u64 behavior when the scaled counter range exceeds u64. Fixes: dc48eb1ff27c ("arm_mpam: Add workaround for T241-MPAM-6") Link: https://lore.kernel.org/lkml/20240816131432.993859-1-sdonthineni@nvidia.com/ Signed-off-by: Shanker Donthineni Reviewed-by: Fenghua Yu Tested-by: Fenghua Yu Reviewed-by: Ben Horgan Signed-off-by: Ben Horgan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6e61b07c348747fd22c02f11546f7661d49d6803 Author: Vladimir Murzin Date: Fri Jul 31 13:26:46 2026 +0100 arm64: smp: Fix IPI teardown for GICv5 flow [ Upstream commit 4c9c81a0860415284e9d260f998fbd755d3a7469 ] Sashiko reported that during CPU offlining, __cpu_disable() is executed by the stopper thread via take_cpu_down() with local interrupts disabled. __cpu_disable() calls ipi_teardown(), which invokes ipi_lpi_disable(). For the GICv5 flow, this eventually calls the sleepable disable_irq(). This can be reproduced easily with CONFIG_DEBUG_ATOMIC_SLEEP=y by offlining a CPU: BUG: sleeping function called from invalid context at kernel/irq/manage.c:702 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 20, name: migration/1 preempt_count: 1, expected: 0 no locks held by migration/1/20. irq event stamp: 186 hardirqs last enabled at (185): [] _raw_spin_unlock_irq+0x38/0x68 hardirqs last disabled at (186): [] multi_cpu_stop+0xc8/0x190 softirqs last enabled at (80): [] handle_softirqs+0x410/0x468 softirqs last disabled at (75): [] __do_softirq+0x1c/0x28 Fix this by using disable_irq_nosync() instead, which is safe in this atomic context. Fixes: ba1004f861d1 ("arm64: smp: Support non-SGIs for IPIs") Signed-off-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0bd829443a50b08e3c352df41ecc9a449564492d Author: Jose Ignacio Tornos Martinez Date: Thu Jul 2 12:43:37 2026 +0200 wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations [ Upstream commit 4df22710a77d2365e56d720bc4106e54c1dfa2ff ] The driver fails to register with error -22 (EINVAL) due to a cfg80211 validation failure in wiphy_verify_iface_combinations(). Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") added beacon_int_min_gcd to if_comb_global and if_comb_global_7992, but these combinations include ADHOC (IBSS) interface type. This violates a cfg80211 rule from commit 56271da29c52 ("cfg80211: disallow beacon_int_min_gcd with IBSS") that explicitly forbids combining ADHOC with beacon_int_min_gcd. The restriction exists because beacon_int_min_gcd requires static, predictable beacon intervals to coordinate multiple beaconing interfaces, but ADHOC interfaces have dynamic beacon intervals that change when joining different networks, making the GCD constraint unenforceable. Remove beacon_int_min_gcd from the interface combinations that include ADHOC because they are not necessary for ADHOC operation. The if_comb combination (AP/MESH/STA only, without ADHOC) correctly retains beacon_int_min_gcd for multi-AP coordination. Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Alex Gavin Link: https://patch.msgid.link/20260702104337.679536-1-jtornosm@redhat.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 045d1bfb72d2631ab9ec74afa491aa788ebb57aa 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 c770e7da8cebd8f7fdc39dd5d3358baf780086d5 Author: Reshma Immaculate Rajkumar Date: Wed Jul 29 22:47:32 2026 +0530 wifi: ath12k: fix encrypted EAPOL TX in encap offload mode [ Upstream commit 1e33f8acd837420160ea088160d8648a3db54c3b ] When a vif operates with IEEE80211_OFFLOAD_ENCAP_ENABLED, mac80211 delivers EAPOL frames to ath12k in native-WiFi format. Unencrypted EAPOL frames used during the initial 4-way handshake are already handled through the existing is_diff_encap path. However, EAPOL frames transmitted during GTK rekeying carry ATH12K_SKB_CIPHER_SET and continue through the normal native-WiFi transmit path. Firmware encryption requires RAW frames with cipher-specific IV and ICV fields correctly provisioned in the skb. Passing encrypted EAPOL frames in native-WiFi format results in incorrect IV provisioning, leading to an invalid ICV and frame drop. Fix this by detecting the EAPOL frames that need HW encryption and converting them to firmware-encrypted RAW frames before transmission. Reserve IV space after the MAC header, append ICV space at the tail, select the appropriate firmware encryption type and request firmware-side encryption. Introduce ath12k_dp_tx_crypto_iv_len() and ath12k_dp_tx_crypto_icv_len() helpers in the TX path to obtain cipher-specific IV and ICV lengths. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1 Fixes: d29591d5b52e ("wifi: ath12k: Advertise encapsulation/decapsulation offload support to mac80211") Signed-off-by: Reshma Immaculate Rajkumar Reviewed-by: Aishwarya R Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260729171732.668367-1-reshma.rajkumar@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit aff81505a84d27f83b4db8e039e813930cb23c2c Author: Felix Fietkau Date: Sat Aug 1 14:53:34 2026 +0000 wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() [ Upstream commit 4330a0ef9f75a54fde3548432a9a698f06bab635 ] When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well. Fixes: 1609b014aa29 ("wifi: mt76: mt7996: Overwrite unspecified link_id in mt7996_tx()") Link: https://patch.msgid.link/20260801145334.1166751-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c1442c345ca8da857fadea1d0797b97347ab6984 Author: Felix Fietkau Date: Sat Aug 1 14:53:33 2026 +0000 wifi: mt76: reject out-of-range link ids in mt76_vif_link() [ Upstream commit 9ba744a28c26eaa5cae930688a22e01888395308 ] mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected(). Fixes: a9384b36a42a ("wifi: mt76: mt7996: rework set/get_tsf callabcks to support MLO") Link: https://patch.msgid.link/20260801145334.1166751-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 626dce25666a8b3bc68a964ef91895ee2d3e199d Author: shengwei.lu Date: Thu Jul 23 11:11:08 2026 +0800 wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum [ Upstream commit 404c4e564f6b1eeffd10bf2b2d3b86620f5794c3 ] Per IEEE 802.11be, the Beamformee SS <= 80/160/320 MHz 3-bit subfields in the EHT PHY Capabilities are encoded as (Nss - 1) and are required to be >= 3 (i.e. at least 4 SS receive capability) whenever SU Beamformee is advertised. MT7925 is a 2x2 STA (sts = 2), so directly filling (sts - 1) = 1 violates the spec minimum. Clamp the encoded value to 3 when sts <= 3, otherwise use (sts - 1). This is applied consistently to the BEAMFORMEE_SS <= 80 MHz (split across phy_cap_info[0]/[1]), <= 160 MHz and <= 320 MHz (6 GHz only) subfields. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: shengwei.lu Link: https://patch.msgid.link/20260723031108.2017653-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fa496e89e01cf625070a31fafac541b0b48bbd8f Author: Peter Chiu Date: Mon Jul 27 15:04:30 2026 +0000 wifi: mt76: fix queue assignment for disassoc packets [ Upstream commit 3999d15cfcc72a946ec419c4059b0e0cd7860053 ] Like deauth, a disassoc frame sent to a client in powersave mode can get stuck in a tx queue along with other buffered frames, filling up hardware queues with frames that are only released after the WTBL slot is reused for another client. Move disassoc packets to the ALTX queue, matching the existing deauth handling. Fixes: dedf2ec30fe4 ("wifi: mt76: fix queue assignment for deauth packets") Signed-off-by: Peter Chiu Link: https://patch.msgid.link/20260727150434.1778520-11-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c2dfb099ca941b8c9b6385af7139f35798364471 Author: Felix Fietkau Date: Mon Jul 27 15:04:28 2026 +0000 wifi: mt76: mt7915: report RX chain signal for all RX paths [ Upstream commit b53c44fe65792608f58028c7b0953e610ad652ee ] status->chains was set from the antenna mask, which is derived from the number of spatial streams, while the chain_signal array is filled from all RCPI fields. On boards where the number of RX paths exceeds the stream count, e.g. the 3T3R mt7916/mt7981 variant with 2 streams on the 5 GHz band, the RSSI of the extra chains was never reported. Use the band local RX path chainmask instead. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Link: https://patch.msgid.link/20260727150434.1778520-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 42082f42969a3ce3c444032886ed3d47b14ec079 Author: Felix Fietkau Date: Mon Jul 27 15:04:27 2026 +0000 wifi: mt76: mt7915: fix chainmask handling for non-dbdc phys on band 1 [ Upstream commit ea891799eccc9e43ebba0dc157d4b197ad6c1a0e ] On single-adie mt7986 the only phy is bound to band 1, but its chainmask is stored unshifted, because dev->chainshift is still zero while the eeprom is parsed for the main phy. mt7915_set_antenna() on the other hand shifts by chainshift * band_idx, so the representation of the chainmask changed as soon as the antenna configuration was touched. Until then, mt7915_mcu_set_chan_info() passed rx_path = 0 to the firmware, since shifting the unshifted mask down clears all bits. Keep the unshifted form for that case and add helpers for the band local chainmask, so that only the band 1 phy of a dbdc device uses the shifted form. Fixes: 3eb50cc90534 ("wifi: mt76: mt7915: rely on band_idx of mt76_phy") Link: https://patch.msgid.link/20260727150434.1778520-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2c488baccd973bf6bb53dea0e54d56151281efe0 Author: Felix Fietkau Date: Mon Jul 27 15:04:26 2026 +0000 wifi: mt76: mt7996: do not leave state behind after a failed WED attach [ Upstream commit 6a4cabff1203791797683cf6be8f56bee983dc73 ] mt7996_mmio_wed_init() set dev->mt76.hwrro_mode and rx_token_size while building the WED configuration, before knowing whether the WED attach can succeed. A failed attach left the enlarged rx_token_size behind and reset hwrro_mode to MT76_HWRRO_OFF, clobbering the values that another RX datapath owner may have configured earlier in probe: on Airoha platforms with the wed_enable module parameter set, this broke the NPU offload configuration set up by mt76_npu_init() (NPU offload requires HW-RRO and a larger rx token space, and the attach always fails there since no SoC has both an Airoha NPU and MTK WED). Move both assignments after a successful attach, next to the existing success-only dma_dev/irq assignments. This is safe for the regular WED attach case: the first consumer of either field runs after probe continues (mtk_wed_device_attach() only invokes the init_buf callback; rx buffers are allocated via init_rx_buf from mtk_wed_start(), long after mt7996_mmio_wed_init() has returned). Within the WED configuration the HW-RRO checks were constant: the mode was assigned unconditionally right before them, and the hif2 path is only reachable after a successful main attach has set it. Resolve them to their constant values and drop the dead branches. Fixes: 377aa17d2aed ("wifi: mt76: mt7996: Add NPU offload support to MT7996 driver") Link: https://patch.msgid.link/20260727150434.1778520-7-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d566387df8306257d2f703a0d99fd9896400317e Author: Felix Fietkau Date: Mon Jul 27 15:04:25 2026 +0000 wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach failed [ Upstream commit 7c1924332e986019c6bcddf55c843361cccac73f ] If the WED attach for the primary PCIe function fails, the probe path still attached wed_hif2 for the secondary function, leaving the device in an inconsistent half-WED configuration that crashes later. The hif2 call also re-enabled hwrro_mode, which the failed primary attach had just turned off. Skip the hif2 WED setup when the primary WED device is not active. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Link: https://patch.msgid.link/20260727150434.1778520-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 865c798933a0389a535ffcaf5d99184f44f0f9f3 Author: StanleyYP Wang Date: Mon Jul 27 15:04:24 2026 +0000 wifi: mt76: mt7996: fix reg addr remap when addr is 0 [ Upstream commit eb906eeff2d1e84b628dc210dada325269c71383 ] When addr is less than the hardcoded threshold in __mt7996_reg_addr, it indicates that remapping is unnecessary. Currently, the flow remaps address 0x0 to MT_HIF_REMAP_BASE_L2, which is incorrect. To address this, modify __mt7996_reg_addr to return INVALID_REG_ADDR if the address is not below the hardcoded value or is not present in the mt7996_reg_map array. Additionally, update the remap condition to check if addr is equal to INVALID_REG_ADDR. Fixes: 3687854d3e7e ("wifi: mt76: mt7996: add locking for accessing mapped registers") Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20260727150434.1778520-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fb9c7b4c238b4e5469a11a1fb8cf332f6193b995 Author: Felix Fietkau Date: Mon Jul 27 15:04:23 2026 +0000 wifi: mt76: mt7915: release hif2 reference on probe IRQ failure [ Upstream commit 8370aebd26a9dfa2e0de665e3ab504c0e97ee730 ] The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2(). Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support") Link: https://patch.msgid.link/20260727150434.1778520-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 648f5f03ff50d4bd719106ace0cdf1d8be02cbdd Author: Felix Fietkau Date: Mon Jul 27 15:04:22 2026 +0000 wifi: mt76: mt7915: fix ext PHY use-after-free on register error path [ Upstream commit 15b960014f24dce5388d4a2e7274e6490cb3c421 ] After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free. Fixes: 7b8e1ae886e4 ("mt76: mt7915: rework hardware/phy initialization") Link: https://patch.msgid.link/20260727150434.1778520-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 29fbc5256c2d8448f084ff179d2e5092ecd1fc54 Author: Felix Fietkau Date: Mon Jul 27 15:04:21 2026 +0000 wifi: mt76: mt7915: fix double hif2 init on the non-WED path [ Upstream commit 3ae8ad277e2819a281b0e36b55633c8515c16ce7 ] mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL. Fixes: cacdd67812c6 ("mt76: mt7915: add mt7915_mmio_probe() as a common probing function") Link: https://patch.msgid.link/20260727150434.1778520-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9e02b1cfb163b6dcf6677a19befcbe794c74030d Author: Felix Fietkau Date: Mon Jul 27 15:04:20 2026 +0000 wifi: mt76: mt7996: fix MIB TX aggregation counter registers for mt7990 [ Upstream commit d0b750072a29c8ff0504c3bc28c411c402f26716 ] The MIB_TSCR0-7 counters read by mt7996_mac_update_stats() are hardcoded at the mt7996/mt7992 offsets 0x6b0-0x6d0, but mt7990 moved them to 0x750-0x770, so TX AMPDU statistics were read from unrelated registers on that chip. Move the offsets into the per-chip register tables. Fixes: f6c87411d15f ("wifi: mt76: mt7996: rework register mapping for mt7990") Link: https://patch.msgid.link/20260727150434.1778520-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 60eb18612d21657c720f99f23f712a8a1bd4934c Author: Felix Fietkau Date: Fri Jul 24 12:48:11 2026 +0000 wifi: mt76: set MT76_SCANNING when starting a hw scan [ Upstream commit 6ff1c217a00335c92aa6a9b35b3ff3b128efbfea ] The scan state bit is cleared by mt76_scan_complete(), but nothing ever sets it: mt76_sw_scan() is only called for drivers without hw scan support. As a result, all MT76_SCANNING checks are inert for drivers using mt76_hw_scan(), including the DFS state handling in mt76_phy_dfs_state() and the guard against manually triggered radar detection while scanning. Set the bit when the scan request is accepted. Since every channel programmed while scanning now evaluates the DFS state as disabled and stops the radar detector, re-program the operating channel at scan completion regardless of the off-channel state, after the scanning bit has been cleared. Otherwise a scan whose last visited channel was the operating channel, or one that returned to it early because of associated stations, would leave radar detection stopped until the next channel switch. Fixes: 31083e38548f ("wifi: mt76: add code for emulating hardware scanning") Link: https://patch.msgid.link/20260724124813.3961474-27-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fc3762724a36867c1749233c43368c2637ecf029 Author: Felix Fietkau Date: Fri Jul 24 12:48:10 2026 +0000 wifi: mt76: mt7996: clear stale link state on full reset [ Upstream commit 75d2a4e2129b58bb0ddb842387299038495aad2a ] After a full chip reset, mac80211 reconfig replays interface, link and channel context setup. mt7996_vif_link_add() short-circuits when the link_id is still marked in mvif->valid_links, a state introduced for postponing link teardown to interface removal. The reset path frees the link structures without clearing those bits, so the replayed setup never re-creates dev_info/bss_info/STA records in the restarted firmware and never re-registers the link wcid, leaving the device inoperative. The reset path also leaks every allocated MLD index: per-link indices and the per-vif group/remap indices are re-allocated from scratch during reconfig, but the old bits stay set in the masks, so repeated full resets exhaust the index space. Clear valid_links in the reset vif iterator and reset the MLD index masks alongside the existing omac_mask clearing. Fixes: ace5d3b6b49e ("wifi: mt76: mt7996: improve hardware restart reliability") Fixes: 08813703ac41 ("wifi: mt76: mt7996: Destroy vif active links in mt7996_remove_interface()") Link: https://patch.msgid.link/20260724124813.3961474-26-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8826d7a5e2dd727aa96456ccd58b33d2b080e935 Author: Felix Fietkau Date: Fri Jul 24 12:48:09 2026 +0000 wifi: mt76: mt7996: free vif links after clearing wcid entries on full reset [ Upstream commit 7e4208e9f6a876c2b7d28fdb6b86dff3b05db2f7 ] mt7996_mac_reset_vif_iter() queues non-default vif links for kfree_rcu while dev->wcid[] still holds pointers to the wcid embedded in each freed link; mt76_reset_device() then dereferences those entries and runs mt76_wcid_cleanup() on them. If a grace period elapses in between, the cleanup operates on freed memory. Run mt76_reset_device() first, so the wcid entries are cleaned up and cleared while the links are still valid. Fixes: ace5d3b6b49e ("wifi: mt76: mt7996: improve hardware restart reliability") Link: https://patch.msgid.link/20260724124813.3961474-25-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bb507affe9e2364092e1c968e67282d3411f8832 Author: Felix Fietkau Date: Fri Jul 24 12:48:03 2026 +0000 wifi: mt76: mt7996: wake MCU waiters before aborting scan in L1 SER [ Upstream commit 6f8d8c458010b597bf4114e6fb3162bff7050041 ] The L1 reset path calls mt76_abort_scan() between setting MT76_MCU_RESET and waking mcu.wait. A scan work blocked on an in-flight MCU command does not re-evaluate its wait condition until woken, so the cancel_delayed_work_sync() inside the abort sleeps out the full MCU timeout before recovery can proceed, adding several seconds of SER latency. mt7996_mac_full_reset() and the mt7915 counterpart already order the wake-up first. Wake mcu.wait immediately after setting MT76_MCU_RESET so in-flight commands bail out before the abort synchronises against them. Fixes: b36d55610215 ("wifi: mt76: abort scan/roc on hw restart") Link: https://patch.msgid.link/20260724124813.3961474-19-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c667ec75881cba1906096fc4d6aa9899b69c92f7 Author: Felix Fietkau Date: Fri Jul 24 12:48:02 2026 +0000 wifi: mt76: mt7996: skip key upload when adding an offchannel link [ Upstream commit ccb4bda277999959bc852480d8684b13b926e657 ] No hw keys are ever uploaded for scanning/roc links and the link remove path already skips the key iteration for them. The add path still runs it, and since mt7996_set_hw_key() resolves the target through mvif->link[link_id] rather than the offchannel link, starting a scan on another band re-uploads the group keys of the link sharing the same link_id, re-sending its BSS cipher info and, for BIGTK with beacon protection on an AP link, toggling its beacons off and on. Skip the key iteration for offchannel links, mirroring the remove path. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Link: https://patch.msgid.link/20260724124813.3961474-18-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit beaa42b875965dbc3e80e46970e0bfa60a94c2db Author: Felix Fietkau Date: Fri Jul 24 12:48:01 2026 +0000 wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement [ Upstream commit 16a04441eab0dcd4d7126a6f66b370adbf28f96d ] The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks. Fixes: 3782b69d03e7 ("mt76: mt7915: introduce mt7915_mac_add_twt_setup routine") Link: https://patch.msgid.link/20260724124813.3961474-17-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a6d7d7a253c550e74b0651897fe313c2f9b2301f Author: Yonghong Song Date: Tue Jul 28 22:02:04 2026 -0700 bpf, x86: Fix trampoline stack size for 128-bit arguments [ Upstream commit 814cba835ef648e0c5eb79505c96c0493b29eea6 ] btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it. Fixes: a9c5ad31fbdc ("bpf: x86: Support in-register struct arguments in trampoline programs") Signed-off-by: Yonghong Song Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260729050204.2586457-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit d36ac53fc83baf843c51b7afd6d2471f36b713d8 Author: Yonghong Song Date: Tue Jul 28 22:01:59 2026 -0700 bpf: Reject >8 byte return values on return-reading trampoline paths [ Upstream commit c48796aa6c392cde93946e5d5a9a1f1b1cf72feb ] btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init(). Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Signed-off-by: Yonghong Song Reviewed-by: Eduard Zingerman Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260729050159.2585809-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 2b33064072c8c7eb6dfde481bb7b8fdc7c9c488c 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 8cd0affed95c6c6c679211f0866f6bf4fc91b231 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 c2d36639d371c08c6193066e87d5257b24ea8343 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 2edeb8a9f07b64fe1564ff54f3a2b6d398fbecd8 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 f320fd080d0361e55830fa03eda1c3067b724fe2 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 e67b5cb76c5b90b975ca91bdae8ff519a85be941 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 c760be5c9f1b78783b10f7aec68320d660902251 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:08 2026 -0300 perf machine: Fix NULL parent dereference in fork event processing [ Upstream commit 73ac546bd6ba8ed4dc8d7a90fcb9bb8236de1568 ] machine__process_fork_event() calls machine__findnew_thread() for the parent thread, which can return NULL on allocation failure. The code then dereferences parent via thread__pid(parent) without a NULL check when validating whether the parent PID matches. The later NULL check at thread__fork() does not prevent this earlier dereference. Add a NULL guard before accessing the parent thread. Fixes: 5cb73340d92a ("perf tools: Make fork event processing more resilient") Reported-by: sashiko-bot Cc: Adrian Hunter 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 bb43829acdf47d7a2e86ece7822491b81ffbef6d Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:07 2026 -0300 perf machine: Fix fd leak on bounds check in maps__set_modules_path_dir() [ Upstream commit 23010160bb9fd6e7ce940e232cd660b37ab9b20b ] The bounds check for root_len >= path_size returns -1 directly without closing the directory fd opened by io_dir__init() a few lines above. Jump to the out label instead, which calls close(iod.dirfd). Fixes: e7af1946818b ("perf machine: Reuse module path buffer") Reported-by: sashiko-bot Cc: 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 201636c1cfd34c782deb6af150fcd173389e9fe2 Author: Michael Liang Date: Tue Jul 28 14:42:15 2026 -0600 perf libdw: Fix outer-frame name resolution and spurious "(inlined)" tag [ Upstream commit 022bcb6ba2d384d772f68477d11b2684afd6e715 ] cu_walk_functions_at() calls libdw_a2l_cb() with the containing DW_TAG_subprogram DIE first, then each DW_TAG_inlined_subroutine nested inside. The callback treated both the same way, causing two bugs: 1) die_name() returns the unqualified DW_AT_name, so every C++ frame lost its namespace/class prefix (ns::Class::method collapsed to method). 2) new_inline_sym() re-uses base_sym only when funcname matches base_sym->name exactly; otherwise it fabricates a fake symbol tagged "(inlined)". Any mismatch between the DWARF name and the ELF symbol name mis-tags an outer, non-inline frame as inlined. This hits C++ (die_name()'s unqualified output never matches the demangled ELF symbol) and it also hits C functions that GCC IPA-cloned (foo vs foo.isra.0 / .constprop / .part / .cold), since DW_AT_linkage_name doesn't reflect those renames. Fix both: * Prefer die_get_linkage_name() (mangled, fully qualified), falling back to die_name() when absent (C, extern "C"). new_inline_sym() already demangles via dso__demangle_sym(). * For DW_TAG_subprogram DIEs, use base_sym directly -- the DIE tag already tells us it is the outer function, sidestepping the name comparison entirely for both C++ qualification and GCC IPA-clone renames. Fixes: 88c51002d06f9a68 ("perf addr2line: Add a libdw implementation") Signed-off-by: Michael Liang Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit da56e16f429308674e7033f4fd9e521c46b12993 Author: Alessio Podda Date: Fri Jul 24 17:40:57 2026 +0200 perf unwind-libdw: Fix unwinding of multi-threaded processes [ Upstream commit f2effca1ef5d30b1ead61d74faea5e251f604a26 ] The libdw callback API has two levels: dwfl_getthread_frames() first finds the requested thread using the next_thread() or get_thread() callback and then walks its stack. Since perf only has a snapshot of the stack of a single thread, it provides a stubbed-out API that always returns the pid the Dwfl was attached with (i.e. whatever was passed to dwfl_attach_state()), rather than the actual sampled thread's TID. Commit 6b2658b3f36a ("perf unwind-libdw: Don't discard loaded ELF/DWARF after every unwind") changed libdw unwinding from recreating the Dwfl object for each sample to caching it in struct maps, which is shared by every thread in the process. It left next_thread() unchanged. Since the pid passed to dwfl_attach_state() is only set at creation, only the thread of the first sample is ever found. As a result, dwfl_getthread_frames() fails with ESRCH when asked to unwind a sample from another thread. Make next_thread() return the current sample's TID, provide get_thread() so libdw can find it directly, and pass the process PID expected by dwfl_attach_state(). This allows libdw to unwind samples from every thread in a multi-threaded process. Add a shell regression test that records a four-thread workload and verifies that libdw recovers the worker callchain for every worker TID. Fixes: 6b2658b3f36a ("perf unwind-libdw: Don't discard loaded ELF/DWARF after every unwind") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Alessio Podda Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit cb8f0d60160beb1e119d9f4622aaf9b638e8ccc8 Author: Charles Keepax Date: Thu Jul 30 14:06:02 2026 +0100 ASoC: SDCA: Add missing stub for sdca_fdl_free_state() [ Upstream commit f6970d8535a95c137f05e9ca825072de3b217b88 ] There should be a stub for sdca_fdl_free_state() for the case FDL support isn't built into the kernel. Add the missing stub. Fixes: 0880082c27b6 ("ASoC: SDCA: Remove devm from primary IRQ cleanup") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607291304.FE3mOcJF-lkp@intel.com/ Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260730130602.3747053-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29dc2e24f6adb36dcb884acf455644c397a67471 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 cc6a0133c7495f27e4730cdef7fa471537427d31 Author: Ashish Mhetre Date: Mon Jun 22 06:54:10 2026 +0000 arm64: tegra: Fix CMDQV interrupt type on Tegra264 [ Upstream commit 5af7a8a522f61ae2a3e5038c889e231e56d63526 ] The CMDQV interrupts on Tegra264 are described as level-triggered, but per the hardware interrupt documentation these interrupts are actually edge-triggered. Correct the interrupt type for all CMDQV nodes from IRQ_TYPE_LEVEL_HIGH to IRQ_TYPE_EDGE_RISING. Fixes: fe57d0ac4835 ("arm64: tegra: Add nodes for CMDQV") Reported-by: Nicolin Chen Signed-off-by: Ashish Mhetre Acked-by: Jon Hunter Acked-by: Nicolin Chen Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 3a504288644374ae232a4ed538b0dc2c913a7363 Author: Yuho Choi Date: Fri Jul 3 11:50:22 2026 -0400 ARM: tegra: Fix OF node reference leaks in IRQ init [ Upstream commit 7acac0cabaac6967e1f987bfedd4418204c813a7 ] tegra114_gic_cpu_pm_registration() and tegra_init_irq() use of_find_matching_node() for temporary IRQ init lookups, but the helper returns a referenced node even when the result is used only as a boolean or as an of_iomap() input. Use scoped device_node cleanup for both lookups so the references are dropped when the functions return. Fixes: 7e8b15dbc392 ("ARM: tegra114: Reprogram GIC CPU interface to bypass IRQ on CPU PM entry") Fixes: e9479e0e832b ("ARM: tegra: skip gic_arch_extn setup if DT has a LIC node") Signed-off-by: Yuho Choi Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 08331ff6fffadd79dbb3f97b279a59fed9629069 Author: Andrey Golovko Date: Mon Jul 27 12:33:09 2026 +0300 ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach [ Upstream commit b627da43035744ca4d691fbf56eef60268319873 ] When the peripheral re-attaches after the SoundWire controller was power-gated during system suspend (s2idle reaching S0i3 on AMD ACP), the amplifier has lost all of its register and DSP state. tas_update_status() handles that by re-running tas_io_init(), which writes the device's TAS2783_SW_RESET register - a vendor register write that clears the device's register file and DSP state, not a SoundWire reset, so no re-enumeration is involved - and re-downloads the firmware. Before doing any of that, it syncs back a register cache that still holds the pre-suspend values. That sync is useless, since the reset immediately wipes whatever it wrote, and it leaves the cache claiming that the amplifier is already powered up and unmuted. Subsequent read-modify-write updates - DAPM amplifier power-up, SDCA PDE transitions at stream start - then see "no change" and skip the hardware write. Playback runs without a single error while the speakers stay silent. Unbinding and rebinding the driver restores audio, since probe starts from a fresh cache. Drop the cache instead of syncing it when an uninitialized device attaches, so that later accesses see the real hardware state. Reordering the sync after tas_io_init() and marking the cache dirty is not a workable alternative here: tas_regmap has no .writeable_reg, so the cache accepts every register up to .max_register, including ones for which tas2783_sdca_mbq_size() returns 0. regmap_sdw_mbq_size() rejects those with -EINVAL, so the replay fails on the first such register and takes initialization down with it. Cached user settings fall back to hardware defaults across such a power loss, which seems clearly preferable to a silent amplifier - the device is being reset and its firmware reloaded at this point anyway. Tested on an ASUS ProArt PX13 HN7306EAC (AMD Strix Halo, ACP7.0, two TAS2783 amplifiers plus RT721 on SoundWire link 1): the speakers work after an s2idle resume with ~51 s of S0i3 residency, where previously they stayed silent despite a complete firmware re-download. Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") Reported-by: Antoine Monnet Closes: https://lore.kernel.org/all/c66ae00a-e878-4af0-a05a-272e9574eaa5@montane.tech/ Signed-off-by: Andrey Golovko Link: https://patch.msgid.link/3e2751d1fb027bed0f09c88e5e56da8f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bfa756f3b8bf8c25ac9f2db0a83ac8a5e368f89b Author: Pengpeng Hou Date: Sat Jul 4 11:57:46 2026 +0800 ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors [ Upstream commit 0d6b2d6f93a6715827a9b3c027cd8448d76e0e47 ] regcache_sync() can fail while replaying cached register state after SoundWire resume or attach handling. tas2783 currently ignores that failure. Propagate the error and restore cache-only/dirty state on failure. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704035746.82560-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Stable-dep-of: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach") Signed-off-by: Sasha Levin commit 047a817147806140cdef5fa25d69d7b7a24f905c 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 00008e6f544c2d480f920ab1e593a46cfb87cead 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 e532b800728d7f0df52e767e1adef5880a8ee19b Author: Konrad Dybcio Date: Tue Jul 28 15:20:46 2026 +0200 drm/msm/dp: Drop dev_pm_opp_set_rate(0) [ Upstream commit cebfa9909e27ec7b7cbaec25ee5516cf886baa39 ] 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 calls to it. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/742781/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-2-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 54b17a858b8be422f8edbd98690773b864766ace Author: Konrad Dybcio Date: Tue Jul 28 15:20:45 2026 +0200 drm/msm/dpu: Drop sneaky dev_pm_opp_set_rate(0) [ Upstream commit 811c38907eab0f66c22c5e5708e6f8eab14d76fa ] 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. Prevent that from happening when _dpu_core_perf_get_core_clk_rate() returns 0. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/742779/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-1-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 8a3aee5143ea80cf1726e1c045aaac6c0664af0e 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 2350896a36b5863e3f55b673688f22ea85b9c7c0 Author: Dmitry Baryshkov Date: Wed Jul 22 09:36:30 2026 +0300 drm/msm/dp: do not reject wide-bus modes while a YUV420 mode is active [ Upstream commit bd926e62d355879133452bc3889447f8e89757f2 ] msm_dp_bridge_mode_valid() halves the candidate mode's pixel clock when the sink either uses YUV 420 output or drives the wide bus, so that modes relying on those to stay under DP_MAX_PIXEL_CLK_KHZ are accepted. The wide bus part is queried through msm_dp_wide_bus_available(), which returns false whenever the currently committed mode uses YUV 420 output: it inspects the stored msm_dp_mode.out_fmt_is_yuv_420 of the active mode, not the mode being validated. Consequently, while a YUV 420 mode is active, an RGB mode that needs the wide bus to fit under DP_MAX_PIXEL_CLK_KHZ has its pixel clock left un-halved and is wrongly rejected as MODE_CLOCK_HIGH. The candidate mode's YUV 420 status is already evaluated as is_yuv_420, and the wide bus is disabled precisely for YUV 420 output, so halving the pixel clock for either case is equivalent to halving it when the candidate is YUV 420 or the controller supports the wide bus. Test wide_bus_supported directly, so the decision no longer depends on the format of the active mode. Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/741740/ Link: https://lore.kernel.org/r/20260722-drm-msm-display-interface-v1-15-368c10fe62fd@oss.qualcomm.com Signed-off-by: Sasha Levin commit c89d481a50de222b4ea59106260cfc33f8a6a498 Author: Dmitry Baryshkov Date: Wed Jul 22 09:36:16 2026 +0300 drm/msm/dp: reject YUV420-only modes without VSC SDP support [ Upstream commit 684f95fb4e9ad10aac39fbb1fa7592a59d7f54ea ] DP conveys YUV 420 colorimetry through a VSC SDP. A sink that advertises a mode as YUV-420-only therefore cannot be driven at all unless the panel supports VSC SDP, yet msm_dp_bridge_mode_valid() only used the VSC SDP capability to decide whether to halve the pixel clock, otherwise letting such modes through to be validated (and possibly accepted) at the full RGB clock the sink cannot display. Reject 420-only modes with MODE_NO_420 when the panel does not support VSC SDP. With those modes filtered out, being a 420-only mode implies VSC SDP support, so the YUV-420 test reduces to drm_mode_is_420_only(): drop msm_dp_is_yuv_420_enabled() and call the DRM helper directly at its two callers (the DPU encoder already has the connector from the atomic state). Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/741713/ Link: https://lore.kernel.org/r/20260722-drm-msm-display-interface-v1-1-368c10fe62fd@oss.qualcomm.com Signed-off-by: Sasha Levin commit e2a99fa93b400dfbb9598103249f71969501094a Author: Dmitry Baryshkov Date: Thu Jul 23 12:52:12 2026 +0300 drm/msm: don't tear down KMS twice when KMS init fails [ Upstream commit 93c125e4ea98fb25f927ba5a334d85845127d667 ] When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash. Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths. The crash trace for the reference: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Fixes: 506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/742068/ Link: https://lore.kernel.org/r/20260723-msm-fix-crash-v1-1-78fb4721c2d9@oss.qualcomm.com Signed-off-by: Sasha Levin commit 0f00f6848f6b6c0944d1ae3d4bc89ccdf4c3011c Author: Yongxing Mou Date: Mon Jul 20 15:56:08 2026 +0800 drm/msm/dpu: Fix DMA SSPP REC block offsets on DPU v13 [ Upstream commit 8834f5494ab5e169b1c0fb4cbcb5464fd81d1ed0 ] On DPU v13, the DMA SSPP REC0 and REC1 blocks are located at offsets 0x1000 and 0x3000 from the SSPP common base. The existing DMA SSPP sub-block descriptor does not initialize sspp_rec0_blk and sspp_rec1_blk, causing REC register accesses to be performed at offset 0 instead of the corresponding REC block. As a result, DMA SSPP pipes are not programmed correctly and fail to produce output. Introduce a DPU v13 specific DMA SSPP descriptor with the correct REC block offsets and use it for all DMA SSPPs in the Kaanapali catalog. Signed-off-by: Yongxing Mou Fixes: 83fe2cd56b1d ("drm/msm/dpu: Add support for Kaanapali DPU") Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/741230/ Link: https://lore.kernel.org/r/20260720-dpu-v13-dma-sspp-rec-fix-v1-1-10d69b4875e7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 182cd086b31ea4ccc1d8f2ec5b81e988dfe0b892 Author: Can Peng Date: Wed Jul 29 10:36:05 2026 +0800 ACPI: processor: Unregister cpufreq notifier on init failure [ Upstream commit 06f32dd67e6b23a05bef0d8183c5335af91c0c3b ] acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered. Fixes: c0e0421a60bf ("ACPI: processor: Reorder acpi_processor_driver_init()") Signed-off-by: Can Peng Link: https://patch.msgid.link/20260729023605.197367-1-pengcan@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1558c267b78b141f174f70f83d0812583abbd762 Author: Felix Fietkau Date: Fri Jul 24 12:47:58 2026 +0000 wifi: mt76: only consume the WO drop bit on WED v2 devices [ Upstream commit 1df54335590bb025c3bd706a9ba9c6e73a1d3000 ] The RX path is handled by the WO MCU only on WED v2 hardware. On WED v3 the same buf1 bit does not carry drop information, so evaluating it there causes spurious RX drops. Fixes: e4d2b8bcac11 ("wifi: mt76: drop the incorrect scatter and gather frame") Link: https://patch.msgid.link/20260724124813.3961474-14-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4087cff2389c9860e01f68b88e6994b8d275a8fe Author: StanleyYP Wang Date: Fri Jul 24 12:47:57 2026 +0000 wifi: mt76: mt7996: add missing rdd_idx check when enabling background radar [ Upstream commit dbca5c4d29826cecd3185fb1ae2746205ab55127 ] Add the missing rdd idx check (< 0) in mt7996_mcu_rdd_background_enable(). mt7996_get_rdd_idx() returns -1 for phys without 5 GHz support, and the negative index was passed to the RDD MCU command unchecked. Fixes: 1529e335f93d ("wifi: mt76: mt7996: rework radar HWRDD idx") Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20260724124813.3961474-13-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2bcbbfaaa648d6f4977a4c854c8d207e840a8f08 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 e1383c17fb5d1649b040248566cce6b0c0ff9a6b Author: Felix Fietkau Date: Fri Jul 24 12:47:55 2026 +0000 wifi: mt76: report data NSS for STBC frames in RX rate decode [ Upstream commit 4238535e85d41abe6fad545bbcdb3d91d191637f ] The RX rate decoder set status->nss straight from the PRXV NSTS field, which for STBC frames is twice the data spatial-stream count. cfg80211 then reported a doubled RX bitrate in station dumps and radiotap. Halve nss for STBC, matching the TX status path. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Fixes: d832f5e73815 ("mt76: connac: move mt76_connac2_mac_fill_rx_rate in connac module") Link: https://patch.msgid.link/20260724124813.3961474-11-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c4dc85481d38951ca7f8bc104e711936306cc664 Author: Felix Fietkau Date: Fri Jul 24 12:47:54 2026 +0000 wifi: mt76: cancel reset and rc work on device unregister [ Upstream commit e995d3dccc9d980af13a60ad37409ed1561f9eeb ] Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260724124813.3961474-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ea69a378d77caf5ce7ee0514b361f5c6a226b88f Author: Felix Fietkau Date: Fri Jul 24 12:47:53 2026 +0000 wifi: mt76: mt7996: don't leak MLD group index on remap alloc failure [ Upstream commit 151a6cf0d12f5d333b93b634dbe5834ea0b77ce7 ] mt7996_change_vif_links() sets the mld_idx_mask group bit before allocating the remap index. If the remap allocation fails it jumped to the exit without clearing that bit, permanently consuming one of the 16 MLD group slots. Release the group bit on the error path. Fixes: 4fb3b4e7d1ca ("wifi: mt76: mt7996: fix MLD group index assignment") Link: https://patch.msgid.link/20260724124813.3961474-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1a51aff0e048dc5b8252d65808b79939c942d6ec Author: Felix Fietkau Date: Fri Jul 24 12:47:52 2026 +0000 wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV [ Upstream commit 50c66bab321140c49aa2ed779a3ec9d2f085b458 ] When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260724124813.3961474-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 01e3d5707522e445c9792744614caf0ad44fc721 Author: Felix Fietkau Date: Fri Jul 24 12:47:51 2026 +0000 wifi: mt76: fix ER-SU 106-tone RU check in RX rate decode [ Upstream commit 29fe963d86e434b32d07958a6785be724e45c787 ] MT_PHY_TYPE_HE_EXT_SU is an enum value (9), not a bit flag, so the bitwise test "*mode & MT_PHY_TYPE_HE_EXT_SU" also matches OFDM, HT-GF and several HE/EHT modes. Only genuine ER-SU should be classified as a 106-tone RU at 40 MHz; use an equality comparison. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Fixes: d832f5e73815 ("mt76: connac: move mt76_connac2_mac_fill_rx_rate in connac module") Link: https://patch.msgid.link/20260724124813.3961474-7-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5f9c09e948cea14c4a7f66ad67865ced80c55c0e Author: Felix Fietkau Date: Fri Jul 24 12:47:50 2026 +0000 wifi: mt76: decode the full VHT Rx STBC capability field [ Upstream commit e8b76a6e0d04d13ae55dc746a270f382825c395b ] The Rx STBC subfield of the VHT capabilities is a 3-bit cumulative value, but the driver only tested the RXSTBC_1 bit when advertising the peer's Rx STBC support to firmware. A peer reporting Rx STBC of 2, 3 or 4 has that bit clear, so STBC was never used towards it. Test the full IEEE80211_VHT_CAP_RXSTBC_MASK, matching the HT path. Fixes: 046d2e7c50e3 ("mac80211: prepare sta handling for MLO support") Fixes: 2660fde82f65 ("wifi: mt76: mt7996: Update mt7996_mcu_add_rate_ctrl to MLO") Link: https://patch.msgid.link/20260724124813.3961474-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 594c4b7f89f9ea75dc9c50b5e4c4296db4a3d701 Author: Felix Fietkau Date: Fri Jul 24 12:47:49 2026 +0000 wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER [ Upstream commit 6190db312b8230813f529f014b26247c6d9800d0 ] mt7996_mac_reset_work() parked the tx worker and disabled the RX/TX NAPIs before taking dev->mt76.mutex. mt76_worker_disable()/_enable() are plain kthread park/unpark, not refcounted, and __mt76_set_channel() toggles the same worker and the MT76_RESET bit under the mutex. An L1 SER racing a channel switch could therefore have the worker unparked and MT76_RESET cleared while the reset path resets the DMA rings, corrupting descriptors or tokens. Take the mutex before disabling the worker, as mt7915 does. Fixes: 27015b6fbcca ("wifi: mt76: mt7996: enable full system reset support") Link: https://patch.msgid.link/20260724124813.3961474-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 71bf9de2ab3fb2c54bedb0b4c9b468d2e1d55280 Author: Felix Fietkau Date: Fri Jul 24 12:47:48 2026 +0000 wifi: mt76: mt7915: unwind state on add_interface failure [ Upstream commit 2fb6480c52f611338e1b0abe5e6219be1fc9ab75 ] When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind. Fixes: b619e01380ee ("mt76: fix MBSS index condition in DBDC mode") Link: https://patch.msgid.link/20260724124813.3961474-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6ed0fba58bb125a8d8de96e391aa86111166efca Author: Felix Fietkau Date: Fri Jul 24 12:47:47 2026 +0000 wifi: mt76: fix out-of-bounds access in mmio copy helpers [ Upstream commit 6689b4a65e88d7b019e687fa9d6943ca070f3e43 ] mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged. Fixes: 2df00805f7db ("wifi: mt76: mmio_*_copy fix byte order and alignment") Link: https://patch.msgid.link/20260724124813.3961474-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93eaddfdd35aa6bfe570c087db4e97fb9d8a791a Author: Felix Fietkau Date: Fri Jul 24 12:47:46 2026 +0000 wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config [ Upstream commit 44af52467e72094351a362bf69effd52f1d9c186 ] The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb. Fixes: 5d33053be609 ("wifi: mt76: mt7996: add variants support") Link: https://patch.msgid.link/20260724124813.3961474-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e6a7cfe0731912471425458e85bd36e05aaf5dea Author: Felix Fietkau Date: Fri Jul 24 12:47:45 2026 +0000 wifi: mt76: fix HE DCM max-RU capability encoding [ Upstream commit cbeed7096794f748d16c78cd9d3e0004420d1e9d ] sta_rec_he.dcm_rx_max_nss was assigned twice: the second assignment, sourced from HE PHY capability byte 8 (DCM max RU), overwrote the RX-NSS value and left dcm_max_ru at zero. Every associated HE station advertising DCM support was configured in firmware with a wrong dcm_rx_max_nss and a zero dcm_max_ru. Store the DCM max-RU value in dcm_max_ru as intended. The same copy-paste error existed in both the shared connac2 path and the mt7915 path. Fixes: c336318f57a9 ("mt76: mt7915: add HE capabilities support for peers") Fixes: 67aa27431c7f ("mt76: mt7921: rely on mt76_connac_mcu common library") Link: https://patch.msgid.link/20260724124813.3961474-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fd5a8b049a7e5a39eb1bd30400c3c20d2eb1be13 Author: Rex Lu Date: Wed Jul 22 08:25:54 2026 +0000 wifi: mt76: check txfree done event on the WED hw path [ Upstream commit 3310e71a74b176d3613dfb42b6bc630d99e90cbb ] Check the txfree done event DW1 bit 15 when WED is enabled, to avoid the driver reading a txfree done event before WED has finished reading it. No need to check this flag on WED v2, otherwise SER will occur. The bit position was previously defined as MT_DMA_CTL_BURST, which is unused; rename it to match its function on the txfree ring. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260722082610.2699628-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 636ab58493fc2e75ee0076fb736ebd5f9786c0e2 Author: Felix Fietkau Date: Wed Jul 22 08:26:10 2026 +0000 wifi: mt76: mt7915: poll the correct SLP CTRL register for the second adie [ Upstream commit dd59a6126a8f1bd52bf6bd057bf0c8307f76a74b ] The clock enable path for the second adie sets MT_ADIE_SLP_CTRL_CK0(1) but polled the busy bit of MT_ADIE_SLP_CTRL_CK0(0), so dual-adie bring-up could proceed before the adie1 clock was stable. Fixes: 99ad32a4ca3a ("mt76: mt7915: add support for MT7986") Link: https://patch.msgid.link/20260722082610.2699628-18-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a273dc3b86a7d983d643827d3d3c795d55d8f632 Author: Felix Fietkau Date: Wed Jul 22 08:26:09 2026 +0000 wifi: mt76: fix RXDMAD_C buffer recycling race [ Upstream commit e1f97c10a4ec2b9db69a134b757304399ca903ce ] The RXDMAD_C buffers come from the RRO data queues' page pools, which are bound to a different NAPI, so the direct page-pool recycle used here could race the owning NAPI; take the non-direct path as is already done for WED RX queues. Fixes: e50d4d710efd ("wifi: mt76: Add mt76_dma_get_rxdmad_c_buf utility routione") Link: https://patch.msgid.link/20260722082610.2699628-17-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a83bc76d17131fbb24446949cd3b3bcff961f943 Author: Felix Fietkau Date: Wed Jul 22 08:26:08 2026 +0000 wifi: mt76: fix uninitialised RXDMAD_C descriptor info [ Upstream commit d3ecac68f73b11828e72eaf7952a9beb5caea12b ] Unlike other WED-RRO queues, RXDMAD_C frames continue into the skb build path, but mt76_dma_get_buf() skips the desc->info read for RRO queues, so the uninitialised on-stack info was stored into skb->cb and passed to rx_skb(); initialise it to zero. Fixes: e50d4d710efd ("wifi: mt76: Add mt76_dma_get_rxdmad_c_buf utility routione") Link: https://patch.msgid.link/20260722082610.2699628-16-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0fd0bad6248dc7cb28f4b34f545bc2d76e0461a3 Author: Felix Fietkau Date: Wed Jul 22 08:26:06 2026 +0000 wifi: mt76: fix stranded frames in mt76_txq_schedule_pending [ Upstream commit 422dd2db28ae27c35a586acd9ad482f30000c090 ] A wcid is added to phy->tx_list whenever either tx_pending or tx_offchannel becomes non-empty, but the requeue check after a partial schedule required BOTH queues to be non-empty. When mt76_txq_schedule_pending_wcid() returns -1 (queue stopped or MT76_RESET) it leaves frames in tx_pending while tx_offchannel is empty, so the wcid is dropped from every scheduling list and its frames stall until the next mt76_tx() for that wcid or wcid cleanup. This strands EAPOL/mgmt/nullfunc frames under momentary queue-full or across scan/channel-switch, causing association and 4-way-handshake timeouts. Requeue when either queue still holds frames, matching the enqueue condition. Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Link: https://patch.msgid.link/20260722082610.2699628-14-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a68447b884548dce7901d8d15d93a864714477b4 Author: Felix Fietkau Date: Wed Jul 22 08:26:04 2026 +0000 wifi: mt76: fix 4th chain ACK RSSI bitmask in sta_poll [ Upstream commit 5caa622956166f6c445a384c7e964da4d553a501 ] The per-chain response-frame RSSI values are packed one per byte, but the 4th chain was extracted with GENMASK(31, 14) instead of GENMASK(31, 24). The wrong mask overlaps chains 1-3 and shifts by 14, producing a garbage chain-3 value that corrupts ack_signal/avg_ack_signal on 4x4 radios. Extract the correct byte. Fixes: a71b648e3527 ("wifi: mt76: mt7915: add ack signal support") Fixes: ea5d99d07fbf ("wifi: mt76: mt7996: enable ack signal support") Fixes: 67fc7a304bf5 ("wifi: mt76: mt7921: add ack signal support") Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Link: https://patch.msgid.link/20260722082610.2699628-12-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93ce0dae8e770f473e9baeb60fbff135028b1d32 Author: Felix Fietkau Date: Wed Jul 22 08:26:03 2026 +0000 wifi: mt76: mt7915: write RX header translation bit to the correct register [ Upstream commit 236145737480c4c0c515e09061d0d5f77cf52d3f ] MT_MDP_DCR0_RX_HDR_TRANS_EN is a field of MT_MDP_DCR0, but monitor-mode handling applied it to the per-band MT_DMA_DCR0 register instead. As a result RX header translation was never disabled in the MDP when entering monitor mode, and an undocumented bit of MT_DMA_DCR0 was toggled. Target MT_MDP_DCR0, matching the mt7996 driver. Fixes: b2491018587a ("wifi: mt76: mt7915: fix monitor mode issues") Link: https://patch.msgid.link/20260722082610.2699628-11-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7b47f11d6ce0f35b8cc96298736e0b05a55f8992 Author: Felix Fietkau Date: Wed Jul 22 08:26:02 2026 +0000 wifi: mt76: mt7996: don't report a zero TX bitrate [ Upstream commit d4d92ccded678c92c390003926097ddbb6516bc7 ] mt7996_sta_statistics() set NL80211_STA_INFO_TX_BITRATE unconditionally after the block that already sets it, so a station with no rate info yet was reported to userspace with a valid-but-zero TX rate. Drop the redundant unconditional assignments; the in-block ones are sufficient. Fixes: b34f346b917e ("wifi: mt76: mt7996: drop return in mt7996_sta_statistics") Link: https://patch.msgid.link/20260722082610.2699628-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ecfd1a07e78c31d81322fb2d81dc468081cc3004 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 a97b2b942d2f8f12fbd6a7caafc735d1ad115e6b Author: Felix Fietkau Date: Wed Jul 22 08:26:00 2026 +0000 wifi: mt76: mt7915: clear wcid mask under mutex after RCU pointer clear [ Upstream commit 6486e11a6e2f679597af2d5bb48c3b07a2b2a7ba ] mt7915_remove_interface() cleared the wcid mask bit with no lock held and before clearing the RCU wcid pointer. The mask is a non-atomic RMW shared with the allocators, which all run under dev->mt76.mutex; on DBDC the two wiphys share one mt76_dev, so this raced add_interface/sta_add on the other band and could leak or double-hand-out a wcid. Clearing the bit before the RCU pointer also let a concurrent allocation reuse the index and publish its wcid, which the subsequent NULL assignment then wiped. Move the clear into the existing mutex section, after the RCU pointer is cleared. Fixes: f3049b88b2b3 ("wifi: mt76: mt7915: allocate vif wcid in the same range as stations") Link: https://patch.msgid.link/20260722082610.2699628-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4b92027fd043aa86f42572124cc2c58274f15e74 Author: Felix Fietkau Date: Wed Jul 22 08:25:59 2026 +0000 wifi: mt76: mt7996: set MT76_MCU_RESET before waking MCU waiters on full reset [ Upstream commit 6469ae71e7e5d0132c934972f628f346ad0379cd ] mt7996_mac_full_reset() called wake_up(&dev->mt76.mcu.wait) without first setting MT76_MCU_RESET. The MCU response wait condition only checks the response queue and that bit, so the wake-up released nobody: a thread blocked in an MCU command against the dead firmware (typically holding dev->mt76.mutex) stayed asleep until its multi-second timeout, stalling recovery. Set the bit before the wake-up, as mt7915 does. Fixes: 27015b6fbcca ("wifi: mt76: mt7996: enable full system reset support") Link: https://patch.msgid.link/20260722082610.2699628-7-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b1c5cf8903bec5476a2233b4e45287b9a2213e02 Author: Felix Fietkau Date: Wed Jul 22 08:25:58 2026 +0000 wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] [ Upstream commit 2243778a5fae8329ab5f18e7adcd7e03b911a1b7 ] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid(). Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260722082610.2699628-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1584fd436132cf830486032a1002fa0d7cdbbfd1 Author: Michael-CY Lee Date: Wed Jul 22 08:25:57 2026 +0000 wifi: mt76: assign link_id when sending probe request during scan [ Upstream commit f137fabc1313427e08af06a414d929ebd9fd37d6 ] The link_id in info->control.flags is required by mt7996 to select the correct mt76_wcid for transmission. Not assigning the link_id in info->control.flags is equivalent to assigning the link_id to 0, causing mt7996 to select link_id 0 for transmission, so probe requests sent on behalf of an MLD vif scanning via a different link were transmitted with the wrong per-link wcid. Fixes: 31083e38548f ("wifi: mt76: add code for emulating hardware scanning") Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20260722082610.2699628-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 186c957ac3325aefb982567ffdd3654b283688a7 Author: Michael-CY Lee Date: Wed Jul 22 08:25:56 2026 +0000 wifi: mt76: fix non-AQL packet accounting for MLO stations [ Upstream commit 8ae659743ba936b22ecb4620815887728e2820d6 ] __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry. Fixes: e1378e5228aa ("mt76: rely on AQL for burst size limits on tx queueing") Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20260722082610.2699628-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0a951ff6704db7b46c3f6d03b77e6053122be8ab Author: Peter Chiu Date: Wed Jul 22 08:25:55 2026 +0000 wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP [ Upstream commit ce35ecffc96e6d097d27b6fe30677a2cfe2e0461 ] Problem: MCU command timeout while the firmware state is normal, and the firmware keeps showing the error log "ERROR!! NO PAUSE...". Root cause: If the MLD_ID field in the TXD is neither the primary link id nor the secondary link id, it may lead to a firmware busy loop when the third link is in power saving mode. Remap frames directed to a third link to the primary link wcid. Since TX status events and txfree completions carry the wcid the firmware saw, use the remapped wcid for packet id tracking and non-AQL packet accounting as well, while the frame keeps its original link context for addressing, band and OMAC selection. Fixes: 85cd5534a3f2 ("wifi: mt76: mt7996: use correct link_id when filling TXD and TXP") Signed-off-by: Peter Chiu Link: https://patch.msgid.link/20260722082610.2699628-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit db4be207f3f6d8886f0b31f8c7db863a4b835ec1 Author: Rex Lu Date: Wed Jul 22 08:25:53 2026 +0000 wifi: mt76: fix RX data queuing of RRO 3.0 [ Upstream commit 86897f106669c07eea4c34b54c3268d448d41426 ] For RRO 3.0, RX data released from a RRO data queue should be put to the indicator queue. The frames are processed and completed in the context of the indicator queue NAPI, which only polls skbs queued on the MT_RXQ_RRO_IND list; frames queued under the data queue id are left sitting on that list until the data queue NAPI happens to run, stalling and reordering RX data. Fixes: b1e58e137b61 ("wifi: mt76: mt7996: Introduce RRO MSDU callbacks") Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260722082610.2699628-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 253b30a739ca1761792e0ac6f1dc64b96e492c2e Author: Shayne Chen Date: Fri Mar 13 14:21:50 2026 +0800 wifi: mt76: mt7996: fix capability of EHT-MCS 15 in MRU [ Upstream commit 29e889c4ada83c69d10a3937f5ae2934306e2e3d ] According to the definition in IEEE Std 802.11be-2024, Table 9-417r: - If 80 MHz is not supported, bit 1-3 are set to 0. - If 160 MHz is not supported, bit 2-3 are set to 0. - If 320 MHz is not supported, bit 3 is set to 0. Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260313062150.3165433-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a142565452eef15cf5252c5fddf873fc1cd1e393 Author: Chad Monroe Date: Tue Jul 21 18:53:33 2026 +0000 wifi: mt76: mt7996: fix non-MLD station num_sta leak [ Upstream commit 2087f029924b75324cfa9a41ba1a349a9620f06e ] The MLO link-reconfiguration rework moved the per-phy num_sta decrement inside a link_valid guard. link_valid is only set for MLO links, but num_sta is incremented for every station link, including the non-MLO deflink. Non-MLO stations bump num_sta on association and never drop it on removal. A non-zero num_sta forces connected-mode off-channel scanning which prevents the directed probe exchange needed to find hidden APs. Decrement phy->num_sta on the actual link teardown, pairing it with the unconditional increment on link creation. Fixes: e8c819df0243 ("wifi: mt76: mt7996: Destroy active sta links in mt7996_mac_sta_remove()") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20260721185333.2419297-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 85a0d0bf9726654cfe08fd6a0ee0b1baf90d2dc3 Author: Chad Monroe Date: Tue Jul 21 18:53:32 2026 +0000 wifi: mt76: mt7996: fix EAPOL source BSS for non-MLD stations [ Upstream commit 6bb5066cfcd4296ac5e0b6872f43f96a43bfe566 ] A non-MLD station's EAPOL and data frames are tagged with link_id == IEEE80211_LINK_UNSPECIFIED, which now skips the per-link lookup in mt7996_mac_write_txwi() and leaves omac_idx/band_idx/wmm_idx at slot 0. When the radio also runs AP VAPs the station's omac is non-zero (get_omac_idx() prefers HW BSSID slots 1-3), so its EAPOL frames egress from the wrong BSS and the 4-way handshake times out even though association succeeds. In mt7996_tx_prepare_skb(), resolve the link from the peer wcid when link_id is UNSPECIFIED and the wcid is not the global entry, restoring the pre-MLO behaviour for station traffic. Fixes: 729c83a3330c ("wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20260721185333.2419297-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6a342db7a6502bc6781579145e05d4d4731786ab Author: Eason Lai Date: Fri Jul 3 08:59:45 2026 +0800 wifi: mt76: mt792x: Fix memory leak in SDIO TX path [ Upstream commit 808f2767d4217a5b96f674288573b9b89d432eed ] When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails. Fixes: b747fa343817 ("mt76: mt7915: drop zero-length packet to avoid Tx hang") Signed-off-by: Eason Lai Link: https://patch.msgid.link/20260703005945.2244533-1-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 27dbe86665dae8a9bde46581661129e9301ab0c1 Author: Jared.Huang Date: Wed Jun 17 15:13:20 2026 +0800 wifi: mt76: mt7925: fix msg len mismatch between driver and firmware [ Upstream commit 9ddb7487aa7cccb6e1880b4151ab5895109eb8d6 ] The mt7925_tx_power_limit_tlv struct begins with a 4-byte rsv[] field that acts as a UNI command header prefix. The firmware dispatcher did not use the 4-byte rsv[] and will only check the payloads after the 4-byte rsv[] As a result, the total message length minus the 4-byte prefix. Fix this by setting len to msg_len - 4. Fixes: ccb186326bb6 ("wifi: mt76: mt7925: fix incorrect length field in txpower command") Signed-off-by: Jared.Huang Link: https://patch.msgid.link/20260617071320.1808499-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5cfd3d6078d9148ecee71c7b761fb1aeb24ff7d9 Author: Jared.Huang Date: Wed Jun 17 15:13:05 2026 +0800 wifi: mt76: mt7925: update clc before setting sar power table [ Upstream commit 8a27c5c764040fbc990cc416a927b1d7eadf559f ] Fix the power table update sequence to ensure CLC is loaded before setting SAR power table. The firmware requires CLC baseline to be established first to properly calculate the final power limit as min(clc_limit, rate_limit,sar_limit). Fixes: 9557b6fe0c8b ("wifi: mt76: mt7925: refine the txpower initialization flow") Signed-off-by: Jared.Huang Link: https://patch.msgid.link/20260617071305.1808394-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7b7060e262731fe943ea5d79aece6d729039de69 Author: Sean Wang Date: Sat Jun 13 17:51:43 2026 -0500 wifi: mt76: mt7927: set band index for sniffer mode [ Upstream commit c410102bbff0803c9dc44056b917aff90abcbaec ] Use the active channel context to select the SNIFFER command band index on MT7927, and fall back to the PHY chandef when no channel context is available. Also pass the same band index to the sniffer channel configuration. This keeps monitor setup on the correct band, especially when multiple PHY band contexts are present. Fixes: 35a5dcc71735 ("wifi: mt76: mt7925: add MT7927 PCIe support") Signed-off-by: Sean Wang Tested-by: Devin Wittmayer Link: https://patch.msgid.link/20260613225144.2414283-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f544bcba4721e1074e9bc6666f0ef4f8b96ddba8 Author: Eason Lai Date: Wed May 6 15:04:58 2026 +0800 wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash [ Upstream commit 915672c5ae32deeb72f4572856d123f314791136 ] When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[]. Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)] mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)] process_one_work+0x188/0x514 worker_thread+0x12c/0x300 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses. Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled. Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets") Co-developed-by: Sean Wang Signed-off-by: Sean Wang Co-developed-by: Jeff Hsu Signed-off-by: Jeff Hsu Signed-off-by: Eason Lai Co-developed-by: Michael Lo Link: https://patch.msgid.link/20260506070458.3096180-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b250943f3f8351385a17972bda001664a5c51008 Author: Eason Lai Date: Wed Jul 1 09:06:54 2026 +0800 wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete [ Upstream commit 217f9e7bb02558759be9d9ecfe532e9708741c50 ] A use-after-free issue occurs in mt76_rx_poll_complete due to a race condition. The STA has already been removed, but the rx_status still had a pointer to the wcid in the STA. Set the links' wcid pointers to be NULL for a MLD in mt7925_sta_pre_rcu_remove() BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470 Call trace: dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc8 print_report+0x1b8/0x710 kasan_report+0xe0/0x144 do_bad_area+0x120/0x260 do_tag_check_fault+0x20/0x34 do_mem_abort+0x54/0xa8 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x40/0xcc el1h_64_sync+0x7c/0x80 mt76_rx_poll_complete+0x280/0x470 mt76_dma_rx_poll+0x114/0x51c mt792x_poll_rx+0x60/0xf8 napi_threaded_poll_loop+0xe0/0x450 napi_threaded_poll+0x80/0x9c kthread+0x11c/0x158 ret_from_fork+0x10/0x20 Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Eason Lai Link: https://patch.msgid.link/20260701010654.956863-1-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0c46d22c30a168e11d91b6a7856d627408a3a87e Author: Sean Wang Date: Wed Jun 24 19:18:31 2026 -0500 wifi: mt76: add init_wiphy callback [ Upstream commit 4ee3d2a5f2cd5b6d0ba0d997913c1b763ef4d5c5 ] Add an optional callback for drivers to finalize wiphy state after mt76 has initialized the supported bands and before registration. Co-developed-by: Stella Liu Signed-off-by: Stella Liu Co-developed-by: Jeremy Yu Signed-off-by: Jeremy Yu Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260625001834.475094-7-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 217f9e7bb025 ("wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete") Signed-off-by: Sasha Levin commit 2691bf35cee6ecd450d91ed778afd1efb14da1d3 Author: Sean Wang Date: Wed Jun 24 19:18:29 2026 -0500 wifi: mt76: mt7925: add NAN MCU helpers [ Upstream commit a5487a6824068cba6fab02f3e5186940a59275ed ] Add the mt7925 NAN MCU ABI and helpers for enable, disable, configuration updates, availability updates and peer schedule commands. Upper-layer integration is added by later patches. Co-developed-by: Stella Liu Signed-off-by: Stella Liu Co-developed-by: Jeremy Yu Signed-off-by: Jeremy Yu Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260625001834.475094-5-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 217f9e7bb025 ("wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete") Signed-off-by: Sasha Levin commit 2ca99492a7bf7bda61ed539170258bf64b9629bd Author: Sean Wang Date: Wed Jun 24 19:18:28 2026 -0500 wifi: mt76: connac: add NAN connection type [ Upstream commit b7ab9f780dc8f6cc9ce30333e9f131ed3419c6b3 ] Introduce a dedicated NAN connection type for connac firmware and use it for NAN interface device, BSS and station records. Add the common NAN MCU command and event IDs used by mt7925. Co-developed-by: Stella Liu Signed-off-by: Stella Liu Co-developed-by: Jeremy Yu Signed-off-by: Jeremy Yu Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260625001834.475094-4-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 217f9e7bb025 ("wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete") Signed-off-by: Sasha Levin commit d4029aab5be84288006e60b2bab1838c545ea7cb Author: Zhi-Jun You Date: Wed Jul 15 23:21:13 2026 +0800 wifi: mt76: mt7915: fix net_fill_forward_path for non-DBDC mt7986 [ Upstream commit bade0d238b60c29dafcc7da17501fa489495d6ae ] Current implementation assumes that the hardware supports DBDC or single band and binds to band0. This causes net_fill_forward_path to select the wrong queue for non-DBDC mt7986 because it binds to band1 and getting the following in dmesg: ieee80211 phy2: WA: --> drop by reaseon:1, msdu id = 0xc002 but failed! mtk_wed1: error status=00000002 ieee80211 phy2: WA: txblk 10324e00 len = 128 DW0 : 10 00 00 00 DW1 : 00 00 00 00 DW2 : 00 00 00 00 DW3 : 72 0f 94 68 DW4 : 00 00 00 00 DW5 : ff 03 00 00 DW6 : 00 00 3c 40 DW7 : 00 17 dd 14 DW8 : 79 6f 00 00 DW9 : 02 c0 00 00 DW10 : 58 c5 34 10 DW11 : 00 00 00 00 DW12 : 00 06 3e 00 DW13 : 00 00 00 80 DW14 : 10 8c 00 00 DW15 : 00 00 00 00 DW16 : 00 00 00 00 DW17 : 00 00 00 00 DW18 : 00 00 00 00 DW19 : 00 00 00 00 DW20 : 00 00 00 00 DW21 : 00 00 00 00 DW22 : 00 00 00 00 DW23 : 00 00 00 00 DW24 : 00 00 00 00 DW25 : 00 00 00 00 DW26 : 00 00 00 00 DW27 : 00 00 00 00 DW28 : 00 00 00 00 DW29 : 00 00 00 00 DW30 : 00 00 00 00 DW31 : 00 00 00 00 Fix it by using phy->mt76->band_idx for queue which works for both non-DBDC and DBDC devices. Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support") Suggested-by: Benjamin Larsson Signed-off-by: Zhi-Jun You Link: https://patch.msgid.link/20260715152113.553-2-hujy652@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ef0190f1fafa73feffb7c53c99921f9537ca3b8c Author: Sean Wang Date: Sat Jun 13 17:41:28 2026 -0500 wifi: mt76: mt792x: stop USB register access after bus hang [ Upstream commit e137e5fd245cb6c0ae378607cc8090c913d984b2 ] Mark the mt792x USB bus hung on the first control timeout and switch register access to no-op bus ops. Each failed vendor request may spend up to MT_VEND_REQ_MAX_RETRY * MT_VEND_REQ_TOUT_MS, about 3 seconds, and teardown/reset paths can keep issuing such requests after the device has stopped responding. Also skip the USB WFSYS reset path after bus_hung is set, since it uses UHW vendor requests as well. mt7925u 1-2:1.3: vendor request req:63 off:0018 failed:-110 mt7925u 1-2:1.3: vendor request req:63 off:0018 failed:-110 mt7925u 1-2:1.3: vendor request req:63 off:0018 failed:-110 mt7925u 1-2:1.3: vendor request req:63 off:0018 failed:-110 mt7925u 1-2:1.3: vendor request req:63 off:0018 failed:-110 Avoid repeating those register reads after the bus is known to be hung by switching register access to no-op handlers. Fixes: 0d2afe09fad5 ("mt76: mt7921: add mt7921u driver") Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260613224131.2396026-4-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 063169a2755abdcbe7698d98360336abb6bef414 Author: Shayne Chen Date: Mon Jul 20 17:01:02 2026 +0800 wifi: mt76: fix handling channel context with different bands in mt76_switch_vif_chanctx() [ Upstream commit 70869cc429fffc77de51e7777c0ecb651e8fca07 ] When performing channel switches on different radios within a short timeframe, channel contexts with different bands can be carried for each struct ieee80211_vif_chanctx_switch. Rework mt76_switch_vif_chanctx() to properly handle this scenario. Fixes: 82334623af0c ("wifi: mt76: add chanctx functions for multi-channel phy support") Co-developed-by: Rex Lu Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260720090102.190729-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6def491fe9c4e83aa8cba62d74e9d4ab751ee967 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 2e3549a038f100d602bb8520f42d8f9b9e427989 Author: Dmitry Gomzyakov Date: Sun May 10 15:29:10 2026 +0500 wifi: mt76: connac: add MT7991A (0x7991) to is_mt7996() [ Upstream commit 574bd79955d166c00c2b1531fed591ee70b6ba04 ] The MT7991A chipset uses PCI device ID 0x7991 (MT7996_DEVICE_ID_2), but is_mt7996() only checks for 0x7990. This causes MT7991A devices to use incorrect chip-specific settings, such as: - MSDU_CNT_V2 instead of MSDU_CNT in TX descriptors - Wrong WTBL BMC size (32 instead of 64) - Incorrect prefetch depth for MCU queues Fixes: 7014fe535860 ("wifi: mt76: mt7996: add macros for pci device ids") Signed-off-by: Dmitry Gomzyakov Link: https://patch.msgid.link/20260510102911.1883849-2-kyoto1337@protonmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3b052a39c46502ac72b28c13e6c4aa6ca981769c 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 ef81e4a1628ecfb9cfc442de10883f383faf17a1 Author: Muhammad Usama Anjum Date: Thu Jul 30 12:12:50 2026 +0100 misc: sgi-gru: remove interrupt-context page-table walks [ Upstream commit 928a8e9f523df845fc496bcb9811013b67aabec5 ] The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented. Fixes: 142586409c8b ("GRU Driver: page faults & exceptions") Signed-off-by: Muhammad Usama Anjum Link: https://patch.msgid.link/20260730111316.3672672-2-usama.anjum@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 961f4406a2dd36b7de14a984c477fdd8a595a26c 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 a1584c5f05cb60af9997ce93f25c5a55fd1fb0c5 Author: Jinjie Ruan Date: Wed Jul 29 09:29:46 2026 +0800 powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() [ Upstream commit 4cc4b586007fbbf8edba4f1d0849e9a06b0cf6c3 ] In get_crash_memory_ranges(), if crash_exclude_mem_range() failed after realloc_mem_ranges() has successfully allocated the cmem memory, it just returns an error but leaves cmem pointing to the allocated memory, nor is it freed in the caller update_crash_elfcorehdr(), which cause a memory leak, goto out to free the cmem. Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Sourabh Jain Signed-off-by: Jinjie Ruan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-2-ruanjinjie@huawei.com Signed-off-by: Sasha Levin commit 2996d2a7cb92cac3c9e5f1ff522dd896e2162ed5 Author: Rosen Penev Date: Sat May 16 23:37:54 2026 -0700 powerpc/44x: Set GPIO chip parent [ Upstream commit b9254d222d0b38cc6f7b73119fad6316f65278be ] The PPC4xx GPIO driver stopped assigning an explicit parent to the gpio_chip when it moved away from of_mm_gpiochip_add_data(). Restore that association from the platform device so OF GPIO lookup can match phandles to the registered gpiochip. Tested on: Cisco MX60W. No more probe deferral. Assisted-by: Codex:GPT-5.5 Fixes: 1044dbaf2a77 ("powerpc/44x: Change GPIO driver to a proper platform driver") Signed-off-by: Rosen Penev Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Linus Walleij Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260517063754.21819-1-rosenp@gmail.com Signed-off-by: Sasha Levin commit 4e8bfb2a3b27162bcff92e90b121980407a97486 Author: Christophe Leroy (CS GROUP) Date: Wed Jul 29 11:56:48 2026 +0200 powerpc: implement get_direction() in cpm2 [ Upstream commit ca16219e9babc874349a6ac307d56523871a9137 ] The lack of get_direction() callback in this driver causes GPIOLIB to emit a warning. Implement it. Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Signed-off-by: Christophe Leroy (CS GROUP) Reviewed-by: Bartosz Golaszewski Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/c6eb70aa0e1ba6e15f947c827006aa79edace05c.1785318836.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit 193fe50a497d40cddf6ffab83049553d3da3e951 Author: Mukesh Kumar Chaurasiya (IBM) Date: Wed Jul 8 13:54:49 2026 +0530 dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled [ Upstream commit be809b60cbb61aab96179f44ac3670242ae72996 ] When building with LLVM=1 for architectures like powerpc where CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>> referenced by helpers.c >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) The issue occurs because: 1. CONFIG_DEBUG_MUTEXES=y is enabled 2. CONFIG_DMA_SHARED_BUFFER is not enabled 3. dma_resv_reset_max_fences() is declared in the header when CONFIG_DEBUG_MUTEXES is set 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, which is only built when CONFIG_DMA_SHARED_BUFFER is enabled 5. Rust helpers call dma_resv_unlock() which calls dma_resv_reset_max_fences(), causing an undefined symbol Fix this by compiling `dma-resv.c` file only when CONFIG_DMA_SHARED_BUFFER is enabled. Fixes: 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock") Reviewed-by: Christian König Reviewed-by: Gary Guo Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260708082454.1254320-3-mkchauras@gmail.com Signed-off-by: Sasha Levin commit 34470cc3a8e66751030d7b777dd18d9f2acb48e8 Author: Brian Foster Date: Wed Jul 29 12:27:16 2026 -0700 iomap: release the folio batch on iomap callback failures [ Upstream commit 31e3d833d522746a93d135e8b465d16f8ad33453 ] A sashiko review of an unrelated patch points out that the folio batch mechanism used for iomap zero range fails to release the batch in a couple error scenarios. If either calls to ->iomap_end() or ->iomap_begin() fail, the direct return paths bypass the batch cleanup. The ->iomap_end() case is not a practical issue at the moment because there is no user of the mechanism that returns an error from this path. The ->iomap_begin() case is theoretically possible because XFS can invoke the fill helper and error out at various points thereafter. This subtly complicates things because XFS does not transfer iomap_flags to the iomap data structure in the error path. To deal with both of these issues, first make sure to invoke the cleanup helper in the error path for either fs callback. Second, update the helper to clear the flag unconditionally and release the batch so long as it is populated. This more clearly delineates the purpose of the flag to control the I/O path and not necessarily the status of the fbatch, so add a comment around this as well. Reported-by: Sashiko Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing") Signed-off-by: Brian Foster Link: https://patch.msgid.link/20260729192737.3190206-2-joannelkoong@gmail.com Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 20e9cbd3be1e3f753e81960eb4cc6c80b8520ee9 Author: Karl Mehltretter Date: Wed Jul 29 02:59:33 2026 +0200 dcache: keep shrink_dcache_for_umount() making progress on busy roots [ Upstream commit 78db93943210df61c8446aae35af6836e2cf04aa ] Commit e9895609cb7f ("wind ->s_roots via ->d_sib instead of ->d_hash") moved secondary roots from ->d_hash to ->d_sib. Secondary roots are now d_unhashed(), so __d_drop() returns without removing them from ->s_roots. Consequently, d_drop() in do_one_tree() no longer guarantees progress through the list. If a secondary root is still busy once do_one_tree() is done with it, its final dput() cannot evict it. The root remains ->s_roots.first and the loop selects it forever, holding ->s_umount for write and repeatedly reporting the same dentry. The root does not need a leaked reference of its own for that. Every child pins its parent (d_alloc() takes a reference on it) and umount_check() deliberately reports a busy descendant instead of complaining about its ancestors, so a single leaked dentry reference anywhere below a secondary root is enough. For filesystems that build ->s_root with d_obtain_root() - nfs, ceph, nilfs2 snapshot mounts - that is the entire tree. Before e9895609cb7f, ___d_drop() special-cased IS_ROOT dentries and removed them from ->s_roots regardless of their refcount, so the d_drop() in do_one_tree() detached the root from the superblock no matter what. Commit 9c8c10e262e0 ("more graceful recovery in umount_collect()") deliberately made busy dentries nonfatal: report them and finish the unmount rather than BUG() while holding ->s_umount. Restore that by detaching the root in do_one_tree() itself, next to the d_drop() that used to do it. That covers both callers - the ->s_roots loop and ->s_root, which for the filesystems above is a secondary root as well. In the normal case dentry_unlist() finds ->d_sib already unhashed when eviction occurs. A permanently leaked reference remains leaked after unmount, as it did before e9895609cb7f; if the extra reference is merely delayed, its final dput() may run after teardown has advanced. Leaving the root on ->s_roots is not an alternative: the superblock would then be freed with a live dentry still linked into it, and that dentry's dentry_unlist() would take ->s_roots_lock on freed memory. Christian Brauner says: Moved the ->s_roots removal from the shrink_dcache_for_umount() loop into do_one_tree(), so a busy ->s_root obtained from d_obtain_root() is detached on the first pass instead of being reported a second time when the loop picks it off ->s_roots. Extended the commit message with the pinned-ancestor case. Fixes: e9895609cb7f ("wind ->s_roots via ->d_sib instead of ->d_hash") Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260729005933.15858-1-kmehltretter@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9be10f49dfc2e4b472b3a5f346483b67374774b8 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 1e202ab73001435e49353e35f956257a3032cb0c Author: Komal Bajaj Date: Tue Jul 28 16:33:08 2026 +0530 pinctrl: qcom: shikra: Fix intr_target_width for summary interrupt routing [ Upstream commit 1e7b04c12c077e8829991833a9aa2cb3bdacab61 ] The intr_target_width field sets the mask width used when writing target processor into interrupt config register and deciding which processor receives summary interrupt for a given GPIO. Without it, pinctrl driver defaults to a 3-bit mask. On Shikra, this field is 4 bits wide, which could corrupt adjacent bits and mis-route interrupts. Set intr_target_width = 4 to match the hardware. Fixes: 9db68ec534c5 ("pinctrl: qcom: Add Shikra pinctrl driver") Signed-off-by: Komal Bajaj Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260728-shikra-pinctrl-intr-width-v1-1-46583734d808@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c02d675e81468003e4f2253b616c53729070d712 Author: Martin Wilck Date: Thu Jul 23 13:27:41 2026 +0200 md/raid1: create serial pool adding rdev to array with serialize_policy=1 [ Upstream commit 140234b2380ffb8ffb0cfc46fee0e822f43adef7 ] The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it. Fixes: 69b00b5bb235 ("md: introduce a new struct for IO serialization") Signed-off-by: Martin Wilck Reviewed-by: Mykola Marzhan Link: https://patch.msgid.link/20260723112741.1206836-1-mwilck@suse.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 1f42e5898b45a88701d9d5164252307154d972b9 Author: Yu Peng Date: Wed Jul 8 16:02:32 2026 +0800 fs: annotate inode timestamp accessors [ Upstream commit c610d2d0787961cdd6fc1de69d9be1ff3687e1a6 ] syzbot reported a KCSAN race between fill_mg_cmtime() and inode_set_ctime_to_ts() on inode->i_ctime_{sec,nsec}. stat/getattr can sample inode timestamps while update paths store new values concurrently, so KCSAN can report benign races on these fields. Annotate the timestamp accessors with READ_ONCE()/WRITE_ONCE(), and use the ctime accessor for the remaining ctime loads. This avoids the KCSAN reports without changing timestamp semantics. Fixes: 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps") Reported-by: syzbot+8b3bd9f8a06658479d4a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8b3bd9f8a06658479d4a Signed-off-by: Yu Peng Link: https://patch.msgid.link/20260708080232.2564807-1-pengyu@kylinos.cn Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit dff41b56ab7b7686e079728617e3752a44b030df Author: Can Peng Date: Wed Jul 15 09:29:49 2026 +0800 i3c: master: adi: add OF module alias for autoloading [ Upstream commit a733069a1943f30922b90bde5eef3cb25b010f8b ] The Analog Devices I3C master driver can be built as a module and uses adi_i3c_master_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: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Signed-off-by: Can Peng Reviewed-by: Frank Li Link: https://patch.msgid.link/20260715012949.180245-1-pengcan@kylinos.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 618dd640ded6b94bbdb79c798a901ec564797033 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 c1f4d7763cdf1b9e0d35c14aa6f52d0512a36319 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:23 2026 +0530 swiotlb: Preserve allocation virtual address for dynamic pools [ Upstream commit 57d29044d0f29a76c6ec0c112c8c7371d5608dc7 ] swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator. Fixes: 79636caad361 ("swiotlb: if swiotlb is full, fall back to a transient memory pool") Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-6-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 8c486293ddd0af60991408149fc3e964ea888dc4 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 a58923756b0f8e71032070c23ae0b167e46731da Author: Chen Cheng Date: Sat Jul 18 16:42:18 2026 +0800 md: scope memalloc_noio to allocation critical sections [ Upstream commit bace2010dd7ac07bc980575afb135c406730a7fe ] Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write. Link: https://github.com/chencheng-fnnas/reproducer/blob/main/repro-md-noio-token-leak.sh Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260718084218.417895-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit cc543e769b97d563b089b9e0ebf8ad361d15076f Author: Chen Cheng Date: Sat Jul 18 11:42:36 2026 +0800 md/bitmap: resume array on backlog_store() error path [ Upstream commit 2911cd0a0f4366a7e06832bc5f0a7fdcc138e4dc ] backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states. Fixes: 58226942ad3d ("md: use new apis to suspend array before mddev_create/destroy_serial_pool") Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260718034236.4119093-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit af409d56bb38cb17a66be144723046daf8350d15 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 e13c99679b5488010655afb4ef992efc779c70aa Author: Imran Shaik Date: Sat Jul 18 18:26:18 2026 +0530 clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disable [ Upstream commit ab46b5fb668b8b9b848a8f036fc4c06ce86b7e3b ] The RCG's clk src has to be parked at XO while disabling as per hardware team's recommendation, hence use clk_rcg2_shared_ops to achieve the same. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-11-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bb105eb8cce8540df611aef0dc63454a7d5fd5c1 Author: Imran Shaik Date: Sat Jul 18 18:26:17 2026 +0530 clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probe [ Upstream commit 7274ea68d2b4be491de0ece45fdce709cfde3154 ] Drop modelling of gpu_cc_ahb_clk and keep it always enabled from probe similar to other critical clocks, since marking it as CLK_IS_CRITICAL causes the clock framework to invoke clk_pm_runtime_get() during prepare, which prevents the associated power domains from collapsing. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-10-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 679df05c771aea5c09fe7134f94d8387d4142a16 Author: Imran Shaik Date: Sat Jul 18 18:26:16 2026 +0530 clk: qcom: gpucc-qcm2290: Move to the latest common qcom_cc_probe() model [ Upstream commit 1b4599bc20e98d61c274b3449ca392b8e2b07b4a ] Update the QCM2290 GPUCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-9-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 7274ea68d2b4 ("clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probe") Signed-off-by: Sasha Levin commit 73d816a47fcc021809610472f0e29cae2286e1d5 Author: Imran Shaik Date: Sat Jul 18 18:26:15 2026 +0530 clk: qcom: gpucc-qcm2290: Drop pm_clk handling [ Upstream commit 1b2e1f5a37dd4c856a9269bc7e5988c642db5847 ] Drop the pm_clk handling from QCM2290 GPUCC driver as the required GCC AHB clocks are kept always enabled by the GCC driver during probe. Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-8-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 7274ea68d2b4 ("clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probe") Signed-off-by: Sasha Levin commit 308f3349e2fd658ab4608a542f6f0fc1f5d3dc63 Author: Imran Shaik Date: Sat Jul 18 18:26:14 2026 +0530 clk: qcom: qcm2290: Update DISPCC and GPUCC GDSC *wait_val values [ Upstream commit 08cfbfd81dd6e27167b1331e0c485bd0414cf5fe ] Update the QCM2290 DISPCC and GPUCC GDSC wait_val fields to match the hardware default values. Incorrect settings can cause the GDSC FSM to stuck, leading to power on/off failures. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-7-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 844e78f83227926d33d6529b7ed090ca2bdffe2a Author: Imran Shaik Date: Sat Jul 18 18:26:13 2026 +0530 clk: qcom: qcm2290: Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs [ Upstream commit 899dfd90229e3d83aa85a27b3d5d1d78bdb7385d ] Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs on QCM2290 to retain the register context across GDSC power collapse. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-6-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dfc8dea60be27b2fddb55cc4d35f769b489c0baa Author: Imran Shaik Date: Sat Jul 18 18:26:12 2026 +0530 clk: qcom: qcm2290: Set POLL_CFG_GDSCR flag for DISPCC and GPUCC GDSCs [ Upstream commit 6b0044bc75b04374c58d082d4cd59f57db83e8dc ] The Qualcomm QCM2290 SoC GDSCR status bit may not reflect the actual state of the GDSC, instead the power on/off bits in CFG_GDSCR must be polled to determine the GDSC state correctly. Set POLL_CFG_GDSCR flag for the QCM2290 MDSS GDSC and GPUCC GX GDSC to ensure the correct GDSC status. This is not applicable for GPUCC CX GDSC, which relies on gds_hw_ctrl status. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-5-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8b516ca0d040c059cd14d2769c980e7ae4f46009 Author: Imran Shaik Date: Sat Jul 18 18:26:11 2026 +0530 clk: qcom: dispcc-qcm2290: Enable runtime PM support [ Upstream commit 11345cbf17cacc3828f7bcb021ecc07c687d04f2 ] The QCM2290 DISPCC is now associated with a power domain (RPMPD_CX) to propagate genpd performance state votes to the CX rail. Set use_rpm to true so that a runtime PM reference is acquired and released around probe, instead of leaving a permanent 'enable' vote on the power domain. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Signed-off-by: Imran Shaik Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-4-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a0e5c01eb1df8f264f22df687e87f5692e26bee9 Author: Imran Shaik Date: Sat Jul 18 18:26:10 2026 +0530 clk: qcom: dispcc-qcm2290: Move to the latest common qcom_cc_probe() model [ Upstream commit b8b5b26aa10e57c154ceb7d32d573afb864823aa ] Update the QCM2290 DISPCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-3-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 11345cbf17ca ("clk: qcom: dispcc-qcm2290: Enable runtime PM support") Signed-off-by: Sasha Levin commit 8bc5a909a6110ecc9afdd9e2f6b7b78e608e7ae0 Author: Taniya Das Date: Fri Jul 24 16:25:06 2026 +0530 clk: qcom: negcc-nord: keep GPU2 CFG clock enabled via critical CBCR [ Upstream commit 936e98ef12f714c19150a5595bbd296d9489b2e1 ] The GPU2 CFG clock must remain enabled for correct operation and should not be exposed as a controllable clk_branch. Remove the clk_branch and mark its CBCR as critical instead to prevent unintended gating. This follows the same approach as 'nw_gcc_gpu_cfg_ahb_clk' and aligns with other always-on clocks in Qualcomm CC drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio Reviewed-by: Alexandre Mergnat Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-2-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b88c019e2cca98cbf741a63b8c3176051ed6caf0 Author: Taniya Das Date: Fri Jul 24 16:25:05 2026 +0530 clk: qcom: gcc-nord: mark PCIe link clocks as critical [ Upstream commit 6c3a4d971503b04b00d75a37882becb3c2f57f30 ] The PCIe link AHB and XO clocks must remain enabled for proper operation. Representing them as clk_branch instances allows them to be gated, which is undesirable. Remove their clk_branch definitions and register their CBCRs as critical clocks instead so they remain enabled. This matches the handling of similar always-on clocks in other Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio Reviewed-by: Alexandre Mergnat Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-1-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9726f63fb92554315994d86732ffb8c35bd538b5 Author: Taniya Das Date: Thu Jul 16 16:29:12 2026 +0530 clk: qcom: negcc-nord: use clk_regmap_phy_mux for USB3 pipe clock srcs [ Upstream commit a5c2859ffe9c8e033e2df1ef62357fa5692008f1 ] ne_gcc_usb3_prim_phy_pipe_clk_src and ne_gcc_usb3_sec_phy_pipe_clk_src are 2-bit muxes selecting between a PHY-sourced USB3 pipe clock and BI_TCXO, implemented with clk_regmap_mux_closest_ops. This requires manual parent switching and does not park the mux on the reference clock when the clock is disabled. Convert both to clk_regmap_phy_mux with clk_regmap_phy_mux_ops, which automatically parks the mux on the XO/ref source on disable and restores the PHY parent on enable, matching the existing UFS symbol clock conversions in this driver. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das Tested-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-2-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c3683217826d70c8c0568729eb8dd72c86b5e712 Author: Taniya Das Date: Thu Jul 16 16:29:11 2026 +0530 clk: qcom: nord: use BRANCH_HALT_SKIP for PHY pipe clocks [ Upstream commit 3a8a7d597b07ffe388b47fb524827be52c9f7e0f ] The PCIe and USB3 pipe clocks on Nord are sourced from their respective PHYs. The halt bit for these branches does not toggle reliably when the PHY is powered down or not yet brought up, so polling for it with BRANCH_HALT_VOTED can spuriously time out. Switch these pipe clock branches to BRANCH_HALT_SKIP, matching the convention used for PHY-sourced pipe clocks elsewhere in the Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das Tested-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-1-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 948183bb89dc053a4bd3506544e84872b089545f Author: Abel Vesa Date: Wed Jul 22 12:40:53 2026 +0300 arm64: dts: qcom: eliza: Add fallback compatible for ADSP remoteproc [ Upstream commit b589944ecd95fe4a51bc2aab13ce83b298b7bcc8 ] The ADSP found on Eliza SoC is actually fully compatible with the ones from SM8750 class. So add the SM8550 compatible as fallback, just like the rest from the SM8750 class SoCs. Fixes: 88ddafb01ec0 ("arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-2-e1e98ae15533@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a2074f86fc9653831e4fb7b711bb715db330f182 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 65e7240d679fe73297666718d9926dbc8508d44a Author: Alexis Savery Date: Thu Jul 30 13:42:40 2026 -0700 platform/chrome: lightbar: Limit payload to max packet size [ Upstream commit ed1d1f519c56c6c2ffa13f3d52cd77beb023db13 ] The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its payload length, but the protocol-negotiated `max_request` may exceed the maximum value an 8-bit integer can represent. When this occurs, large payloads (e.g., >255 bytes) integer wrap the 8-bit size variable when assigning `param->set_program_ex.size`, causing truncation and parse failures downstream in the EC firmware stack. Clamp `max_size` to the maximum value the structural size field can support. Fixes: 9600b8bdbfe4 ("platform/chrome: lightbar: Add support for large sequence") Signed-off-by: Alexis Savery Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 79347e42cfbc9e78872922e8f08a70609c9af82f Author: Pu Lehui Date: Tue Jul 28 02:54:57 2026 +0000 bpf: Fix potential UAF when reading bpf link info [ Upstream commit 863f3ddd0b8ac65abfb50d3be0869268ac0e277b ] In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Reviewed-by: Amery Hung Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728025457.2814876-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 923f559e95b89b33c7e1793b3d8f7f4ec9b2e4b7 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 aab9d81a415c6653b44b057695ebfbba34dc9556 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 ad4f4e6678ecd4f6de97b73d4bab7d2352d40d70 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 3646c881b6adbb07851926b3f6152041b73ece4a Author: Manivannan Sadhasivam Date: Thu Jul 30 13:56:03 2026 +0200 arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Fix the PCIe iommu-map entries [ Upstream commit 770d1448435bca2b1cd00854dc9401320b584d5b ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 4559b435f741 ("arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add TC9563 PCIe switch node for PCIe0") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-22-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 65fded30a4479b456a0c0a517a1740114a11e252 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:56:02 2026 +0200 arm64: dts: qcom: qcs6490-rb3gen2: Fix the PCIe iommu-map entries [ Upstream commit 485dc5e557a8fef1374669f4ebe027c947187325 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 267643b3e3a4 ("arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-21-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d6c3c9c6cc382e0eef1ebba5c4e9af6c6fada92f Author: Manivannan Sadhasivam Date: Thu Jul 30 13:56:01 2026 +0200 arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: Fix the PCIe iommu-map entries [ Upstream commit fc3c550b3847636f6c0732dc6c94e879ab5ff578 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 1cde54c54b83 ("arm64: dts: qcom: qcs6490: Add Thundercomm AI Mini PC G1 IoT") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-20-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit efcf504642bae1374871ed87c9831023a03d749f Author: Manivannan Sadhasivam Date: Thu Jul 30 13:56:00 2026 +0200 arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Fix the PCIe iommu-map entries [ Upstream commit 82a10eb6aeab412abd83a57cc3a605213d1dc1d5 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: ef254b12ec60 ("arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-19-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a1e2a5239cfc50a24104483faedf36cbaa8aa655 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:59 2026 +0200 arm64: dts: qcom: lemans-evk-ifp-mezzanine: Fix the PCIe iommu-map entries [ Upstream commit 6ee8ab6ca91dcea05793809df8a1dcfa94bcf3f0 ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: b64abb26a291 ("arm64: dts: qcom: lemans-evk: Add IFP Mezzanine") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-18-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e57c32625d30d12cc2a393ab3512ab8c743855dd Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:58 2026 +0200 arm64: dts: qcom: monaco-evk-ifp-mezzanine: Fix the PCIe iommu-map entries [ Upstream commit b35b58535b45441a4521d50215b5668731857c7d ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5a67924d2fc5 ("arm64: dts: qcom: monaco-evk: Add IFP Mezzanine") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-17-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d0da19edc7bafcd4c0af00ef413c01ab023b371b Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:57 2026 +0200 arm64: dts: qcom: monaco-monza-som: Fix the PCIe iommu-map entries [ Upstream commit d7ae79013e6c9b2374948d70856045cc84c9261d ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5238f4e7169f ("arm64: dts: qcom: Add Monaco Monza SoM") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-16-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5ac48b3956ca925d22c317f89f13383a7025c495 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:56 2026 +0200 arm64: dts: qcom: monaco: Fix the PCIe iommu-map entries [ Upstream commit 2e455d9278550c8886a94e30a906437a26c79581 ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-15-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3047cfd5ebdce25272484bddfa36484f07ff1445 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:55 2026 +0200 arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries [ Upstream commit 19b4c47fc9733a953e9586bc0906a3be378b4cd5 ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-14-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eb16dcbce98bc325c4390259cc5987377554e9c5 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:54 2026 +0200 arm64: dts: qcom: talos: Fix the PCIe iommu-map entries [ Upstream commit f7e687d6050f27a03847abadc12d6821576d06ee ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 718cc7542a00 ("arm64: dts: qcom: qcs615: enable pcie") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-13-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 604e55211af9b2b57effea1bcc08abf7ebdcbcb8 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:53 2026 +0200 arm64: dts: qcom: sm8750: Fix the PCIe iommu-map entries [ Upstream commit 366a540432a38c1c1533a319bc07b333f53752b6 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 19f1395333f8 ("arm64: dts: qcom: sm8750: Add PCIe PHY and controller node") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-12-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ff9c3c087b67aac8db6c3c944318c27f0521f873 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:52 2026 +0200 arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entries [ Upstream commit 8ccba7b44609d58db088447a771f6f30cfa8739e ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-11-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9eb128da8525a69575b38c87f47e04e2bc411df7 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:51 2026 +0200 arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries [ Upstream commit 16d98ee918d63018eaa6cc260791b71319aa4faa ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-10-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0ce01e1cd0c3b3bbe02c17902fe043ac49a694f0 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:50 2026 +0200 arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries [ Upstream commit 9b10e56647fa8f7ab62c7e45ebf4b168f7befa7f ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7b09b1b47335 ("arm64: dts: qcom: sm8450: add PCIe0 RC device") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-9-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d6e5c05018beaaf2865524278186c8709f3e696 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:49 2026 +0200 arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries [ Upstream commit 80337ea3a154230621c0b4e3c831f5d81712ba18 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 6daee40678a0 ("arm64: dts: qcom: sm8350: add PCIe devices") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-8-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8c8b4f2a352c1dd3f14a9cb4c6960d97e7c1f40d Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:48 2026 +0200 arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries [ Upstream commit c41749e9554d4e03e7074f5d1e46140bc4ac77bd ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-7-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dcdb31fb3e9784c6dd5c7a0bcdd7d5220e952712 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:47 2026 +0200 arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries [ Upstream commit d2e56fb42e3d10d7e711063cdc00523ddb31d544 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-6-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 22a6fcd328ab18807a67741ac55781686cfcd9d4 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:46 2026 +0200 arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries [ Upstream commit deaea7e982bc353c8d3c406774970f16ed901adb ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5c538e09cb19 ("arm64: dts: qcom: sdm845: Add first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-5-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 04ae73e1f607a4af5ea1f4fe475b359bcc48a9b6 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:45 2026 +0200 arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entries [ Upstream commit a4548204821a56c23cd711cfad2a637ca055ff47 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-4-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bf3f0faa4514405ce927d4afb0f9cbecf77717ce Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:44 2026 +0200 arm64: dts: qcom: sar2130p: Fix the PCIe iommu-map entries [ Upstream commit f605087abc70ecac53757a7ae0d2d8068342ec4b ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: be9115bfe5bf ("arm64: dts: qcom: sar2130p: add support for SAR2130P") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-3-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5f6cc86e9d609d9936e24910c11b28d718c6d105 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:43 2026 +0200 arm64: dts: qcom: kodiak: Fix the PCIe iommu-map entries [ Upstream commit 52dac5bda29a3acd896fab2567605683d34970db ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: f8328b7549e1 ("arm64: dts: qcom: sc7280: Describe the first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-2-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 36fb7eea71218ddcb74b60790eccb64bd4438d6e Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:42 2026 +0200 arm64: dts: qcom: kaanapali: Fix the PCIe iommu-map entries [ Upstream commit 35eda0e5f87d52ed9f015f8a44155e8ab2ad9c5a ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-1-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d0e427b1bbbad63f3121e505c856a897313169b Author: Dawid Wróbel Date: Thu Jul 30 15:44:07 2026 +0200 arm64: dts: qcom: sm8250-xiaomi-elish: correct the board ID [ Upstream commit 299731d4fbeaaa141ce2e8226ca00cb30d6ab647 ] elish declares the same qcom,msm-id and qcom,board-id pair as sm8250-sony-xperia-edo.dtsi, so a bootloader choosing between appended device trees cannot tell the two boards apart. 0x10008 is Sony's value. The downstream device tree for this board, elish-sm8250-overlay.dts, uses qcom,board-id = <47 0>, i.e. platform type 0x2f. Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Dawid Wróbel Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-elish-board-id-v1-1-92f99e9722ec@dawidwrobel.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 58d595f2d695ce6b43c547e0e26719a218296e9b Author: Imran Shaik Date: Thu Jul 30 15:45:10 2026 +0530 arm64: dts: qcom: talos: Fix cpu6 1094.4MHz OPP frequency typo [ Upstream commit f2eb18c66b98fbfcbab4daef42c04f4becba7d79 ] opp-1094400000 in cpu6_opp_table has a typo in opp-hz, missing a trailing zero. Fix it to resolve the following OPP update failures: cpu cpu6: Voltage update failed freq=1094400 cpu cpu6: failed to update OPP for freq=1094400 Fixes: 44562f591890 ("arm64: dts: qcom: qcs615: Add OSM l3 interconnect provider node and CPU OPP tables to scale DDR/L3") Signed-off-by: Imran Shaik Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260730-talos-cpu6-opp-fix-v1-1-f4886fdff13f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 030376932ffd9f4c7741548b2cffac207268f41e Author: Konrad Dybcio Date: Wed Jul 29 16:08:32 2026 +0200 arm64: dts: qcom: glymur: Fix PDC IRQ mapping [ Upstream commit 1b0b6ddd0299efa29d18f68a2d7152ad67cb9576 ] Some of the sub-ranges are inconsistent with HW docs. Fix them. They are valid for both Glymur and Mahua. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Gopikrishna Garmidi Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260729-topic-glymur_pdc-v1-1-8747789e35aa@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cbbaf0c870dde06cf4b887a77a94e3094179ca9f Author: Keith Busch Date: Mon Jul 20 13:10:54 2026 -0700 block: fix dio leak on metadata mapping error [ Upstream commit 702a2a9f3dfe066a7481698c858371112f3cb697 ] A failed integrity mapping holds a dio reference, so we need to go through the full bio ending in case there were previously submitted bio's in the sequence. Fixes: 2729a60bbfb92 ("block: don't silently ignore metadata for sync read/write") Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Link: https://patch.msgid.link/20260720201057.1862857-3-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6809ba75b8bb54e5f86c8a33577c8753d6ce818f Author: Mukesh Ojha Date: Fri Jul 24 15:19:39 2026 +0530 firmware: qcom: scm: Fix tzmem state on probe retry [ Upstream commit 9941fe8a04f3d258e07eb5899db3027252a4190f ] qcom_tzmem_enable() returns -EBUSY if called a second time, but this causes probe retries to fail permanently if a later step in qcom_scm_probe() defers after qcom_tzmem_enable() has already succeeded. Use DO_ONCE() to ensure qcom_tzmem_init() runs exactly once across all calls in a thread-safe manner. qcom_tzmem_dev is set on every call since probe retries use the same device pointer. The result of the first initialisation is cached and returned to every subsequent caller. Fixes: 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6fab857eccfc6d8eaf052863606040ec7633e56c Author: Mukesh Ojha Date: Fri Jul 24 15:19:38 2026 +0530 firmware: qcom: scm: Fix reserved memory cleanup on probe failure [ Upstream commit b697b20cea4374d27e2134da4bb7b0ea39f36c8b ] of_reserved_mem_device_init() adds an entry to a global list with no devres counterpart. If qcom_scm_probe() fails after the call the assignment is never cleaned up. A probe retry would add a duplicate entry, leaking the original one permanently. Add an err_rmem label that calls of_reserved_mem_device_release() and route all error paths after of_reserved_mem_device_init() through it. of_reserved_mem_device_release() is safe to call unconditionally as it simply walks an empty list when nothing was assigned. Fixes: a33b2579c8d3 ("firmware: qcom: scm: add support for SHM bridge memory carveout") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f312ef5026678f14caf1378c5f7fffdf667f9c81 Author: Mukesh Ojha Date: Fri Jul 24 15:19:37 2026 +0530 firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published [ Upstream commit 966d23c7e68ea32679275a7e3d2383181002c868 ] In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit edad2969959f1cd95bee16b55bfc6269d3e0822d Author: Yuvaraj Ranganathan Date: Fri May 22 12:09:00 2026 +0530 firmware: qcom: scm: instrument SMC call path with tracepoints [ Upstream commit 41329e72363c02facfeae063ef304aa7ced68c3b ] Wire the five tracepoints defined in qcom_scm_trace.h into the SMC execution path by including the header with CREATE_TRACE_POINTS. Reviewed-by: Konrad Dybcio Signed-off-by: Yuvaraj Ranganathan Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-2-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit 0e93bb22355efcfdf503dd827cfa992b58bf021d Author: Yuvaraj Ranganathan Date: Fri May 22 12:08:59 2026 +0530 firmware: qcom: scm: add trace events for the SMC call interface [ Upstream commit f6bb2daa4584229af155c2488b83151999315293 ] The SCM SMC call path is opaque at runtime. Stalls caused by firmware congestion, QCOM_SCM_WAITQ_SLEEP/RESUME cycles, and EBUSY retry loops are invisible without recompiling the kernel with temporary printk statements or attaching a hardware debugger. Add five TRACE_EVENTs covering the complete lifecycle of an SCM call: scm_smc_request Emit before each arm_smccc_smc_quirk() invocation. Records the SMC function ID, decoded service and command identifiers, argument count, and up to six register arguments in hex and decimal. Because the caller loops on QCOM_SCM_INTERRUPTED, this event fires once per physical SMC instruction including inte scm_smc_done Emit after the outer __scm_smc_do() returns, pairing each request with its final outcome. Records the SMC function ID, the kernel error code returned to the caller, and the four firmware result registers a0-a3. scm_waitq_sleep Emit when the firmware returns QCOM_SCM_WAITQ_SLEEP. Records the wait-queue context and the SMC call context handles required to issue the matching WAITQ_RESUME. scm_waitq_resume Emit just before constructing and sending the WAITQ_RESUME follow-up call. Records the SMC call context handle being resumed. scm_waitq_get_wq_ctx Emit after a successful WAITQ_GET_WQ_CTX fast-call. Records the returned wait-queue context, flags, and more_pending indicator. These events let ftrace and perf reconstruct the full sequence of firmware interactions, measure per-call and end-to-end latency, and attribute waitqueue stalls to specific service/command pairs without modifying driver source. Reviewed-by: Konrad Dybcio Signed-off-by: Yuvaraj Ranganathan Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-1-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit cb3219dcb859b38bcda7a2e760d2c6c1fca51ddd Author: Konrad Dybcio Date: Wed Jul 1 17:43:16 2026 +0200 arm64: dts: qcom: sc8280xp-crd: Fix the pin index for misc_3p3_reg_en [ Upstream commit 0e05c183f3b97427f00d619132ba5984494f6886 ] The correct pin is GPIO1. Fix it. Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260701-topic-8280crd_fixups-v1-2-3fe92ee9636b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a9e8aa66c5387c5ad7f83e40889fbb394709502f Author: Pradyot Kumar Nayak Date: Fri Jul 17 17:28:35 2026 +0530 arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support [ Upstream commit 67b5818ecadeb75e29c14add973b8cada2a73788 ] The touchscreen module on Glymur/Mahua CRDs is different from the one used on Hamoa CRDs and requires the reset-gpios to be wired to the device. Without this in place the reset line will remain permanently asserted during resume leaving the device offline and causing all I2C transactions to fail with -ENXIO. i2c_hid_of 3-0038: failed to change power setting. i2c_hid_of 3-0038: PM: dpm_run_callback(): i2c_hid_core_pm_resume [i2c_hid] returns -6 i2c_hid_of 3-0038: PM: failed to resume async: error -6 The touchscreen on Glymur/Mahua-CRD is a focaltech ft3d81, which is hardware-compatible with the ft8112. we have added the required change in DT. Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen") Fixes: f64ef325f1d9 ("arm64: dts: glymur-crd: Add reset GPIO to touchscreen node") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Pradyot Kumar Nayak Link: https://lore.kernel.org/r/20260717-add_focaltech_ft3d81_touchscreen_support-v4-2-5dd091e25801@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 759308ce67e93a2b82805059f3e4fce6aabea44a Author: Konrad Dybcio Date: Fri Jul 17 20:06:37 2026 +0200 soc: qcom: pmic_glink_altmode: Define the TBT extradata properly [ Upstream commit b255c6f4e6b48e09227cd68777a5d2ec1d36dc31 ] Before the fixes-referenced commit, there was a trailing 'u32 reserved' after the payload array. That commit gobbled it up into the thunderbolt extradata. Push it back where it belongs. There's no functional change, since the outer struct size remains identical - struct usbc_sc8280x_tbt_data and therefore the union it's a part of made up for the difference and the res bytes were ignored anyway. Fixes: 0539c5a6fdef ("soc: qcom: pmic_glink_altmode: Consume TBT3/USB4 mode notifications") Reported-by: Fenglin Wu Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-tbt_extradata_fixup-v1-1-5caa18f1c8d3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c9edf04712b5c4ccbf41b85692bb491693a55702 Author: Dmitry Baryshkov Date: Wed Jul 22 15:46:08 2026 +0300 clk: qcom: gcc-qcm2290: don't park QUP RCGs upon registration [ Upstream commit 9c4cee964e0ccc155e4ab8fa6cec88fffc262c63 ] The gcc_qupv3_wrap0_s[0-5]_clk_src RCGs feed the QUP serial engines (UART/I2C/SPI). Since shared RCGs are parked to XO at registration time, binding the gcc-qcm2290 driver reprograms these clocks away from the rate configured by the bootloader. For the UART used as the boot console this drops early console output until the serial driver later reconfigures the clock. Switch the QUP wrap0 clock sources over to clk_rcg2_shared_no_init_park_ops so their frequency is left unchanged at registration time, keeping the bootloader-configured console working across the gcc driver probe. Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260722-agatti-no-park-v1-1-31ae3a4774e5@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cf8a53ea2a805bcc15a5cf7e57dfd1d642330012 Author: Krishna Kurapati Date: Thu Jul 23 13:47:04 2026 +0530 arm64: dts: qcom: qcs404: Fix DTBS Check errors in usb controller nodes [ Upstream commit 9812d0a3077489f67afaca84dcc7e01a440ee106 ] The following errors pop up when DTBS check is done for qcs404 based platforms: arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml Modify ordering of hs_phy and qusb2_phy interrupts to fix the errors. Fixes: 927173bf8a0e ("arm64: dts: qcom: Add missing interrupts for qcs404/ipq5332") Signed-off-by: Krishna Kurapati Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260723-qcs404_dtbs_fix-v1-1-c9ca0dd69f23@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 099702ece0620a27d161aa18cfa0c3c18392b171 Author: Konrad Dybcio Date: Fri Jul 17 13:00:00 2026 +0200 arm64: dts: qcom: sdm632-motorola-ocean: Fix LED default trigger property [ Upstream commit c82ea31fb783d9ce4080eca1a7bb855f4648fc28 ] The correct property name is "linux,default-trigger", not "default-trigger". Fix it to avoid DT checker warnings and let the OSes consume the intended information. Fixes: 3176c4d6b9be ("arm64: dts: qcom: sdm632: Add device tree for Motorola G7 Power") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-3-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9f84fcd2869071795548d7a66e163bdb38e6939a Author: Konrad Dybcio Date: Fri Jul 17 12:59:59 2026 +0200 arm64: dts: qcom: msm8976-longcheer-l9360: Fix accidental node override [ Upstream commit bd0bb7d97773026c9f5d5f8ff1dcf987f8051045 ] The active and sleep pinctrl states for the touchscreen interrupt pin shared the same node name, creating a single node, accidentally overridden immediately after the definition. Alter the names to make them distinct and to silence DT checker warnings. Fixes: 79b896e7da7e ("arm64: dts: qcom: msm8976-longcheer-l9360: Add initial device tree") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-2-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 85fc83107415dcc602eec3812283798037294afc Author: Konrad Dybcio Date: Fri Jul 17 12:59:58 2026 +0200 arm64: dts: qcom: msm8998: Don't pull-up I2C pins by default in sleep [ Upstream commit 58ce9a2b9099bb26aed55d4e350c32af94930532 ] When the I2C controller is disabled, no communication is expected to take place. Without traffic on the bus, the pull-up is unnecessary. Both the vendor kernel for this platform and DTs of other SoCs in upstream concur this logic. Change the default and clean up now-NOP overrides. Fixes: 0fee55fc0de7 ("arm64: dts: qcom: msm8998: Add I2C pinctrl and fix BLSP2_I2C naming") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-1-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4c31039af7423bd335c087ee0254f085aab16c86 Author: Itai Handler Date: Thu Jul 23 10:41:38 2026 +0300 rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs [ Upstream commit 27d73e81195b395270117ff77c47be2ed9b09b12 ] rcu_all_qs() and rcu_note_context_switch() read/clear the per-CPU ->rcu_urgent_qs and ->rcu_need_heavy_qs flags with plain raw_cpu_read() and this_cpu_write(), while the RCU core clears them with WRITE_ONCE() in rcu_disable_urgency_upon_qs(). KCSAN flags the resulting same-CPU race: BUG: KCSAN: data-race in rcu_all_qs / rcu_disable_urgency_upon_qs It is benign -- the flags are advisory and rcu_all_qs() re-reads ->rcu_urgent_qs with smp_load_acquire() before acting on it -- but these are the last unmarked accesses to the two flags; every other access already uses READ_ONCE()/WRITE_ONCE()/smp_*. Mark them to match. No functional change. Reproduced on a PREEMPT_NONE, CONFIG_KCSAN_INTERRUPT_WATCHER=y kernel with a pthreads program whose threads (two per CPU) loop reading a large file: for (;;) { int fd = open("/proc/kallsyms", O_RDONLY); while (read(fd, buf, sizeof(buf)) > 0) ; close(fd); } The read()s drive cond_resched() -> rcu_all_qs() while the busy CPUs keep the grace period urgent, so the RCU core clears the flags concurrently. Fixes: 2dba13f0b6c2 ("rcu: Switch urgent quiescent-state requests to rcu_data structure") Signed-off-by: Itai Handler Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 0a3709557f8859c1ddc243f4783d148c381236d1 Author: Manivannan Sadhasivam Date: Wed Jul 29 10:22:27 2026 +0530 PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup() [ Upstream commit 36637958726a4bbc630c0848eb3eb07cbfae89c2 ] The MSI iATU mapping is currently only cleared when the endpoint is stopped via configfs or when the host updates the MSI address/size. This avoids redundant iATU reconfiguration every time the endpoint raises an MSI interrupt. However, a fundamental reset triggered by PERST# assert/deassert resets all iATU inbound/outbound registers without going through the configfs stop path. If the host also retains the same MSI address/size after PERST# deassert, the driver never clears the stale MSI iATU mapping. It then continues using this stale mapping to raise the MSI interrupts, which can cause IOMMU faults and MSI failures on the host. Fix this by clearing the MSI iATU mapping inside dw_pcie_ep_cleanup(), which is already called as part of the PERST# assert/deassert sequence. This unmaps the MSI iATU region and sets the msi_iatu_mapped flag to false, ensuring that dw_pcie_ep_raise_msi_irq() performs a fresh iATU mapping on its next invocation, regardless of whether the host changed the MSI address/size. Fixes: 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260729-pci-port-reset-v9-1-53570b92064d@oss.qualcomm.com Signed-off-by: Sasha Levin commit 379913074bf47768bdf805dd939da98fb726d2f7 Author: Abd-Alrhman Masalkhi Date: Fri Jul 10 10:15:17 2026 +0000 md/raid10: consistently fail atomic writes that require splitting [ Upstream commit 3409bf2f9678d769a4c33bd232a3571c51fac481 ] RAID10 currently handles one badblock path explicitly by failing atomic writes with EIO. However, another badblock path can also reduce the writable range and force the bio through bio_submit_split_bioset(), which implicitly completes the bio with EINVAL. Fix this by handling atomic writes in the common split check. If RAID10 determines that an atomic write would require splitting, complete the bio with EIO. Fixes: a1d9b4fd42d9 ("md/raid10: Atomic write support") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Reviewed-by: John Garry Link: https://patch.msgid.link/20260710101521.1714-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 110092e68836e53d3cd0d3297cda89d2e30859db Author: Abd-Alrhman Masalkhi Date: Fri Jul 10 10:15:16 2026 +0000 md/raid1: restrict atomic write limits and handle runtime constraints [ Upstream commit 86d801e895b853667a886918998e1628fcc3174e ] Restrict the RAID1 atomic write limits by setting chunk_sectors to BARRIER_UNIT_SECTOR_SIZE so that atomic writes never straddle a barrier unit. A bio that passes block-layer validation may still become unserviceable within RAID1 due to bad blocks or write-behind constraints. In the former case, complete the bio with EIO. In the latter case, disable write-behind rather than failing the bio with EIO. Fixes: f2a38abf5f1c ("md/raid1: Atomic write support") Fixes: a4c55c902670 ("md/raid1: simplify raid1_write_request() error handling") Reviewed-by: John Garry Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260710101521.1714-3-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit acff2713c3212ade15051e7b421f15c89927e70f Author: Jeff Johnson Date: Tue Jul 28 18:05:29 2026 -0700 wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() [ Upstream commit 7a246c72132eb943b5844ba79dad597b47429dba ] Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only. Fixes: 5b90fc760db5 ("ath11k: fix wmi service ready ext tlv parsing") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-2-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 26f8f87f0a556e7984366c64cebc16d49e15d22f Author: Jeff Johnson Date: Tue Jul 28 18:05:28 2026 -0700 wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() [ Upstream commit 4c6eb712a91fa079be6f9f1419c96e0ad2227081 ] Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-1-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ba1ee854b681ace60c307fad5ee5f65eb43733c3 Author: Fushuai Wang Date: Fri Jul 24 17:31:51 2026 +0800 Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration" [ Upstream commit 57c0741b8c15b93ba4aa92c6618cde6f3f4115b2 ] This reverts commit d338ab1d90603f875c4f7ed223406535378173a5. uart_console() only indicates that the port is selected as the console. It does not mean that the console has already been registered or has printed the buffered messages. On platforms where an initial 8250 port is replaced when the real UART device is registered, clearing CON_PRINTBUFFER causes the console to start at the end of the printk ring buffer. Without earlycon, all messages logged before UART registration are therefore lost. Fixes: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Reported-by: Mark Brown Reported-by: Anirudh Srinivasan Link: https://lore.kernel.org/all/20260522101042.21976-1-fushuai.wang@linux.dev/ Signed-off-by: Fushuai Wang Reviewed-by: John Ogness Link: https://patch.msgid.link/20260724093151.53216-1-fushuai.wang@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cd2e2685209483dcc25c74aa2cbd94c8addad9ba 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 81b39df5d701976cf20e52f33106c1fc1603b4cb Author: Abd-Alrhman Masalkhi Date: Wed Jul 8 11:20:03 2026 +0000 md: recheck spare changes before starting sync [ Upstream commit c7d34d17ea43ebc86b45d439ebb435e11ca44bca ] remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing. Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260628142420.1051027-1-abd.masalkhi@gmail.com?part=3 Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260708112003.474537-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 9bb9504e2d8f3d22ef12d51c333dd499f402dc8f Author: Abd-Alrhman Masalkhi Date: Sun Jun 28 14:27:37 2026 +0000 md: remove REQ_NOWAIT support from raid1/10/456 [ Upstream commit 3fe5b7c9fb72ccc29bfd0f955b124892af7e3674 ] REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data. Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support. Fixes: bf2c411bb1cf ("md: raid456 add nowait support") Fixes: c9aa889b035f ("md: raid10 add nowait support") Fixes: 5aa705039c4f ("md: raid1 add nowait support") Fixes: f51d46d0e7cb ("md: add support for REQ_NOWAIT") Suggested-by: Yu Kuai Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260628142737.1051059-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit f6215e3a65f195c531838c18197ece8594e670cf Author: Thomas Weißschuh Date: Mon Jul 27 17:02:48 2026 +0200 tools/nolibc/powerpc: mark ctr and xer as clobbered by system call [ Upstream commit b9fc5a1742b0c8fb7edf066cc17fa0b18b7be623 ] The system call can clobber the ctr and xer registers. Make sure the compiler takes this into account. The missing clobbers only seem to be an issue with newer compilers. Fixes: 0cb0675ec37e ("tools/nolibc: add support for powerpc") Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260727-nolibc-powerpc-clobber-v1-1-e0911cc99ce1@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 86d4e8c527deef46d1251d2d47886327121722b6 Author: Yichong Chen Date: Thu Jul 30 15:06:48 2026 +0800 fanotify: stop permission watchdog when timeout is zero [ Upstream commit 17463fe751309330b74618560f181426f643aa3d ] The fanotify permission watchdog can be disabled by writing zero to fs/fanotify/watchdog_timeout. fanotify_perm_watchdog_group_add() already checks for a zero timeout before scheduling the watchdog. However, once the watchdog work has been scheduled, perm_group_watchdog() unconditionally schedules itself again with the current timeout. If the sysctl is changed to zero while the work is active, secs_to_jiffies(0) causes the work to be rescheduled immediately, resulting in a kworker busy loop. Read the timeout once in perm_group_watchdog_schedule() and do not schedule the work when it is zero. This lets a running watchdog stop after the next execution when the sysctl is set to zero. Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260730070648.549458-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0187a11e2d61297410e52cc820d9a067f7932be7 Author: Chen Cheng Date: Sat Jun 27 18:25:19 2026 +0800 md/raid5: protect lockless recovery_offset accesses during reshape [ Upstream commit a47431dfb3538a1485f65b68a0605a05307b5b2d ] During reshape: - reshape_request() advances rdev->recovery_offset for non-In_sync devices locklessly. - analyse_stripe() reads rdev->recovery_offset locklessly to decide: a. use a replacement device to read ? b. a device can already be treated as in-sync for the current stripe ? one possible scenario is: CPU1 CPU2 reshape_request() -> mddev->curr_resync_completed = sector_nr -> if (!mddev->reshape_backwards) -> rdev->recovery_offset = sector_nr analyse_stripe(sh) -> rdev = conf->disks[i].replacement -> if (rdev->recovery_offset >= sh->sector + stripe_sectors) set_bit(R5_ReadRepl) -> or -> if (sh->sector + stripe_sectors <= rdev->recovery_offset) set_bit(R5_Insync) And it could be: - reading from a replacement before it is recovered far enough; or - treating a not-yet-recovered device as in-sync for the current stripe. Fixes: db0505d32066 ("md: be cautious about using ->curr_resync_completed for ->recovery_offset") The race report: ================================================================== BUG: KCSAN: data-race in ops_run_io / reshape_request write to 0xffff8bdee168b270 of 8 bytes by task 1704 on cpu 10: reshape_request+0x1292/0x17b0 raid5_sync_request+0x815/0xa00 md_do_sync.cold+0xf8d/0x1516 [......] read to 0xffff8bdee168b270 of 8 bytes by task 1696 on cpu 9: ops_run_io+0xc25/0x1960 handle_stripe+0x2273/0x4570 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7d5/0xb90 [......] value changed: 0x0000000000091a00 -> 0x0000000000091b00 ================================================================== Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260627102519.136940-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bae1d7735113998714d33a08eadafcd705fda3fe Author: Lorenzo Bianconi Date: Sat Jul 25 22:41:41 2026 +0200 net: airoha: fix ETS QoS stats counter underflow and cross-channel corruption [ Upstream commit 8b9a508819880c0c41d70f5b655bbd0baa231395 ] airoha_qdma_get_tx_ets_stats() has two bugs: - The hardware counters read via airoha_qdma_rr() are 32-bit values but are stored in u64 locals and subtracted from u64 baselines. When a 32-bit hardware counter wraps around, the subtraction produces a large underflow value passed to _bstats_update(). - The baseline counters (cpu_tx_packets, fwd_tx_packets) are stored as single per-device fields, but airoha_qdma_get_tx_ets_stats() is called with different channel values (0-3). Each call reads a different channel's hardware counter but overwrites the same baseline, corrupting the delta computation for other channels. Fix both by: - Narrowing the counter locals and baselines to u32 so that 32-bit unsigned subtraction handles wrap-around naturally. - Grouping the baselines into a per-channel qos_stats array so each channel tracks its own previous counter value independently. - Splitting the delta addition into two statements so the first u32 delta is widened to u64 on assignment and the second is added in u64 arithmetic, preventing overflow when both deltas are large. Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Reviewed-by: Simon Horman Reviewed-by: Alexander Lobakin Reviewed-by: Jacob Keller Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260725-airoha-ethtool-priv_flags-v12-2-5136a30b2157@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4b9a1b5203d4e070a28b055a663f49759808d698 Author: Chen Cheng Date: Wed Jun 24 10:40:42 2026 +0800 md/raid5: fix lockless max_nr_stripes reads [ Upstream commit 6cb6ab75bdf2f49c0adb0fd6971886b082932eaa ] max_nr_stripes is updated under cache_size_mutex in the stripe cache grow/shrink paths, while is_inactive_blocked() and raid5_end_read_request() read it without that lock. Use READ_ONCE() for those reads in lockless path to match the WRITE_ONCE() updates and avoid KCSAN data race reports. A similar issue was previously fixed in commit-id: dfd2bf436709b2bccb78c2dda550dde93700efa7. Fixes: 0009fad03337 ("raid5 improve too many read errors msg by adding limits") Fixes: 3514da58be9c ("md/raid5: Make is_inactive_blocked() helper") KCSAN report: ================= BUG: KCSAN: data-race in grow_one_stripe / is_inactive_blocked write (marked) to 0xffff8f01f0b5a268 of 4 bytes by task 12616 on cpu 9: grow_one_stripe+0x2d8/0x320 raid5d+0xb57/0xba0 md_thread+0x15a/0x2d0 [..........] read to 0xffff8f01f0b5a268 of 4 bytes by task 12670 on cpu 11: is_inactive_blocked+0x97/0xc0 raid5_get_active_stripe+0x2fd/0xa70 raid5_make_request+0x4aa/0x2940 [..........] value changed: 0x000003b9 -> 0x000003ba Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260624024042.2561803-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit fcf21df7d3c50c8ebeb0757df5d21b02dcae4218 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 16b6e6243d81fe41500f1334fe789135cbf351da Author: Chen Cheng Date: Mon Jun 22 20:46:49 2026 +0800 md/raid5: protect bitmap batch counters aka seq_flush/seq_write consistency [ Upstream commit f565925810cb8bc799421485770e15d922ef766a ] kcsan detect race : - raid5d() closes the current bitmap batch by updating conf->seq_flush under conf->device_lock. - __add_stripe_bio() read conf->seq_flush without that lock when assigning sh->bm_seq. so, protect seq_flush/seq_write consistency for multiple CPUs by READ_ONCE()/WRITE_ONCE() under the path without held device_lock. re-explain the stripe batch sequence number update flow: 1. sh->bm_seq declare which batch number the stripe belongs to when perform bitmap-related write. ==> bm_seq = seq_flush+1 2. stripe be handled, * if sh->bm_seq - conf->seq_write > 0, means the batch stripes **newer than** the last written batch, it cannot proceed yet, queued on bitmap_list. * otherwise , has already proceed. 3. raid5d() `++seq_flush` to closes the current batch, means * no more stripes join that old batch * just-closed batch ready to write-out to disk 4. raid5d() calls bitmap hooks unplug() or writeout, then, `++seq_write` to the same as bm_seq. - seq_flush - for producer, to close batches. - seq_write - for consumer, the checkpoint number. the report: ==================================== BUG: KCSAN: data-race in __add_stripe_bio / raid5d write to 0xffff88ba5625d470 of 4 bytes by task 82401 on cpu 0: raid5d+0x1d9/0xba0 [.....] read to 0xffff88ba5625d470 of 4 bytes by task 82421 on cpu 8: __add_stripe_bio+0x332/0x400 raid5_make_request+0x6ac/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 [.....] Fixes: 7c13edc87510 ("md: incorporate new plugging into raid5.") v1 -> v2: - remove WRITE_ONCE(conf->seq_write) in held device_lock path. - remove READ_ONCE(conf->seq_flush) in held device_lock path. Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260622124649.1780233-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 4743959aa8d876b5b456a62e8a62eb770db7afe9 Author: Yuho Choi Date: Tue Jul 7 14:51:00 2026 -0400 bus: mhi: host: Fix controller cleanup on EDL sysfs failure [ Upstream commit 0d5b9e66591d4e2a4376ac82c8cda889a29ba3ee ] mhi_register_controller() adds the controller device before creating the optional trigger_edl sysfs file. If sysfs_create_file() fails, the error path only drops the device reference and leaves the device registered. Hence, call device_del() in the error path before put_device(). Fixes: 17553ba8e19d ("bus: mhi: host: Add sysfs entry to force device to enter EDL") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 84e713a8aa7fe722f8faa278c828e5ca62401da2 Author: Manivannan Sadhasivam Date: Tue Jun 23 16:51:34 2026 +0200 bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET [ Upstream commit 24f4423cbc89548def2b05ae86de6175086dbf94 ] mhi_soc_reset() tries to reset the device by writing to the MHI_SOC_RESET_REQ_OFFSET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before returning to the caller. This may lead to the delay (if implemented) on the caller to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the MHI_SOC_RESET_REQ_OFFSET register. Fixes: b5a8d233a588 ("bus: mhi: core: Add device hardware reset support") Reported-by: Alex Williamson Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeff Hugo Link: https://patch.msgid.link/20260623145134.43976-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Sasha Levin commit 1b68b6e529ce75112fab98e89583a76370ca394b 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 05c1081ae4503e45b934b390350f942db3208892 Author: Hongyan Xu Date: Wed Jul 29 18:32:17 2026 +0800 platform/chrome: cros_ec_debugfs: Unregister panic notifier [ Upstream commit e5954d3031fb55dd31aa59bae477d63c68e941c0 ] cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit e97d1fce7173f0ebbbfa618265821071a4714ca6 Author: Hongyan Xu Date: Wed Jul 29 18:32:16 2026 +0800 platform/chrome: cros_ec_debugfs: Clean up console log on probe failure [ Upstream commit 5d187600c4603b8f7812b12ce359a11ad7a7fd3a ] Add a dedicated error label for failures after successful console log setup. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/c00974953a1b952f51f0f021d7f9fad134159909.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 618781e47fb04a0495006cdf869fe8010ec0b700 Author: Surendra Singh Chouhan Date: Fri Jul 24 18:28:57 2026 +0530 regulator: tps65185: handle gpiod_get_value_cansleep() error returns [ Upstream commit 623d9a55685c52b10b995d8dbde9da6283170220 ] tps65185_vposneg_enable() evaluated: if (gpiod_get_value_cansleep(data->pgood_gpio) != 1) return -ETIMEDOUT; gpiod_get_value_cansleep() returns 1 if active, 0 if inactive, and a negative error code (e.g. -EIO or -EINVAL) on failure. Evaluating != 1 treats a negative error code as non-equal, swallowing GPIO read errors and masking them as -ETIMEDOUT. Fix this by capturing the return value of gpiod_get_value_cansleep(). If it returns a negative error code, propagate that error immediately; if it returns 0 (inactive), return -ETIMEDOUT. Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver") Signed-off-by: Surendra Singh Chouhan Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260724125858.75635-1-kr494167@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 08835d42ce640a9625fb09e1e788b94989c9b988 Author: Jens Remus Date: Mon Jul 13 16:42:30 2026 +0200 s390/vdso: Pass --eh-frame-hdr to the linker [ Upstream commit dc161efb6df8518b3cfa7f0a5efdc16a1aee815b ] Commit 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") accidentally broke the GNU_EH_FRAME program table entry in the vDSO, causing it to be empty: $ readelf --program-headers arch/s390/kernel/vdso/vdso.so ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align ... GNU_EH_FRAME 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x8 ... Originally, the compiler would implicitly add --eh-frame-hdr when invoking the linker, but when this Makefile was converted from invoking the linker via the compiler, to invoking it directly, the option was missed. This is the s390 variant of x86 commit cd01544a268a ("x86/vdso: Pass --eh-frame-hdr to the linker"). Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Reviewed-by: Ilya Leoshkevich Acked-by: Heiko Carstens Signed-off-by: Jens Remus Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 4d030d7d1af95d24d3eb6e536a4f09b7bf9a8659 Author: Dan Carpenter Date: Fri Jul 17 12:12:29 2026 +0300 media: stm32: dcmi: fix some error handling bugs in probe() [ Upstream commit f1d1ed39ced825615aeac61f0b6a322178756632 ] There are a few issues here: 1) After we assign: chan = dma_request_chan(&pdev->dev, "tx"); Then the error paths need to clean up before returning. The first error path does a direct return. 2) The error paths check "dcmi->mdma_chan" but that is not assigned until later so it results in memory leaks. Test "mdma_chan" instead. 3) The error handling calls dma_release_channel(dcmi->dma_chan) before "dcmi->dma_chan" has been assigned which leads to a NULL pointer dereference. Use the "chan" variable instead. I also moved the call to dma_release_channel() after the call to dma_release_channel() so it mirrors the allocation code better. Fixes: bc901885fae0 ("media: stm32: dcmi: perform dmaengine_slave_config at probe") Signed-off-by: Dan Carpenter Acked-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit cb83cfff8dff5d546fadce15596e01b1504b632a Author: Hungyu Lin Date: Thu Jun 4 05:04:51 2026 +0000 media: qcom: iris: handle runtime PM resume failure in core deinit [ Upstream commit 75d79879ec3cbfd288144b0ae4c3e3fa7700c5fc ] Check the return value of pm_runtime_resume_and_get() in iris_core_deinit(). If runtime PM resume fails, skip hardware power-off operations but still perform software teardown and state transition. Also skip the corresponding pm_runtime_put_sync() call to avoid unbalanced runtime PM references. Fixes: bb8a95aa038e ("media: iris: implement power management") Signed-off-by: Hungyu Lin Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 6bd10931ac2d48064417d5e60827eab276329578 Author: Dikshita Agarwal Date: Sun May 31 11:20:39 2026 +0530 media: qcom: iris: Remove duplicate HFI_PROP_OPB_ENABLE entry [ Upstream commit 727a87c71b4ef794cdf552dae585d6f67be690ee ] HFI_PROP_OPB_ENABLE/iris_hfi_gen2_set_opb_enable appeared twice in the dispatch table, causing the property to be sent to firmware twice on every config-params call. Fixes: 2af481a459a4 ("media: iris: Define AV1-specific platform capabilities and properties") Reviewed-by: Konrad Dybcio Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit a5e341a25de36f0ef58d2487346aa1c913c2ee80 Author: Dikshita Agarwal Date: Sun May 31 11:20:37 2026 +0530 media: qcom: iris: Fix bitmask test in iris_allow_cmd() [ Upstream commit 0ac05c4d9f1fa25d0692fb154de36bd3baf2e7ce ] iris_allow_cmd() incorrectly checks a sub‑state flag using a logical equality comparison. Since sub_state is a bitmask, this allows STOP to pass when IRIS_INST_SUB_DRAIN is set alongside other bits, violating the intended drain semantics. Fix this by using a proper bitmask test. Fixes: d09100763bed ("media: iris: add support for drain sequence") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 8a61c211d0d52ce8e6c8b27dd077298cb0f1c08b Author: Anna Maniscalco Date: Thu Jul 23 21:23:22 2026 +0200 drm/msm: remove objects from evit list after pinning them [ Upstream commit 83723f32cb3de23d45c1ac09241b5e0cfb32cc9b ] Once objects are pinned they should not be kept in the evict list as that will cause drm_gpuvm_validate to keep ieterating a growing list of objects needlessly. Once an object is pinned remove it from the list. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Anna Maniscalco Patchwork: https://patchwork.freedesktop.org/patch/742166/ Message-ID: <20260723-evict_list_fix-v2-1-bd0725e56253@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 29d6bbda42aa93979f272b1ef9ba056e73afc9d6 Author: Ali Tariq Date: Sat Jul 18 20:33:51 2026 +0500 PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe [ Upstream commit aaae917990623a6ca6b638557056606a1ae4a8d6 ] pm_runtime_get_sync() is called in starfive_pcie_probe() without checking its return value. If runtime resume fails, the driver proceeds to configure PCIe hardware through regmap_update_bits(), enable clocks and resets, and power on the PHY, even though the device may not actually be powered. pm_runtime_get_sync() also increments the usage counter even when resume fails, which would leave the counter unbalanced if this error path were later handled without additional cleanup. Switch to pm_runtime_resume_and_get(), which balances the usage counter internally on failure, and bail out of probe before any hardware is touched if resume does not succeed. Tested on StarFive VisionFive 2 v1.2A board. Fixes: 6168efbebace ("PCI: starfive: Enable controller runtime PM before probing host bridge") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718153352.661930-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin commit dad14ba26c9a26c82ccd7b1fb971285856242ea8 Author: Ali Tariq Date: Sat Jul 18 18:38:25 2026 +0500 PCI: starfive: Fix Runtime PM handling and teardown ordering [ Upstream commit fb9f7973473fc30d62e0f5f90d59df8ef5223777 ] The starfive_pcie_remove() path incorrectly disabled runtime PM before executing plda_pcie_host_deinit(), which can cause unmanaged hardware register access in plda_pcie_host_deinit() while power domains or clocks are disabled. Fix this by restructuring starfive_pcie_remove() to deinitialize the host controller first while runtime PM is active, followed by a synchronous pm_runtime_put_sync() and pm_runtime_disable(). This bug was found in automated AI review by sashiko-bot. Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Closes: https://lore.kernel.org/linux-pci/20260712180440.423421F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718133825.445041-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin commit 7c7fad5607dc287f0134b80032798ef53a22a1cb Author: Jeff Johnson Date: Sun Jul 26 16:02:07 2026 -0700 wifi: ath12k: validate TLV length in process_tpc_stats() [ Upstream commit 8e415b8068480d51a057197ded974e2637e8c42b ] The outer skb->len guard only confirms the SKB is large enough to hold the full fixed_param struct, but the TLV's own WMI_TLV_LEN field is never checked. Firmware advertising a TLV length shorter than sizeof(*fixed_param) causes reads of pdev_id and event_count beyond the declared TLV payload. Add a check that the TLV length is at least sizeof(*fixed_param) before casting and dereferencing the pointer. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260726-ath12k_wmi_process_tpc_stats-len-check-v1-1-c4ba2f84d9c6@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5de2b8c53714ad58f2fda118cd29ebbe31b38665 Author: Jeff Johnson Date: Fri Jul 24 08:56:14 2026 -0700 wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() [ Upstream commit 208d7fdb85976a737a715b81d54efaff6703880c ] There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. 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/20260724-ath12k_wmi_process_csa_switch_count_event-cleanup-v2-2-02a45d7246c0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit bf97c9d5123859a07848462539153176db029f3a Author: Jeff Johnson Date: Fri Jul 24 08:56:13 2026 -0700 wifi: ath12k: fix overreads in ath12k_wmi_process_csa_switch_count_event() [ Upstream commit 878654eb78c6aa0ff585baf1376567c775ca28ec ] There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath12k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath12k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260724-ath12k_wmi_process_csa_switch_count_event-cleanup-v2-1-02a45d7246c0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 761cf9c63274a5b711c3dc829601723215710d2d Author: Adrián Larumbe Date: Mon Jul 20 16:48:41 2026 +0100 drm/panthor: Add vm_bind region with kbo range overlap check [ Upstream commit 985f5e12f3cdf43030e13c2bbd154913133b5c3f ] When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources. Fixes: 12cf826bf1dd ("drm/panthor: Support sparse mappings") Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon Signed-off-by: Adrián Larumbe Reviewed-by: Steven Price Link: https://patch.msgid.link/20260720-vm_bind_checks-v6-1-c2c7dbe93a73@collabora.com Signed-off-by: Steven Price Signed-off-by: Sasha Levin commit 1a7958ce58dc95b06615df00c120ece4eb9ccc86 Author: Fan Wu Date: Sun Jul 19 01:00:14 2026 +0000 spi: davinci: switch to managed controller allocation [ Upstream commit ea408a05dc8f18b4a184b88d6e19d2fd1acc1527 ] The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool. Fixes: 5b3bb5963ff2 ("spi: davinci: Use devm_*() functions") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260719010014.3163356-2-fanwu01@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 44ec34cd3cbea9bed69a671b5b7d6004bfb73786 Author: Guixin Liu Date: Wed Jul 29 19:02:31 2026 +0800 nvmet: reject out-of-range mdts values in configfs store [ Upstream commit bf881dd20062db5e951a0d0703cb476df8c9fdee ] nvmet_param_mdts_store() accepts any integer that kstrtoint() can parse and stores it directly into port->mdts. The value is only range-checked later, when the port is enabled: nvmet_enable_port() silently resets port->mdts to 0 if it is negative or greater than NVMET_MAX_MDTS. As a result, writing e.g. "mdts=1000" succeeds and reading the attribute back returns 1000, yet enabling the port quietly turns it into 0. This is confusing and hides the invalid input from the user. Validate the value against [0, NVMET_MAX_MDTS] in the store handler and reject anything out of range with -EINVAL, so the error is reported at write time and port->mdts never holds a value the port cannot use. Fixes: 0a5a94648627 ("nvmet: introduce new mdts configuration entry") Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 06352dae949c146a051262f1566059285a2e6a56 Author: Guixin Liu Date: Wed Jul 29 18:59:58 2026 +0800 nvme-pci: return error when parsing a quirk string fails [ Upstream commit df74eaad001cf669c332dc67ef91996532e6b52c ] quirks_param_set() reuses 'err', which param_set_copystring() left as 0, as the return value of the whole function. When nvme_parse_quirk_entry() fails to parse a field, the code jumps to out_free_qlist and returns that stale 0, so a malformed quirks= parameter is silently accepted as valid. Set err to -EINVAL before jumping out on a parse failure. Fixes: 7bb8c40f5ad8 ("nvme: add support for dynamic quirk configuration via module parameter") Reviewed-by: Christoph Hellwig Reviewed-by: Daniel Wagner Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit be5eb47ee3fea338efae1a5b678d6bb5f0fcc931 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 9e136150ac55df4b7ea36e6110ffa39d08905f37 Author: Guixin Liu Date: Wed Jul 29 18:56:07 2026 +0800 nvmet: fix return status of RMI log page on allocation failure [ Upstream commit 581d8bb556dd3e5567bcf322aa5e3e4b6a200c08 ] nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS (set by the successful nvmet_req_find_ns() call) when the kzalloc() for the log buffer fails. It then jumps to the out label and completes the request with a success status, so the host is told the command succeeded while no data was transferred. Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler, so an allocation failure is reported as an internal error. Fixes: 5fd075cdaf36 ("nvmet: implement rotational media information log") Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 48812c8103071d550d9ab4a3431be5bdc52255bc 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 352dc85324b29f5c85876f2666f3158b645e3f18 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 c12cc56eb9fcd4b68faf6456c61744c23c00921c Author: Cong Nguyen Date: Mon Jul 27 18:22:39 2026 +0700 media: staging/ipu7: fix async notifier leak on init error [ Upstream commit 11ccf31a657f9f95260a22848b7d324d3c6cf113 ] isys_notifier_init() initialises a v4l2 async notifier and then, for each CSI-2 port, adds a remote sensor subdev to the notifier's waiting_list via v4l2_async_nf_add_fwnode_remote(), which allocates a sensor_async_sd descriptor and takes a fwnode reference. If parsing or adding a later port fails, the code jumps to the "err_parse" label, which only drops the current endpoint fwnode reference and returns, without calling v4l2_async_nf_cleanup(). Any descriptors already added to the notifier for earlier ports are therefore leaked, and the caller's error path does not clean up the notifier either. Call v4l2_async_nf_cleanup() on the error path, matching the cleanup already performed when v4l2_async_nf_register() fails. This is safe as the notifier is always initialised before the loop is entered. Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device driver") Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit a64e2beb450179a5d43034af8d5476a11eac1486 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 5b96c5ba26a8fe52720105a9bfca1de35b6774f0 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 c75ee076fa09778a2f9602a972dade4a0b0785f7 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 6b15fc9bc117fb6597fa1c2cc30284aafe71101c Author: Leon Romanovsky Date: Wed Jul 29 07:21:28 2026 -0400 RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() [ Upstream commit 373f3716a2de7adc739269ebb4d87e5bf4dc180c ] When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem(). Fixes: 0f8ab0b6e91b ("RDMA/iw_cxgb4: Low resource fixes for Memory registration") Link: https://patch.msgid.link/20260726-leaked-mhp-dereg-skb-in-c4iw-dereg-m-v1-1-ebd6df364d53@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 254579a81e49aaec1feec3a257bdcec69edb6304 Author: Inochi Amaoto Date: Wed Jul 29 09:24:17 2026 +0800 riscv: dts: spacemit: Make dtschema recognize the etherent PHY correctly on K3 com260 board [ Upstream commit bff5af3c934740481a316c5ae1cd4a09a43134d0 ] Since the previous commit does not change the phy node name, the dtschema can not recognize the type of the ethernet phy, so the following error is produced: /arch/riscv/boot/dts/spacemit/k3-com260-ifx.dtb: phy@1 (ethernet-phy-id001c.c916): $nodename:0: 'phy@1' does not match '^ethernet-phy(@[a-f0-9]+)?$' from schema $id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml /arch/riscv/boot/dts/spacemit/k3-com260-ifx.dtb: phy@1 (ethernet-phy-id001c.c916): Unevaluated properties are not allowed ('reg', 'reset-assert-us', ' reset-deassert-us', 'reset-gpios' were unexpected) from schema $id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml Change the nodename to make the dtschema can recognize the right PHY type. Fixes: 9db839d52ccd ("riscv: dts: spacemit: Fix phy id check for the phy on com260 board") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729012418.154652-2-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 63ad1eb9dcebbb6182854b6d2594b0f6177ad3bb Author: Inochi Amaoto Date: Wed Jul 29 09:24:16 2026 +0800 riscv: dts: spacemit: Make dtschema recognize the etherent PHY correctly on K3 pico-itx board [ Upstream commit 9b371a8b13fd0e8e6f3b12f4ef7e58927d6f62ee ] Since the previous commit does not change the phy node name, the dtschema can not recognize the type of the ethernet phy, so the following error is produced: /arch/riscv/boot/dts/spacemit/k3-pico-itx.dtb: phy@1 (ethernet-phy-id001c.c916): $nodename:0: 'phy@1' does not match '^ethernet-phy(@[a-f0-9]+)?$' from schema $id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml /arch/riscv/boot/dts/spacemit/k3-pico-itx.dtb: phy@1 (ethernet-phy-id001c.c916): Unevaluated properties are not allowed ('reg', 'reset-assert-us', 're set-deassert-us', 'reset-gpios' were unexpected) from schema $id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml Change the nodename to make the dtschema can recognize the right PHY type. Fixes: 6d6536c880fe ("riscv: dts: spacemit: Fix phy id check for the phy on pico-itx board") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729012418.154652-1-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit fcf7e0500ea9a68f6c60bc16c64bc7c710a96817 Author: Troy Mitchell Date: Fri Jul 17 00:26:03 2026 -0700 clk: spacemit: k3: fix missing /2 factor in i2s sysclk dividers [ Upstream commit 8a7d4b1924d2a424b1a6fe69de4f9464ee1fb485 ] The i2s{0,2,3,4,5}_sysclk_div DDNs have an additional fixed 1/2 divider in the hardware IP after the configurable divider, so the real output rate is: rate = parent_rate * den / (num * 2) Set pre_div to 2 to account for it. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Signed-off-by: Troy Mitchell Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260717-k3-clk-fix-i2s-v1-3-e95001a692ee@linux.spacemit.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit fcadc927cbff473c2fe7790c24d07b16a5da3cff Author: David Strahan Date: Wed Jul 22 17:03:58 2026 -0500 scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between dispatches. [ Upstream commit 225548863f0a2350c6f34231ca56710c3dd1a5d5 ] On recent Linux kernels the driver can enter a retry loop on the AIO fast path when a request is retried, looping until timeout. A diagnostic path that takes a physical drive offline on AIO-bypass failure is also never entered on affected kernels. Register a per-command initialization callback with the SCSI core. Its presence causes the core to skip the per-dispatch clear, so the retry marker now survives across the requeue and the AIO-to-RAID fallback proceeds as intended. The driver takes over the marker's lifetime: it is zeroed at tag allocation, preserved across the retry requeue so the error path can act on it, and cleared on terminal completion so the tag starts clean on its next use. Fixes: dce5c4afd035 ("scsi: core: Clear driver private data when retrying request") Co-developed-by: Mike McGowen Signed-off-by: Mike McGowen Acked-by: Don Brace Signed-off-by: David Strahan Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/ Link: https://patch.msgid.link/20260722220401.6357-2-david.strahan@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f181155baf0c93a74ebe804c6cecbe970e78ee9e Author: Ryusuke Konishi Date: Mon Jul 20 23:16:52 2026 +0900 nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch [ Upstream commit 66f4ad3ce158902e5f98afea93189972ed8750c2 ] Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode. Reported-by: syzbot+8baf9a79a3ffc6271cb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8baf9a79a3ffc6271cb6 Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 15c8559376416a84c3d8402fd8d0c89bb323d05f 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 8cea0bc78ac64cb88da49c07f80bf2cf9fb7aff8 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 44ea94a65fd279a1b18d9e915b7631113e9eea6f Author: Alexey Charkov Date: Thu Jul 23 14:21:59 2026 +0400 clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement [ Upstream commit 5814788834774ed6ad1a27ae91b44eeca80cd27f ] When the PLL rates table was first committed for RK3588 (and later reused for RK3576), the fractional PLL coefficient was defined as an unsigned value, while the TRM clearly states that it is a two's complement 16-bit value. Treating the fractional PLL coefficient as unsigned in rate recalculation results in a kernel-visible rate which deviates from what the hardware actually generates by Fin / (p * 2^s), or 2 MHz for the two affected table entries. Rockchip's downstream kernel later revised the fractional PLL code [1] to account for the two's complement nature of the coefficient, but that change wasn't upstreamed. Change the PLL table definition to use two's complement for the fractional coefficient and update its users accordingly. Note that a negative fractional coefficient is meant to be subtracted from the next larger integer multiplier, so the m values in the table are also adjusted accordingly for the two negative-k entries. Rockchip's downstream commit introducing the two's complement logic for k also does unrelated tweaks to the PLL parameters which are not explained by the switch to the two's complement, so they are not replicated here. If any of the parameters prove to need further tweaks (e.g. for precision or jitter) that would better be done in targeted follow-up commits. Fractional PLL rates don't seem to be used by any current mainline consumers, so this is purely a correctness fix. It will also be important to properly support DisplayPort output going forward, as the video output controller derives its pixel clock from system PLLs with no dedicated PHY PLL option for DP unlike HDMI, and some display modes are only achievable using fractional PLL rates. Link: https://github.com/flipperdevices/rockchip-linux/commit/7a72bc05dcc3a51e85ae531749e6270bf9b9212d [1] Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Fixes: cc40f5baa91b ("clk: rockchip: Add clock controller for the RK3576") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260723-rk3588-fracpll-v2-2-3adfb9dda235@flipper.net Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 554c752ebd460a034f1a270308866ff02cfac2eb Author: Alexey Charkov Date: Thu Jul 23 14:21:58 2026 +0400 clk: rockchip: Fix the fractional part denominator on RK3588/RK3576 PLLs [ Upstream commit 52aef653c3d0c24013dfa9eccf692594eacdbe17 ] According to the TRM, the fractional PLL coefficient should be divided by 65536 rather than 65535 to obtain the output rate. Fix the denominator and add a comment with the TRM provided clock formulae for future reference. See RK3576 TRM Part 1 V1.2 section 2.13.1.4 Setting Guide on P, M, S and K or equivalently RK3588 TRM part 1 V1.0 section 2.17.1.4 Setting Guide on P, M, S and K. Fractional PLL rates don't seem to be used by any current mainline consumers, so this is purely a correctness fix. It will also be important to properly support DisplayPort output going forward, as the video output controller derives its pixel clock from system PLLs with no dedicated PHY PLL option for DP unlike HDMI, and some display modes are only achievable with fractional PLL rates. Fixes: 8f6594494b1c ("clk: rockchip: add pll type for RK3588") Signed-off-by: Alexey Charkov Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260723-rk3588-fracpll-v2-1-3adfb9dda235@flipper.net Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 42a5661ff7e4c7d3c5025d0f8e5079fb5479ea49 Author: Gary Guo Date: Thu Jul 23 23:00:48 2026 +0100 PCI: Fix UAF when probe runs concurrent to dyn ID removal [ Upstream commit 3ffc4c9690c33ee28cdb3d0182b12f9c623e3acc ] Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe. Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry") Reported-by: Sashiko Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/ Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-9-3580726844e1@garyguo.net Signed-off-by: Sasha Levin commit e0b62b59a0abf8700e5588c02b636db408bcc45a Author: Gary Guo Date: Thu Jul 23 23:00:47 2026 +0100 PCI: Fix dyn_id add TOCTOU [ Upstream commit 04fde70f782b6ce984f9f80c2023786caea28287 ] Currently there is a TOCTOU issue in new_id_store() as the dyn ID insertion in pci_add_dynid() and the pci_match_device() are in separate critical sections. Fix this by moving the existing ID check to inside pci_add_dynid() and only check against the static ID table outside the critical section. Fixes: 3853f9123c18 ("PCI: Avoid duplicate IDs in driver dynamic IDs list") Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-8-3580726844e1@garyguo.net Signed-off-by: Sasha Levin commit 30f79038b676ba8283fa944ff60ef6b5264ad75d Author: Gary Guo Date: Thu Jul 23 23:00:46 2026 +0100 PCI: Make pci_match_one_device() match on ID instead of device [ Upstream commit c967b365d7b51c2297d9be5df39ac3e20638faf4 ] PCI dynamic ID needs to match IDs against a new ID to see if it already exists. Existing APIs can only match IDs against devices, so the dynamic ID insertion code creates a temporary device only for matching purposes. Rename pci_match_one_device() to pci_match_one_id() so it can be used for this purpose instead; add a pci_id_from_device() helper to make it easy to convert users. Similarly, convert pci_match_id() to do_pci_match_id(). But keep the existing API because there are many users. Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-pci_id_fix-v4-7-3580726844e1@garyguo.net Stable-dep-of: 04fde70f782b ("PCI: Fix dyn_id add TOCTOU") Signed-off-by: Sasha Levin commit 8e25cfa697a917032b6a4d8a810c6d768614a202 Author: Akari Tsuyukusa Date: Mon Jun 29 22:20:43 2026 +0900 clk: mediatek: mt8135: Fix inverted gate control for devapc_ck [ Upstream commit fd0e3e4edea6a3e4da91be608ca2fb9b348f9e32 ] The devapc_ck (CLK_INFRA_DEVAPC) on MT8135 is currently using "mtk_clk_gate_ops_setclr". However, checking the downstream kernel reveals that this clock is configured with set:enable and clr:disable making "mtk_clk_gate_ops_setclr_inv" the appropriate choice. But, it is strange that some downstream kernels are not like that. Amazon: INV ChromiumOS (early): not INV ChromiumOS 3.16 to 3.18-revew-v2: INV ChromiumOS 3.18-review-v3 and later (sent to kernel.org): not INV Link: https://github.com/amazon-oss/android_kernel_amazon_mt8135/blob/e2b2163a8ec4a7c8d961c89003a15b4ba0f0e371/arch/arm/mach-mt8135/mt_clkmgr.c#L1022-L1028 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/4b624ee66e65d5dcd43fca36b313086efae8922a/arch/arm/boot/dts/mt8135-clocks.dtsi#L944-L948 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/decd80c01d0dbe9f3afa8ff72273b5618b418180/drivers/clk/mediatek/clk-mt8135.c#L881-L882 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/9b6f06cb7637100aa1a42e1fc351b36b384a1c54/drivers/clk/mediatek/clk-mt8135.c#L450 Fixes: a8aede794843 ("clk: mediatek: Add basic clocks for Mediatek MT8135.") Signed-off-by: Akari Tsuyukusa Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 6bc007ee691c357b0fc99ddbf506071dbac1968d 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 a3c031fd2c4c8afb9a17b3c97ed6308e153d76c8 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 1183dc2450a268a536a15da8b106ec520cdbd19f Author: Kostas Damaskinakis Date: Fri Jul 10 17:15:20 2026 +0300 clk: eswin: Zero-initialize stack-allocated clk_init_data [ Upstream commit 011d8de504bc84402aabc1dda1cf0552fe9a5af2 ] eswin_clk_register_pll() and eswin_register_clkdiv() declare a struct clk_init_data on the stack and only initialize some of its fields (parent_data respectively parent_hws). clk_core_populate_parent_map() checks parent_names first and parent_data second before falling back to parent_hws, so leftover stack garbage in the uninitialized fields hijacks parent resolution and the clk core dereferences a bogus pointer: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000c Oops [#1] epc : __clk_register+0x31a/0x7f0 [] __clk_register+0x31a/0x7f0 [] devm_clk_hw_register+0x2a/0x94 [] eswin_register_clkdiv+0x80/0xd0 [] eswin_clk_register_clks+0x162/0x1a0 [] eic7700_clk_probe+0x146/0x180 [] platform_probe+0x3c/0x7a Observed on EIC7700 hardware (with the driver backported to a 6.17 tree); whether the bug triggers depends entirely on what the stack happens to contain when the registration helpers run. Zero-initialize both structures. Fixes: cd44f127c1d4 ("clk: eswin: Add eic7700 clock driver") Signed-off-by: Kostas Damaskinakis Reviewed-by: Brian Masney Acked-by: Xuyang Dong Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit fea0b4fd891a2af77b55e05b950e7ea55b5d234e Author: Louis-Alexis Eyraud Date: Thu Jul 9 14:23:00 2026 +0200 clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path [ Upstream commit 540d91480bcb1b28a62d7023aa70947ea44c55b9 ] When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop. Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: Brian Masney Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 8ed265c0b47201941698dfc935d71e2997315e66 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 41e42bf05da99e0f3fb25c78f74ae2ac4ddbb9f8 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 0b56ad971fa02271192ff0a8e673012be806a8c2 Author: Zhao Li Date: Tue Jul 28 19:13:26 2026 +0800 wifi: mac80211: fix per-STA profile length in cross-link CSA parsing [ Upstream commit 4a0bd262df757b25fc4e2a53c947317c119ced4e ] ieee80211_mgd_check_cross_link_csa() starts parsing elements after the fixed per-STA profile header and the STA Info field, but subtracts only the STA Info length from the profile length. As a result, ieee802_11_parse_elems() is given sizeof(*prof) == 3 bytes beyond the current profile's element area, and data following the profile may be interpreted as belonging to it. Subtract the fixed profile header as well. The preceding ieee80211_mle_basic_sta_prof_size_ok() check guarantees that the corrected calculation cannot underflow, and ieee80211_rx_uhr_link_reconfig_req() uses the same calculation. The call site currently states that cross-link CSA parsing has no effect because the broader parsing is still incorrect. This patch does not address that broader problem; it only makes the per-STA profile parser stop at the end of that profile. No production allocation over-read or user-visible failure has been demonstrated. Fixes: 7ef8f6821d16 ("wifi: mac80211: mlme: handle cross-link CSA") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260728111326.63087-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ce30b9f6ace6ff13d3b49c1d38e1c1d5bce6d3ea Author: Alain Volmat Date: Tue Jul 21 15:38:37 2026 +0200 media: stm32: dcmi: fix error handling on MDMA pool alloc failure [ Upstream commit 1bc5946763067d5b8dde2e5c11d7a7ddb89c8937 ] Properly return an error if of_gen_pool_get or gen_pool_dma_zalloc fails during the chained DMA probing. Fixes: 87ebce19aa03 ("media: stm32: dcmi: addition of DMA-MDMA chaining support") Signed-off-by: Alain Volmat Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1d4b5902773475fc97151379b7e5f09cad0fa57b 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 4cfb448705da3171d44d9cbe7be53ff03284d532 Author: Peiyang He Date: Mon Jul 27 13:06:59 2026 +0800 RDMA/rxe: Fix UAF in ODP init error-handling path [ Upstream commit 51f2c8d2c99fc1f452f7113c08a35edcc4bf8732 ] rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error. rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF. Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again. Fixes: d03fb5c6599e ("RDMA/rxe: Allow registering MRs for On-Demand Paging") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Peiyang He Link: https://patch.msgid.link/70CB6DBCB19624C7+20260727050659.1543627-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 417190bde0fda4ee857999a722ca90163fbec587 Author: Nicolin Chen Date: Tue Jul 14 13:55:06 2026 -0700 iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path [ Upstream commit f40f3144477314b489e4bc209c06cb51679fe82b ] tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0b139ec4641c7d4163d8e345c26cc630e24fa43b Author: Nicolin Chen Date: Tue Jul 14 13:55:05 2026 -0700 iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID [ Upstream commit fb292bfc9be936dade7eef7ec5762de1201983d8 ] tegra241_vintf_init_vsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Reject the mapping with -EOPNOTSUPP if master->num_streams is not one. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 421f5ab135cd4a1353891e5bf2602cfc3c01afc7 Author: Nicolin Chen Date: Tue Jul 14 13:55:03 2026 -0700 iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs [ Upstream commit 61f0d437988e5730b04442f6a7d30a9907339f2a ] tegra241_cmdqv_remove() tears each VINTF down first, then calls free_irq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241_cmdqv_isr() read the stale slot and hand it to tegra241_vintf0_handle_error(), which dereferences a NULL or freed pointer. Free the IRQ before tearing the VINTFs down. free_irq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down. Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 86197679b293f0601c3331d545f99a70a7780aa9 Author: Nicolin Chen Date: Tue Jul 14 13:55:02 2026 -0700 iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc() [ Upstream commit d4d05f55e9da646ec03adfa77260eb46f4163749 ] __tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path. Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a168254ff8db08f2292be3d8fcbd37d2bb8c3d2d Author: Nicolin Chen Date: Tue Jul 14 13:55:01 2026 -0700 iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs [ Upstream commit 5acd67ceb38debe2fbf70ea35e2dec9f7ab01bbd ] __tegra241_cmdqv_probe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->num_vintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241_cmdqv_isr() then walks the uninitialized cmdqv->vintfs array. Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f3ef4abc271a1d3d7b6715879e149c286dc8aae7 Author: Nicolin Chen Date: Tue Jul 14 13:54:59 2026 -0700 iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init [ Upstream commit a491be376abd1c80a314cdd658632c85cd660b73 ] A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b4535b403d6bf9bcc24dbd62096711329b9c612c Author: Nicolin Chen Date: Tue Jul 14 13:54:58 2026 -0700 iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized [ Upstream commit cbc41aacd49e695338940196e7084770365e1b68 ] tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 967a5ff8a614d10126b6d46db1ac040948d6cb42 Author: Weiming Shi Date: Tue Jun 23 03:14:35 2026 -0700 fs/ntfs3: reject restart table growth beyond U16_MAX entries [ Upstream commit 111f8d74a19d85942ecbb3aba78f6f3c88e59391 ] During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): rt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit e67992e9089be9920a53830eeacbd6125b381e85 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 c582b049fd021582a3e12db19a6dc561696fb4b4 Author: Ananthu C V Date: Thu Jul 9 23:39:44 2026 -0700 arm64: dts: qcom: glymur: fix SoCCP memory mappings [ Upstream commit 61e5b39e96aadeafa884ab96c1477b781dccf145 ] The currently listed SoCCP and SoCCP DTB reserved memory regions don't align with the memory requested by the SoCCP Firmware. Fix this by updating the SoCCP/SoCCP DTB memory regions to reflect the memory region requirements of the SoCCP firmware, as described in the Glymur v21 memory map release. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Ananthu C V Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260709-glymur-soccp-v6-3-16f70227547d@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0dc9e289bbb549ca0d8867804c7d709b9c795fd8 Author: Bjorn Andersson Date: Thu Jul 23 03:00:41 2026 +0000 remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side [ Upstream commit 0ea50486978f109e6d4c32267fab01ed654a2160 ] rpmsg client drivers are allowed to invoke rproc_report_crash() on their grandparent when they determine that the otherwise seemingly healthy remoteproc has entered a functionally broken state. In the crash handling path qcom_q6v5_request_stop() is invoked, which is based on the current rproc state whether to request a graceful shutdown. But the current rproc `state` will be RPROC_CRASHED regardless of where the crash handler was initiated from, and empirical data shows that unless the firmware is taking part of the shutdown the system state is often left such that it's not possible to start the subsystem again. Use the `running` state in the q6v5 driver to make the decision instead, as this does represent the actual state of the firmware. This makes it possible to reliably trigger a restart from client drivers. Fixes: 3cc889eb83f5 ("remoteproc: qcom: q6v5: Avoid setting smem bit in case of crash shutdown") Signed-off-by: Bjorn Andersson Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260723-q6v5-host-side-crash-v1-1-23bd53db90a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a8deb8980c636133d6c0c0645d85e4a26e49b181 Author: Jingyi Wang Date: Tue Jun 23 03:05:21 2026 -0700 remoteproc: qcom: pas: Add late attach support for subsystems [ Upstream commit 16472c99f4699cb28f2f5f946400ead02f58a15e ] Subsystems can be brought out of reset by entities such as bootloaders. As the irq enablement could be later than subsystem bring up, the state of subsystem should be checked by reading SMP2P bits. A new qcom_pas_attach() function is introduced. if crash state is detected for the subsystem, rproc_report_crash() is called. If the ready state is detected meanwhile stop state is not detected, it will be marked as "attached", otherwise it could be the early boot feature is not supported by other entities or it has already been stopped. In above cases, the state will be marked as RPROC_OFFLINE so that the PAS driver can load the firmware and start the remoteproc. Co-developed-by: Gokul Krishna Krishnakumar Signed-off-by: Gokul Krishna Krishnakumar Tested-by: Shawn Guo Signed-off-by: Jingyi Wang Tested-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-5-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 0ea50486978f ("remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side") Signed-off-by: Sasha Levin commit 61862ed651b2493573e6d2192d5640bc6616f5d0 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 0ff49320a49ca884c8716160fa79903ee71d77eb 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 38e4018ac5cc1c19c0ece2bc4cda3c65eac9f0b9 Author: Bjorn Andersson Date: Thu Jul 23 03:52:27 2026 +0000 remoteproc: Allow shutdown of crashed processors [ Upstream commit 2482ca875ef5993df8daee563033d70e2523a25f ] rproc_shutdown() rejects a remoteproc in RPROC_CRASHED state, and rproc_del() ignores that error. The result of these two decisions is that a user cannot stop a remoteproc that with recovery disabled that has entered a crash state, and removal of an associated remoteproc driver will release resources without first stopping the remoteproc. Allow rproc_shutdown() to stop crashed processors. Propagate the crash state to subdevice teardown, to allow subdevices to dismantle things appropriately. Assisted-by: OpenCode:GPT-5.5 Fixes: 5e6a0e05270e ("remoteproc: core: Move state checking to remoteproc_core") Signed-off-by: Bjorn Andersson Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-1-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b22af817f56d0bcfaf7e1da2fdf1cdcaa0c0966c Author: K Prateek Nayak Date: Mon Jul 27 07:20:48 2026 +0000 cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf [ Upstream commit 5c3ecf36d2918facff40548ee6ae28eef0865266 ] amd_pstate_update_min_max_limit() sets the min_limit_perf to the nominal_perf to avoid frequency throttling when the system is idling. This was found to be an ideal default but is suboptimal for users who have profiled their workload at different operating frequencies and have configured the optimal idling frequency via bios_min_perf. Use the bios_min_perf (if configured) as the min_limit_perf when running with performance governor. In absence of bios_min_perf, continue using nominal_perf as the default min_limit_perf to avoid throttling. Fixes: 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260727072056.1248-2-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 732fc96c1f872025eb10a23f6cf74ec57c456ec2 Author: Ian Rogers Date: Wed Jul 22 21:59:48 2026 -0700 perf annotate: Be robust to annotating without a thread [ Upstream commit b84e081e071da548a531875258fa4b513d786331 ] If a thread isn't given to map_symbol__get_arch(), try harder to determine the arch for disassembly. Do this by utilizing fallback paths such as reading the e_machine from a map's DSO ELF header for user-space libraries. Additionally, rely on map__kmaps() and maps__machine() to reliably extract the recorded machine environment and e_machine for kernel and kallsyms maps, perfectly preventing silent, incorrect host fallbacks to uname() during cross-platform Capstone annotation sessions. At the same time, ensure all remaining uses of a map_symbol's thread pointer do not assume it is non-NULL to eliminate UI segmentation faults, and remove the fragile, redundant thread__get_arch() function to streamline the annotate and disassembly subsystem architecture. Fixes: 0e26ba5a8774 ("perf disasm: Refactor arch__find and initialization of arch structs") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f173b0c5e656181e8c56b116eff26fa6e75e2b4a Author: Ian Rogers Date: Wed Jul 22 21:59:46 2026 -0700 perf ui hists: In report UI ensure thread is set with reference counting [ Upstream commit ae89153d5e50d22e04a084829f74dc5a9ae6eb6d ] Populates the map_symbol thread in the UI code to fix the e_machine lookup for cross-platform disassembly when using the annotate action. At the same time, refactor the UI options and actions generation to comply with the perf subsystem's strict reference counting abstraction requirements for 'struct map_symbol' and 'struct thread'. Introduce explicit reference acquiring via map_symbol__copy() and thread__get() for menu items, safely clean them up between menu iterations using a new free_popup_actions() helper, and utilize insulated temporary action variables for direct hotkey handler execution. Fixes: 0e26ba5a8774 ("perf disasm: Refactor arch__find and initialization of arch structs") Reported-by: Josh Stone Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b5ea46ba8a953fe1ae601a5e4c99c7785403a8a3 Author: Alexandre Courbot Date: Thu Jul 23 15:54:46 2026 +0900 gpu: nova-core: fix packed registry table size [ Upstream commit 93b9511a3bba7f31d95502e5f912f0a476b0cf4a ] `PACKED_REGISTRY_TABLE::size` describes the entire table, including its fixed-size header. `SetRegistry` currently initializes it with only the variable payload length, omitting the 8 bytes header. Fix this by using `CommandToGsp::size` to obtain the actual command size, including its header. Fixes: 19b0a6e7c2be ("gpu: nova-core: gsp: Add SetRegistry command") Reported-by: Sashiko Closes: https://lore.kernel.org/r/20260722075253.B6DDB1F00A3D@smtp.kernel.org Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260723-nova-registry-size-fix-v1-1-8f471ba00ab4@nvidia.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 973e3c9087f97c11afc998ab05b08b7538503f50 Author: Zhi Wang Date: Wed Jul 1 09:26:20 2026 +0300 gpu: nova-core: build SetRegistry entries dynamically [ Upstream commit d85845b64c0020b2812243a22fa79d57cc1c1e38 ] The GSP SetRegistry command currently stores its registry entries in a fixed-size array. That makes every additional runtime-dependent registry object require reshaping the command data structure at the same time as the feature that needs the new entry. Keep the existing registry contents unchanged, but store them in a KVec so SetRegistry can be constructed dynamically. The constructor now returns a Result to propagate allocation failures while the command payload layout is still computed from the final entry list. Cc: Alexandre Courbot Signed-off-by: Zhi Wang Link: https://patch.msgid.link/20260701062622.3499033-7-zhiw@nvidia.com [acourbot: remove orphan comment.] Signed-off-by: Alexandre Courbot Stable-dep-of: 93b9511a3bba ("gpu: nova-core: fix packed registry table size") Signed-off-by: Sasha Levin commit 4d6270bbb4e083a4d2d39f3c36f30f5c939c06ed Author: Tejun Heo Date: Mon Jul 27 11:20:32 2026 -1000 sched_ext: Abort directly from the hardlockup handler [ Upstream commit 3c4b38064937a761ebbf85b1649e812db85eb59e ] scx_hardlockup() defers the abort to an irq_work because exit claiming used to take scx_sched_lock and couldn't run from NMI. The deferral is now unnecessary - claiming is NMI-safe and asserting ->aborting is exactly what breaks the live-locks that hard-lock CPUs. Call handle_lockup() directly and drop the irq_work. This also makes the self-detected case recoverable: the perf watchdog fires on the hard-locked CPU itself, where a queued irq_work never runs with IRQs off. Also fix the return value: %true used to be returned whenever sched_ext was loaded, suppressing the kernel's hardlockup report even when the abort was refused. Return %true only when this call initiated the abort. Fixes: bd2d76455b65 ("sched_ext: Defer scx_hardlockup() out of NMI") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit 30f4e6c8225ed8835d56ff7a3d95d108e946cb0b Author: Cheng-Yang Chou Date: Wed Jun 10 23:26:55 2026 +0800 sched_ext: Fix exit_cpu accuracy for lockup paths [ Upstream commit da428d572e07bb9dd2d076297ef5700f6483aafd ] handle_lockup() uses raw_smp_processor_id() for exit_cpu, which is wrong for two paths: - scx_hardlockup_irq_workfn() has the hung CPU in a local variable but irq_work may run elsewhere. Pass the local cpu explicitly. - scx_rcu_cpu_stall() records the detector CPU rather than the stalled one. Pass -1 for now. The next patch fixes this properly. Signed-off-by: Cheng-Yang Chou Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Stable-dep-of: 3c4b38064937 ("sched_ext: Abort directly from the hardlockup handler") Signed-off-by: Sasha Levin commit 7965965aa2828dbaac17f8f87de3324261e5e063 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 1cd16c8d68f58e54abb8f331d05469237200631f Author: Fan Wu Date: Sun Jul 19 01:00:13 2026 +0000 spi: oc-tiny: switch to managed controller allocation [ Upstream commit d710f43ce30975d197f73c543bfe47b958d8ba17 ] The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool. Fixes: ce792580ea2c ("spi: add OpenCores tiny SPI driver") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260719010014.3163356-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7069684d4bc68fd8447d1470691b9c7b1afaa39f Author: Myeonghun Pak Date: Wed Jun 24 15:23:55 2026 +0900 clk: mediatek: mt6735: Unregister PLLs on probe failure [ Upstream commit 935ad6242c47b37380d0cb7ec366516fe11855b4 ] mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while clk_mt6735_apmixed_remove() unregisters them on driver removal. If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds, probe returns the error directly and the remove callback is not run. This leaves the registered PLL clocks behind on the probe failure path. Unregister the PLLs in that failure branch before returning the error. Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers") 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 1c90da6376e47a73bb6bc808e71f63fe98d3673a Author: Manivannan Sadhasivam Date: Sat Jul 25 10:59:15 2026 +0200 PCI/pwrctrl: tc9563: Power off only the external ports in tc9563_pwrctrl_disable_port() [ Upstream commit e41bbfc4c109f2db741eef5cd0ac55600930c449 ] TC9563 supports powering off only the external facing ports like DSP1 and DSP2. It is not recommended to power off USP and DSP3 as they have fixed ports/endpoint connected. Fix tc9563_pwrctrl_disable_port() to power off only DSP1 and DSP2. Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Elder Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260725-tc9563-fix-v1-3-ec4286e31331@oss.qualcomm.com Signed-off-by: Sasha Levin commit 972c771674e88a43c8310c459ea30f0f0d0c168f Author: Manivannan Sadhasivam Date: Sat Jul 25 10:59:14 2026 +0200 PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node [ Upstream commit 6e5e6c2194b2acbded5b12ed80590d215b786d29 ] DSP3 has an integrated Ethernet MAC Endpoint which has its own set of config registers for configuring settings such as ASPM. The Endpoint device has two physical functions and those two functions share the same settings. Parse the Endpoint node under DSP3 instead of parsing both functions. The existing parsing logic also has one OOB issue as parsing both functions will result in accessing past the tc9563_pwrctrl->cfg array. Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Elder Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260725-tc9563-fix-v1-2-ec4286e31331@oss.qualcomm.com Signed-off-by: Sasha Levin commit 3371d30a97a257b7b5f2c8009612e9d452180f0a 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 16a56afd56c49bb8dac6b3582c077b6891785aa3 Author: Sumeet Pawnikar Date: Thu Jul 23 22:53:20 2026 +0530 powercap: intel_rapl_tpmi: Handle PMU registration failure during probe [ Upstream commit 9229916d59918ec9d3639e7263e1e97be638e361 ] intel_rapl_tpmi_probe() invokes rapl_package_add_pmu() but ignores its return value, so a PMU registration failure would leave the driver reporting probe success despite the PMU being absent, with no log trace. Since PMU registration is an optional auxiliary feature for perf energy counters, its failure should not break the primary powercap functionality. Check the return value and log a warning to ensure graceful degradation. Fixes: 963a9ad3c589 ("powercap: intel_rapl_tpmi: Enable PMU support") Signed-off-by: Sumeet Pawnikar [ rjw: Changed the log level of the new message to "info" ] Link: https://patch.msgid.link/20260723172321.5960-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 74d2066418412b6feeeb4520902e8e2815ded634 Author: Rakesh Kota Date: Fri Jul 24 16:30:24 2026 +0530 thermal/drivers/qcom-spmi-adc-tm5: Drop IIO_VAL_INT check in adc_tm5_get_temp [ Upstream commit 0c569e22020f53ddfac0099b0aa193907bfbcd6f ] Commit bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") fixed the iio_read_channel_processed_scale to return 0 on success instead of IIO_VAL_INT (1). The existing check in adc_tm5_get_temp() treated a successful return as an error because it expected IIO_VAL_INT. Drop the redundant `ret != IIO_VAL_INT` condition and rely solely on the negative error check. Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") Signed-off-by: Rakesh Kota Signed-off-by: Daniel Lezcano Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com Signed-off-by: Sasha Levin commit 82d250eb2a04b6d2d0f9e426d88b26e30bf8b894 Author: Christian Marangi Date: Thu Jul 2 11:48:30 2026 +0200 thermal/drivers/airoha: Fix copy paste error for sen internal [ Upstream commit 6791265d609549be55bb35b747c9648d0b570c12 ] In airoha_thermal_setup_monitor there is a copy paste error on configuring the internval for temp monitor. Fix the error and use the correct mask for the sen interval for the EN7581_TEMPMONCTL2 register. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi Signed-off-by: Daniel Lezcano Reviewed-by: Wayen Yan Link: https://patch.msgid.link/20260702094846.17325-3-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit bf7994d4d7f5ec80f9c6f3b5c28a69443aa5e5d3 Author: Christian Marangi Date: Thu Jul 2 11:48:29 2026 +0200 thermal/drivers/airoha: Fix copy paste error on clamp_t low temp [ Upstream commit 251621813fb4275e24431f9a0690aec9b15823e7 ] In airoha_thermal_set_trips, there is a copy paste error on clamping the value for the low trip temp point. Fix it to the correct value and actually clamp for the low variable. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi Signed-off-by: Daniel Lezcano Reviewed-by: Wayen Yan Link: https://patch.msgid.link/20260702094846.17325-2-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit 67332b75ca7ec05c4ba02a3813abeca8adff6ab3 Author: Rafael J. Wysocki Date: Thu Jul 23 13:16:03 2026 +0200 ACPI: bus: Avoid confusing complaints regarding missing _OSC features [ Upstream commit 9bfb23e0661be3d6a72aedde08a9f0fec2e8041a ] The platform firmware on some platforms sets OSC_CAPABILITIES_MASK_ERROR in _OSC error bits even though it actually acknowledges all of the requested features which after commit e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") causes the kernel to complain unnecessarily. Avoid the confusing complaints by explicitly checking for that case in acpi_osc_handshake(). Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") Signed-off-by: Rafael J. Wysocki Tested-by: Saverio Miroddi [ rjw: Fixed a typo in the new comment ] Link: https://patch.msgid.link/6315683.lOV4Wx5bFT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f917707f0de0832b8ab582391b1f64e549995c6c 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 093f290dd8790da22156b51a55c004c483808aa0 Author: Can Peng Date: Tue Jul 14 21:14:42 2026 +0800 crypto: keembay - publish OF module alias for OCS AES/SM4 [ Upstream commit 0a94091e29f914e4f233a208599ca4055882c01b ] The Keem Bay OCS AES/SM4 driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Although the match table lives in keembay-ocs-aes-core.o, that object is part of the composite keembay-ocs-aes module. Add the missing MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module alias information for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Signed-off-by: Can Peng Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5aae80dcec0748b4ed61daace2ad8b12082261f2 Author: Linmao Li Date: Tue Jul 14 11:30:15 2026 +0800 crypto: keembay - Initialize completion before requesting IRQ [ Upstream commit fce20289dd622cc7ab78d72c8a979a9f8b7cb10e ] kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Signed-off-by: Linmao Li Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2b3fb5693c25c21741f357a8c9d0e1f19b7e368f Author: Li Qiang Date: Fri Jul 17 23:39:13 2026 +0800 scsi: ufs: debugfs: Reserve space for a string terminator [ Upstream commit abd26e6b53c4169122d61fdd4cabe09bdd916aac ] ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL. Fixes: 7340faae9474 ("scsi: ufs: core: Add debugfs attributes for triggering the UFS EH") Signed-off-by: Li Qiang Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260717153914.26321-7-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cfef700703d98d3629159dcade27c695959ecf1c Author: Li Qiang Date: Fri Jul 17 23:39:11 2026 +0800 scsi: ufs: rpmb: Validate request frame length before parsing [ Upstream commit a947b8edbdcec8415a80ca55e9f38801322ffdd3 ] The RPMB core only verifies that request and response buffers are nonempty. This callback reads req_resp at the end of the first request frame before validating the request length. Require a complete frame before that access. Fixes: b06b8c421485 ("scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices") Signed-off-by: Li Qiang Reviewed-by: Peter Wang Reviewed-by: Bean Huo Link: https://patch.msgid.link/20260717153914.26321-5-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4b62f73836f4d037c9afd20c4c6084e4d44b3a57 Author: Li Qiang Date: Fri Jul 17 23:39:10 2026 +0800 scsi: ufs: core: Validate connected lane counts [ Upstream commit 9e6dd452f1affb5c412ca64bf5809ce9fde3174d ] The connected lane count is used by TX equalization code to index arrays sized by UFS_MAX_LANES. Reject zero and out-of-range RX or TX lane counts before they can be propagated. Fixes: 03e5d38e2f98 ("scsi: ufs: core: Add support for TX Equalization") Signed-off-by: Li Qiang Link: https://patch.msgid.link/20260717153914.26321-4-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a769095d1d74ebac2b1474c56bbd29bb0b9ed5a7 Author: Li Qiang Date: Fri Jul 17 23:39:09 2026 +0800 scsi: ufs: Avoid NULL CQE dereference when reporting invalid tags [ Upstream commit 331bda797e6afc143127ce72b1469d73316f49b4 ] The single-doorbell completion path can call ufshcd_compl_one_cqe() with a NULL CQE. If no command is associated with the completion tag, the warning message dereferences the CQE while reporting the error. Avoid that dereference and include the invalid tag in the warning. Fixes: 22089c218037 ("scsi: ufs: core: Optimize the hot path") Signed-off-by: Li Qiang Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260717153914.26321-3-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 66da25277256b6bf4c3fdbf3c9bfd43324c9cf25 Author: Li Qiang Date: Fri Jul 17 23:39:08 2026 +0800 scsi: ufs: core: Validate string descriptors [ Upstream commit d96e83d028d7d8762e424e49c671d49ac2ecf14f ] The string descriptor length includes a two-byte header while the UTF-16 payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code units, not bytes. Passing the payload byte count can make it read beyond the descriptor buffer. Validate that the payload has an even byte count, pass a code-unit count to the converter, and allocate sufficient UTF-8 output space. The raw string buffer starts after the descriptor header but its size is bLength. Copying bLength bytes from that pointer can read beyond the response buffer. Allocate a zeroed bLength-sized buffer and copy only the UTF-16 payload. This preserves the raw buffer size consumed by the RPMB device-ID ABI while avoiding the overread. Fixes: 4b828fe156a6 ("scsi: ufs: revamp string descriptor reading") Fixes: d794b499f948 ("scsi: ufs: core: fix incorrect buffer duplication in ufshcd_read_string_desc()") Signed-off-by: Li Qiang Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260717153914.26321-2-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f7f970bc705296ba1cb19c2e36eaf1af21cfb77c 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 d29a8ee271da17b5e32d7a76a9c78d43f66447ca Author: Kohei Enju Date: Wed Jul 15 21:28:50 2026 +0900 arm64: RSI: fix field-spanning write warning in attestation token init [ Upstream commit 221049874b6a78c7d87bc826581b0695cd338e2b ] The challenge is passed in registers a1 through a8. However, copying to ®s.a1 makes FORTIFY treat the destination as the single a1 field, resulting in a field-spanning write warning. [1] Overlay the SMCCC register structure with an RSI-specific argument layout and copy the challenge into an explicit 64-byte array. This keeps the existing a1-a8 argument encoding while giving the copy a correctly sized destination object. [1] memcpy: detected field-spanning write (size 64) of single field "®s.a1" at ./arch/arm64/include/asm/rsi_cmds.h:119 (size 8) WARNING: ./arch/arm64/include/asm/rsi_cmds.h:119 at rsi_attestation_token_init+0xdc/0xf8 [arm_cca_guest], CPU#0: cat/3314 Fixes: b880a80011f5 ("arm64: rsi: Add RSI definitions") Signed-off-by: Kohei Enju Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit df6bc642201d7c6b70582cd6ed9addb217298754 Author: Inochi Amaoto Date: Sun Jul 26 07:33:50 2026 +0800 riscv: dts: spacemit: Fix phy id check for the phy on com260 board [ Upstream commit 9db839d52ccd9af67d460cb9ac893276a74b88e5 ] Current phy framework can not re-initialize the phy correctly, as it will assert the phy reset GPIO so the phy id can not be read. Setting the phy id of board com260 manually so the phy id dectection can be skipped. Fixes: cfe5c91cb73c ("riscv: dts: spacemit: k3: Initial support for CoM260-IFX board") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260725233351.55004-3-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit a510644ce03e7157575845c3cb8a15e7e3513ad8 Author: Inochi Amaoto Date: Sun Jul 26 07:33:49 2026 +0800 riscv: dts: spacemit: Fix phy id check for the phy on pico-itx board [ Upstream commit 6d6536c880febe2340d8d388f42660eccff5aa81 ] Current phy framework can not re-initialize the phy correctly, as it will assert the phy reset GPIO so the phy id can not be read. Setting the phy id of board pico-itx manually so the phy id detection can be skipped. Fixes: 74657a376960 ("riscv: dts: spacemit: Add ethernet device for K3") Reported-by: E Shattow Reported-by: Inochi Amaoto Closes: https://lore.kernel.org/netdev/20260712045233.800748-1-inochiama@gmail.com Signed-off-by: Inochi Amaoto Tested-by: E Shattow Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260725233351.55004-2-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 9875c4587d651963594c1540972e021452cd9e6c Author: James Clark Date: Wed Jul 15 15:53:48 2026 +0100 tools/build: Allow versioning of all LLVM tools defined in Makefile.include [ Upstream commit d5a1d1270c898057afc5b51fb6d0f2defa89d56d ] The version of LLVM tools can be given on the build command with LLVM=-15, but this isn't applied to all tools. For example $(CC) gets versioned, but $(CLANG) doesn't. This causes a Perf build with LTO=1 to fail with an error about mixed clang versions: ld.lld: error: libperf/core.o: Unknown attribute kind (86) (Producer: 'LLVM18.1.8' Reader: 'LLVM 15.0.7') This file has two "ifneq ($(LLVM),)" blocks adjacent to each other, so merge these blocks making it obvious that all tools should be versioned consistently and there is nothing special about each block. This also reveals that ?= and "allow-override" are used inconsistently between the blocks. "allow-override" is technically only required for builtin variables, but isn't only used on them, and doesn't do any harm if used on a non-builtin. Make them all "allow-override" for consistency. The only functional difference this will cause is if there is a file level definition of one of the variables followed by an "#include of Makefile.include" which will now overwrite. But this isn't done and in a later commit some of the duplicate definitions will be removed for good measure. There are also some other LLVM tools that are not defined here and will be moved in a later commit. Signed-off-by: James Clark Reviewed-by: Ian Rogers Acked-by: Kumar Kartikeya Dwivedi Fixes: e9c281928c24 ("kbuild: Make $(LLVM) more flexible") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e06785cba7f86d72abd531058b1a82d6952a7346 Author: Justin Yeh Date: Thu Jul 23 11:58:13 2026 +0800 pinctrl: mediatek: free EINT resources on unbind [ Upstream commit 88292b7103d260e3e606eb3bb2794060a5fde48e ] mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind. Fixes: e46df235b4e6 ("pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit") Signed-off-by: Justin Yeh Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b8fa1098ee9f627d38bdf7c0ef6c1a6058a4165b Author: Justin Yeh Date: Thu Jul 23 11:58:12 2026 +0800 pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip [ Upstream commit 9c650317ba553d297f3fc5f0ae40ec53d86f9dab ] The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away. Fixes: a6df410d420a ("pinctrl: mediatek: Add Pinctrl/GPIO driver for mt8135.") Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the vendor dt-bindings") Fixes: e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that implements the generic pinctrl dt-bindings") Signed-off-by: Justin Yeh Reviewed-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 908f3ea3f050b865c5c2d8c1da566185a4a3efc0 Author: David Matlack Date: Thu May 28 17:41:40 2026 +0000 liveupdate: Remember FLB retrieve() status [ Upstream commit 5c4a03afcb21783987ffc64562b76ddd5a21b12b ] LUO keeps track of successful retrieve attempts on an FLB. It does so to avoid multiple retrievals of the same FLB. Multiple retrievals cause problems because once the FLB is retrieved, the serialized data structures are likely freed and the FLB is likely in a very different state from what the code expects. All this works well when retrieve succeeds. When it fails, luo_flb_retrieve_one() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. If the user attempts to retrieve another file registered with the same FLB, LUO will attempt to call the FLB's retrieve() callback again. The retry is problematic for much of the same reasons listed above. The FLB is likely in a very different state than what the retrieve logic normally expects (e.g. some KHO pages may have already been restored and freed). There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. This is done by changing the retrieved bool to a retrieve_status integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value. This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember retrieve() status") which did the same for LUO files. Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state") Assisted-by: Gemini:gemini-3-pro-preview Signed-off-by: David Matlack Reviewed-by: Pasha Tatashin Reviewed-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260528174140.1921129-3-dmatlack@google.com Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 217775362e805886dd1cdd584c435abc250abffb Author: David Matlack Date: Thu May 28 17:41:39 2026 +0000 liveupdate: Reference count outgoing FLB data [ Upstream commit 36882f3392395704c8a3fe7fac831fb6f5737e7d ] Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_outgoing() function so the caller can explicitly indicate when it is done using the outgoing FLB. During a Live Update, the kernel may need to fetch the outgoing FLB outside of the scope of a file handler's preserve() and unpreserve() callbacks. In that situation there is no way for the caller to protect itself against the outgoing FLB from being freed while it is using it. Incrementing the reference count in liveupdate_flb_get_outgoing() ensures it cannot be freed. This change also aligns the outgoing FLB lifecycle management with the incoming FLB, since the latter uses the same get/put semantics. Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state") Assisted-by: Gemini:gemini-3-pro-preview Signed-off-by: David Matlack Reviewed-by: Pasha Tatashin Link: https://patch.msgid.link/20260528174140.1921129-2-dmatlack@google.com Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit f2a3a52b82930c122167c3873bf04f001536a4ee Author: Jackie Liu Date: Thu Jul 16 09:26:07 2026 +0800 liveupdate: reject nonzero reserved value for SESSION_FINISH [ Upstream commit 05cf3d87a0bf23e328a7f7db488860fe14acc335 ] The UAPI documents liveupdate_session_finish::reserved as requiring zero, but luo_session_finish() currently ignores it and finishes the session. Accepting nonzero values prevents the field from being safely repurposed by a future extension. Reject nonzero reserved values before changing session state, matching LIVEUPDATE_SESSION_GET_NAME. Fixes: 16cec0d26521 ("liveupdate: luo_session: add ioctls for file preservation") Assisted-by: Codex:gpt-5.6-sol Reviewed-by: Pratyush Yadav (Google) Signed-off-by: Jackie Liu Link: https://patch.msgid.link/20260716012607.22020-2-liu.yun@linux.dev Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit dc59caae4d8f7c6cdeaf401f005829b185113596 Author: Inochi Amaoto Date: Fri Jul 10 14:33:13 2026 +0800 riscv: dts: spacemit: Add enough deassert time for the PHY on com260 board [ Upstream commit 12b0d602e8642297ec369eeb99366d37c8a3a120 ] RTL8211F require at least 50ms deassert to guarantee the register access, 10ms is only enough for the PHY reset. Fixes: cfe5c91cb73c ("riscv: dts: spacemit: k3: Initial support for CoM260-IFX board") Signed-off-by: Inochi Amaoto Link: https://patch.msgid.link/20260710063314.1030249-2-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit bf26fb05720ba6639e031f7e281a5eecfa99d919 Author: Inochi Amaoto Date: Fri Jul 10 14:33:12 2026 +0800 riscv: dts: spacemit: Add enough deassert time for the PHY on PICO ITX [ Upstream commit a225e19a4cc4e040ca0389cf0bbe209c23f5c92d ] RTL8211F require at least 50ms deassert to guarantee the register access, 10ms is only enough for the PHY reset. Fixes: 74657a376960 ("riscv: dts: spacemit: Add ethernet device for K3") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Tested-by: E Shattow Link: https://patch.msgid.link/20260710063314.1030249-1-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 56140bd357c5d533f48d60dfc5832dc7cd5962fa Author: Aurelien Jarno Date: Tue Jun 23 22:43:49 2026 +0200 riscv: dts: spacemit: improve RTL8211F PHY configuration on K3 Pico-ITX board [ Upstream commit e0c1145f4c8ea0515b32e0b9620412528a4312b1 ] Vendor kernel enabled ALDPS (Advanced Link Down Power Saving) on the RTL8211F PHY to save power when link down. Vendor kernel also disabled the 125MHz clkout clock signal, and indeed the schematics confirms that it only goes to a test point (TP14), so let's do the same. Signed-off-by: Aurelien Jarno Tested-by: Yixun Lan Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260623204431.498700-6-aurelien@aurel32.net Signed-off-by: Yixun Lan Stable-dep-of: a225e19a4cc4 ("riscv: dts: spacemit: Add enough deassert time for the PHY on PICO ITX") Signed-off-by: Sasha Levin commit 7c37d7cd2d0b5dbbea0812a41bbcdf4c66975bb4 Author: Shivendra Pratap Date: Fri Jul 24 18:46:04 2026 +0530 power: reset: reboot-mode: Remove devres based allocations [ Upstream commit 42326d59391cf287bf21224f3fdca528be31ece2 ] Devres APIs are intended for use in drivers, where the managed lifetime of resources is tied directly to the driver attach/detach cycle. To ensure correct lifetime handling, avoid using devres-based allocations in the reboot-mode and explicitly handle allocation and cleanup of resources. Fixes: cfaf0a90789a ("power: reset: reboot-mode: Expose sysfs for registered reboot_modes") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607191025.h6bQp891-lkp@intel.com/ Reviewed-by: Bartosz Golaszewski Signed-off-by: Shivendra Pratap Link: https://patch.msgid.link/20260724-arm-psci-system_reset2-vendor-reboots-v24-1-ed5125785ef6@oss.qualcomm.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8f7683ce37a53eeabd721941517341d2eef2cf3c Author: Alison Schofield Date: Fri Jul 24 15:28:01 2026 -0700 cxl/region: Fix use-after-free in find_pos_and_ways() error path [ Upstream commit 15da704b732332cc1e8f121f624e5e6c05124c5d ] The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported. Fixes: d90acdf49e18 ("cxl/region: Add a dev_err() on missing target list entries") Reviewed-by: Li Ming Reviewed-by: Jonathan Cameron Signed-off-by: Alison Schofield Link: https://patch.msgid.link/10deb519b543ef693ce23148b509a03fe1c07d0c.1784931354.git.alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit c44c01167aed2f38a88d3efd4318351f73f5655a Author: Julian Braha Date: Thu Jul 16 04:34:41 2026 +0100 pinctrl: fix unmet dependencies from missing GPIOLIB [ Upstream commit 46840fa8c9f53b9c90db4b4be2b808bbc626cde2 ] These 4 options, PINCTRL_PIC32, PINCTRL_PIC32, PINCTRL_IPROC_GPIO, and PINCTRL_NSP_GPIO all select GPIOLIB_IRQCHIP without ensuring GPIOLIB is enabled, causing unmet dependencies, such as: WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP Depends on [n]: GPIOLIB [=n] Selected by [y]: - PINCTRL_PIC32 [=y] && PINCTRL [=y] && OF [=y] && (MACH_PIC32 || COMPILE_TEST [=y]) Similar options in this subsystem select GPIOLIB, so let's do the same here. These unmet dependency bugs were found by kconfirm, a static analysis tool for Kconfig. Fixes: 2ba384e6c381 ("pinctrl: pinctrl-pic32: Add PIC32 pin control driver") Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver") Fixes: b64333ce769c ("pinctrl: cygnus: add gpio/pinconf driver") Fixes: 8bfcbbbcabe0 ("pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC") Signed-off-by: Julian Braha Reviewed-by: Arnd Bergmann Acked-by: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1a6e68cd6117410078ed4fd5b2e8af2d17f3184b Author: Feng Yang Date: Thu Jul 23 16:51:00 2026 +0800 selftests/bpf: Fix memory leak on subtest_states reallocation [ Upstream commit 06efb01c6530e9cfc247178cb96aa8adb3beaf61 ] Fix memory leak in subtest_states reallocation, and revert subtest_num if allocation fails. Fixes: 0925225956bb ("bpf/selftests: Add granular subtest output for prog_test") Signed-off-by: Feng Yang Link: https://lore.kernel.org/bpf/20260723085100.482147-6-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 3d83554653bb2198f4dfc5b19d3172e770ab98cd Author: Feng Yang Date: Thu Jul 23 16:50:58 2026 +0800 selftests/bpf: Fix missing allocation null checks in test_progs.c [ Upstream commit 12b362b2f06b283b7d8a2450f702f9b6a0f94aed ] Add null checks after memory allocations to prevent potential segmentation faults. Fixes: 79b453501310 ("tools/bpf: add a test for bpf_get_stack with tracepoint prog") Fixes: 0925225956bb ("bpf/selftests: Add granular subtest output for prog_test") Signed-off-by: Feng Yang Link: https://lore.kernel.org/bpf/20260723085100.482147-4-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 8d2b2adee3b94cd0f2d9df10812acbcc261c4ff1 Author: Feng Yang Date: Thu Jul 23 16:50:57 2026 +0800 selftests/bpf: Fix incorrect error checking for pthread_create [ Upstream commit b04b8d4e198aefc863e7b702ececb957845b0c25 ] pthread_create returns 0 on success and a positive error code on failure; it never returns a negative value. The current conditional branch can never be taken. Failures during thread creation are silently ignored, which will lead to invalid memory access when waiting on threads or dereferencing thread handles later. Fixes: 91b2c0afd00c ("selftests/bpf: Add parallelism to test_progs") Signed-off-by: Feng Yang Link: https://lore.kernel.org/bpf/20260723085100.482147-3-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 48a0209d8da0d90a7b0a0db19d1ff88027b13781 Author: Leon Hwang Date: Wed Jul 22 23:19:08 2026 +0800 bpf: Fix WARNING in bpf_tracing_link_release [ Upstream commit 61aaa8782bec59ecffd22e030f54ef9351bcabf9 ] The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier. 1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn. [ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [ 3.428793] bpf_link_free+0x58/0x130 [ 3.429293] bpf_link_release+0x23/0x30 Fix the warning by updating 'tr->flags' with '|=' and lock. Fixes: 2b5dcb31a19a ("bpf, x64: Fix tailcall infinite loop") Signed-off-by: Leon Hwang Reviewed-by: Pu Lehui Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20260722151909.69142-2-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 5de0acc36e233f3d540eaaceae8f1007008fb9ae 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 a2cbab47f44e9ea8c5a161ecba1b6bb8535771eb Author: Mykyta Yatsenko Date: Fri Jul 24 08:52:06 2026 -0700 bpf: Fix CFI mismatch in task work callback [ Upstream commit 2805abd089576799b15092949420e3f8ba97fabd ] BPF subprograms use the bpf_callback_t ABI, but task work invokes the callback through a three-argument function pointer. This trips kCFI. Store and invoke the callback as bpf_callback_t. Fixes: 38aa7003e369 ("bpf: task work scheduling kfuncs") Signed-off-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20260724-task_work_cfi-v1-1-2616691781ed@meta.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 843419e12402bb701b242483dbd534b3553f4f48 Author: Fabio Estevam Date: Tue Jul 21 10:54:50 2026 -0300 arm64: dts: rockchip: Fix rk3566-bigtreetech-cb2 touchscreen property [ Upstream commit 7707e4555cf1d52689621e3206df8ad2debaa0dd ] The TSC2007 driver uses the ti,max-rt property to specify the maximum touch resistance, but the rk3566-bigtreetech-cb2 device tree uses the undocumented ti,rt-thr property instead. As a result, the configured value is ignored and the driver falls back to its default maximum resistance value of 4095. Replace ti,rt-thr with ti,max-rt to preserve the intended resistance threshold of 3000. Fixes: bfbc663d2733 ("arm64: dts: rockchip: Add BigTreeTech CB2 and Pi2") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260721135450.45286-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 94987478c83e0afac41511be9d6f4e0d13adfec7 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 331fd2c8cd1e23d3056b8f7ec8692ec92621a48f Author: Damon Ding Date: Fri Jun 5 10:23:04 2026 +0800 arm64: dts: rockchip: Add missing hclk for RK3588 eDP1 [ Upstream commit 09820811c549ee2c408defe36b210b13c7a85fcf ] Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with corresponding clock-name "hclk". This clock is necessary for the eDP controller to access video output GRF and work properly. Previously the clock was enabled implicitly via GRF phandle reference. Add it explicitly now to align with updated binding. Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588") Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260605022305.3058853-3-damon.ding@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d506e4a1b179f90ff585b6d8ab047c49edfb8b45 Author: Damon Ding Date: Fri Jun 5 10:23:03 2026 +0800 arm64: dts: rockchip: Add missing hclk for RK3588 eDP0 [ Upstream commit ede2ee37f0a445cacbf24760f53befa10f64994a ] Add the required HCLK_VO1 bus clock to RK3588 eDP0 node with corresponding clock-name "hclk". This clock is necessary for the eDP controller to access video output GRF and work properly. Previously the clock was enabled implicitly via GRF phandle reference. Add it explicitly now to align with updated binding. Fixes: dc79d3d5e7c7 ("arm64: dts: rockchip: Add eDP0 node for RK3588") Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260605022305.3058853-2-damon.ding@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 24f20986b253c3e4eb13ebe3c2007d1d352408a6 Author: Namjae Jeon Date: Wed Jul 22 14:14:11 2026 +0900 exfat: fix valid_size extension over a shared writable mapping [ Upstream commit 1135704ed22f54873eb0498a232611d9eca30dd4 ] When a shared writable mapping has its valid_size extended by a buffered write or a page fault, exfat zeroes the page-cache gap below the new valid_size. A store through the mapping can race with this zeroing and be overwritten. Fix this by zeroing the gap lazily. Drop ->map_pages so that every first write fault goes through exfat_page_mkwrite(), which advances valid_size to cover the faulting page. With fault-around enabled, a store could install a writable PTE, skip ->page_mkwrite(), and land past valid_size without advancing it. Extending valid_size one faulting page at a time also leaves never-written pages in a large mapping alone. The gap is filled with block granularity, zeroing only the not-uptodate blocks and preserving blocks that may hold data stored through the mapping. On the buffered-write path the invalidate lock is held and the gap is unmapped before zeroing, so a racing store re-faults and, under the inode lock, completes only after the gap has been zeroed and valid_size covers it. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Co-developed-by: Yuezhang Mo Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8cb66c6579ab26e46a97fef5b9499815b8ddbe71 Author: Osama Abdelkader Date: Thu Jul 16 16:03:36 2026 +0200 drm/panthor: return PTR_ERR() from devm_drm_dev_alloc() [ Upstream commit abc1e559f8e5996eee506dfdc8e3781c2a1e04f9 ] devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe() always converts that failure to -ENOMEM. Preserve the actual error code returned by the DRM core instead. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com Signed-off-by: Sasha Levin commit 72caafbc95c5dca8266a942b8e96ad81d8d9adc7 Author: Weiming Wu Date: Wed Jun 10 19:57:25 2026 +0800 fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init [ Upstream commit 2064bc663f89e61b8681c1fb9d1ce445de72063d ] ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360) Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Wu Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c408d416618ebb8a95e3097a13f3b793ea9272ee 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 fdb1a59dfc8cf77678c74035c85fc783326a87ab 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 0b37120b0bb536426a8015d45db4c53bb35ed437 Author: Aaron Tomlin Date: Wed Jul 22 11:50:48 2026 -0400 perf trace: Correct default cpumask formatting to hexadecimal [ Upstream commit 89493fe58c81db19efc16ec220e6fce512ec1cf7 ] Currently, dynamic non-array fields such as 'cpumask_t' are mishandled in 'perf trace', causing the raw length and offset descriptors to be interpreted and displayed as a literal integer (e.g., "cpumask: 524320" instead of the actual mask data). Correct the parsing of dynamic fields that do not have the TEP_FIELD_IS_ARRAY flag set by introducing helper functions format_field__get_raw_data() and format_field__get_cpumask(). Using these helpers, resolve the pointer to the raw bits within the payload and format the cpumask as a zero-padded hexadecimal string by default. Fixes: c5e006cdbd27 ("perf trace: Support tracepoint dynamic char arrays") Signed-off-by: Aaron Tomlin Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8edcf5385ca711bfee2dfda1cd6049f45122c9d2 Author: Ian Rogers Date: Wed Jul 22 22:06:40 2026 -0700 perf cap: Remove used_root parameter and simplify capability checks [ Upstream commit 87ec3437f37b9fe44c524ba967cb12e78de06f15 ] Refactor perf_cap__capable() to completely remove the used_root out-parameter as requested by the maintainer. Relying on an explicit used_root boolean poisoned sequential capability checks (e.g. failing CAP_SYS_ADMIN checks poisoning the flag for subsequent CAP_PERFMON evaluations for unprivileged users) and created redundant complexity across check_ftrace_capable(), symbol__read_kptr_restrict(), and perf_event_paranoid_check(). Streamline the capability API to perform a pure true/false boolean evaluation. The function checks the Effective set using SYS_capget; if the syscall is missing or fails on legacy kernels, it cleanly falls back to checking EUID == 0. This perfectly preserves modern capability-aware host sessions, guarantees transparent fallback for older kernels, and correctly rejects privileged operations for containerized root processes that have explicitly dropped their capability bounding and permitted sets. Fixes: e25ebda78e23 ("perf cap: Tidy up and improve capability testing") Suggested-by: Namhyung Kim Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit aabd063d7987ce11907708313393a87d15971c52 Author: Troy Mitchell Date: Tue Jul 21 19:35:55 2026 -0700 ASoC: spacemit: rename clock inputs to match binding [ Upstream commit 4c69d04958ec87163ba826e2506babab37192e4b ] The driver requests the per-controller SSPA bus and functional clocks as "sspa_bus" and "sspa", but the device tree binding (spacemit,k1-i2s) specifies them as "bus" and "func". As a result, any DT written against the published binding fails to probe. There are currently no in-tree DT users referencing these names, so rename the clock inputs in the driver to match the binding rather than changing the binding. While at it, rename the matching struct member sspa_clk to func_clk for consistency with the new clock-names. Fixes: fce217449075 ("ASoC: spacemit: add i2s support for K1 SoC") Signed-off-by: Troy Mitchell Link: https://patch.msgid.link/20260721-kx-i2s-dts-v1-1-d22cb6cfaab5@linux.spacemit.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5b856fd4a76320321ad05e29ffc835d47ecca4a6 Author: Jerome Brunet Date: Thu Jul 23 11:39:51 2026 +0200 clk: sunxi-ng: mux: fix determine helper rate propagation [ Upstream commit 4bcba49984ff8c77729f003dd32082b10c02c23b ] Applying the pre divider on the parent rate is wrong because, while handling rate propagation through determine_rate(), the framework will likely round the parent rate again while cycling through the possibilities, throwing away the prediv applied. This means, the parent rate will then be wrong when the prediv is unapplied from a parent rate on which it was never applied to begin with. The right way to do it is to unapply the prediv from the requested rate, which is the wanted rate at the input on the clock element, and pass this to framework to do its thing. Change the determine rate mux helper in this way. Fixes: 1c8d7af61b37 ("clk: sunxi-ng: convert from divider_round_rate_parent() to divider_determine_rate()") Signed-off-by: Jerome Brunet Link: https://patch.msgid.link/20260723-a733-rtc-v7-1-8fd68aab94ae@baylibre.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 4eda2111b111ced5f9dd1802a0700d8b194a44a8 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 c2b4cd53bc6f3385143bf17f5508ebb6a8968ab3 Author: Malaya Kumar Rout Date: Sat Jul 11 20:22:45 2026 +0530 PM: hibernate: Fix memory leak in snapshot_write_next() error path [ Upstream commit 21d5c4cee31c5ce78f6decc7fafc7e7759af391f ] When memory_bm_create() succeeds for copy_bm but fails for zero_bm, the function returns without freeing the resources allocated for copy_bm. This results in a memory leak that includes radix tree nodes, zone structures, and page lists. Fix this by calling memory_bm_free() to release copy_bm's resources before returning the error code when zero_bm allocation fails. Fixes: 005e8dddd497 ("PM: hibernate: don't store zero pages in the image file") Signed-off-by: Malaya Kumar Rout Acked-by: Brian Geffon Link: https://patch.msgid.link/20260711145246.8625-1-malayarout91@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 334145d683ad3e31d052247f10807f2ebc950351 Author: Leon Romanovsky Date: Thu Jul 23 07:35:23 2026 -0400 RDMA/erdma: complete object teardown when the destroy command fails [ Upstream commit 652befcba956ef357f480525ccbe25c59bc81d4d ] erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Link: https://patch.msgid.link/20260722-b4-qp-and-cq-memory-are-leaked-if-the-d-v1-1-97e223dc1c96@nvidia.com Signed-off-by: Leon Romanovsky Acked-by: Cheng Xu Signed-off-by: Sasha Levin commit 56a347950e661c1a7f8f31c43a2ea53c2323b6f4 Author: Sanghyun Park Date: Wed Jul 22 16:28:38 2026 +0900 xfrm: Fix skb double-free in xfrm_dev_direct_output() [ Upstream commit 2aed51fc58d9ce450e2c116efb956160fd06fa02 ] A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume(). Fixes: 5eddd76ec2fd ("xfrm: fix tunnel mode TX datapath in packet offload mode") Signed-off-by: Sanghyun Park Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9562da57ff48384cc4612e7e65752e0ce64ec184 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 28bb9cb3134770b4ae6444c85b2b693764c55ebf 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 a8412fdcd0007b2e36d70edb6189208cba3d022e Author: Eliot Courtney Date: Fri Jul 3 19:22:13 2026 +0900 gpu: nova-core: correct RISC-V HALTED field [ Upstream commit 5557c238eb0f97169edda1d0776207e3d61f4f16 ] This uses the incorrect value, so update it. Fixes: bb58d1aee608 ("gpu: nova-core: falcon: Add support to check if RISC-V is active") Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-9-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 8f396ccaf128dc83e25b457cb099e7de1db7225e Author: Icenowy Zheng Date: Tue Jul 14 15:45:11 2026 +0800 riscv: dts: thead: th1520: remove pclk for I2C1 [ Upstream commit 5ed8cdb56cd90859e0c7f269b4a7c2b1571419b2 ] The I2C1 node added previously to the th1520.dtsi file has two clocks set -- one "ref" clock (CLK_I2C1) and one "pclk" (CLK_PERI_APB_PCLK). However, the CLK_I2C1 clock is just a clock gate with the CLK_PERI_APB_PCLK clock as its input. In addition, when it's gated, reading registers from the I2C controller returns fixed value (the last read value) for all registers. These facts indicate that the CLK_I2C1 clock is the true APB clock fed into the I2C controller instead of a dedicated reference clock. Leave only the CLK_I2C1 clock as the `clocks` property of the I2C1 device node and remove `clock-names` property, which represents the I2C controller only takes a single clock both as the APB clock and the reference clock. Fixes: 2f60e3516330 ("riscv: dts: thead: Add TH1520 I2C1 controller") Signed-off-by: Icenowy Zheng Reviewed-by: Drew Fustini Link: https://lore.kernel.org/r/20260714074515.1959352-2-zhengxingda@iscas.ac.cn Signed-off-by: Drew Fustini Signed-off-by: Sasha Levin commit e8a504606b9450de1291a3dbd9f53038fd33c1ed Author: Junhui Liu Date: Sun Jul 12 12:00:02 2026 +0800 riscv: dts: spacemit: k1: Split gmac_clk_ref into independent pinctrl groups [ Upstream commit 8270311d70fdf36bc8aab1e52b554e654a8839ff ] The gmac_clk_ref signal is optional for the GMAC controller and is not strictly required for all hardware designs. The pins for gmac0_clk_ref (GPIO 45) and gmac1_clk_ref (GPIO 46) may also be used as GPIOs for other functions even when the Ethernet controller is active. Split the refclk pins into independent pinctrl groups so boards can request them only when the reference clock path is actually needed. Among the already mainlined boards, BPI-F3, Jupiter and MusePi Pro have optional hardware paths for the GMAC refclk pins. BPI-F3 and Jupiter route both GMAC refclk pins to the PHYs through NC/0R option resistors, while MusePi Pro only does so for GMAC0. Keep referencing the new clk-ref pinctrl groups on these boards so the optional hardware paths remain usable if the option resistors are populated. OrangePi R2S has no publicly available schematic, so also keep the clk-ref groups there to preserve the previous pinmux behavior. Fixes: 60775f28cfb7 ("riscv: dts: spacemit: Add Ethernet support for K1") Signed-off-by: Junhui Liu Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260712-bpi-cm6-v3-2-8d1e2045179d@pigmoral.tech Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit da3066cee2c830bf58ec31b4ab0dc6441f06cb71 Author: Aurelien Jarno Date: Tue Jun 23 22:43:45 2026 +0200 riscv: dts: spacemit: set console baud rate on K3 Pico-ITX board [ Upstream commit 788ed93b3b85baa3b5817655ce621ff1f6c300e9 ] Because the default console's baud rate is not set, defconfig kernels do not have any serial output on this platform. Set the baud rate to 115200, matching what is used by U-Boot etc on this platform. Fixes: 7a6131804986 ("riscv: dts: spacemit: add K3 Pico-ITX board support") Signed-off-by: Aurelien Jarno Reviewed-by: Guodong Xu Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260623204431.498700-2-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 24f57e7c75b7e7af385cc13f171315c5bcaf6513 Author: Christophe Leroy (CS GROUP) Date: Thu Jul 9 13:40:06 2026 +0200 bitmap: Properly initialise destination bitmap for scatter & gather test [ Upstream commit 36f78b0dfa7df4892ba067ccf00d95a4513b4935 ] Erhard reports failure of bitmap tests on powerpc: test_bitmap: loaded. test_bitmap: [lib/test_bitmap.c:397] bitmaps contents differ: expected "1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99" test_bitmap: parselist('0-2047:128/256'): 912 test_bitmap: scnprintf("%*pbl", '0-32767'): 5977 test_bitmap: test_bitmap_read_perf: 1191082 test_bitmap: test_bitmap_write_perf: 1270153 test_bitmap: failed 1 out of 208655 tests It happens mainly when CONFIG_INIT_STACK_ALL_PATTERN is set. Commit 6b5a4b687367 ("bitmap: Add test for out-of-boundary modifications for scatter & gather") extended the test to out-of-boundary bits, but those bits were left uninitialised. Properly initialise the entire result bitmap before the test. [Yury: minor commit message tweaks] Reported-by: Erhard Furtner Closes: https://lore.kernel.org/all/ca3547ae-8b79-43a2-a758-23ec980bfd9a@mailbox.org Fixes: 6b5a4b687367 ("bitmap: Add test for out-of-boundary modifications for scatter & gather") Signed-off-by: Christophe Leroy (CS GROUP) Reviewed-by: Andy Shevchenko Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit 4520d4a1db37198756ad23568e36cdf091b6ffff Author: Sudeep Holla Date: Wed Jul 22 18:35:21 2026 +0100 firmware: arm_scmi: Unrequest devices if driver registration fails [ Upstream commit 9f7cd6a62aa754ed6b48cbd5d50de40add1bcc86 ] scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-2-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 826413b858ea2969e4c3e8197d0065efc47c6343 Author: Sudeep Holla Date: Wed Jul 22 18:35:20 2026 +0100 firmware: arm_scmi: Roll back partial protocol table registration [ Upstream commit 2224b622260ba590ab56ea1585d6bf7610be25b2 ] scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver. Fixes: 2858f6e5f064 ("firmware: arm_scmi: Add multiple protocols registration support") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f4ade8d224756ab69f108204dde6777bac4664e4 Author: EDAMAMEX Date: Wed May 20 16:02:11 2026 +0900 cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks [ Upstream commit 39c0cf62fc7851a17782e7efe8dfb2948739c681 ] cpufreq_cpu_get() returns NULL when no cpufreq policy is associated with the requested CPU, for example because the CPU is offline or the policy has already been torn down. Both amd_pstate_power_supply_notifier() and amd_pstate_profile_set() acquire a policy via cpufreq_cpu_get() and then pass that pointer to amd_pstate_get_balanced_epp() and amd_pstate_set_epp(), which dereference it unconditionally. A racing CPU hotplug or driver teardown can therefore lead to a NULL pointer dereference on either of these dynamic EPP paths. The third cpufreq_cpu_get() caller in this file, amd_pstate_verify(), already handles the NULL case. Bring the two new callers in line with that pattern: return NOTIFY_OK from the power-supply notifier (matching the other "nothing to do" exits) and -ENODEV from amd_pstate_profile_set() (the usual cpufreq error for a missing CPU policy). Found by code inspection; not tested on hardware. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Fixes: 798c47593cca ("cpufreq/amd-pstate: Add support for platform profile class") Signed-off-by: EDAMAMEX Link: https://lore.kernel.org/r/20260520070211.2753183-1-edame8080@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 54d63431854b50655b0c37500f7c43edc64e13fc Author: Marco Scardovi Date: Tue Jun 9 09:29:04 2026 +0200 cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems [ Upstream commit 9dfd13f80c856eab79130403a13fa3b83199346b ] On shared memory systems, the EPP configuration path (handled via cppc_set_epp_perf()) is responsible for toggling on the CPPC autonomous selection register (auto_sel). Currently, shmem_init_perf() returns early without doing any of the auto_sel configuration steps if cppc_state is AMD_PSTATE_ACTIVE. This skips enabling auto_sel, leaving the CPU in non-autonomous mode. Remove the early return check in shmem_init_perf() when cppc_state is AMD_PSTATE_ACTIVE. Toggling auto_sel is necessary for the active mode on shared memory systems to function based on the ACPI spec for CPPC v2 and below. Fixes: 2dd6d0ebf740 ("cpufreq: amd-pstate: Add guided autonomous mode") Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Signed-off-by: Marco Scardovi Reviewed-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260609073042.81275-3-scardracs@disroot.org Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit f15b9aa413078a2d417fb0e4b4a2a2d0abde1717 Author: Marco Scardovi Date: Tue Jun 9 09:29:03 2026 +0200 cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization [ Upstream commit 57476909c3000a04e84a1d6018d63ba1b2aa20ab ] Currently, the EPP getter helper functions (msr_get_epp, shmem_get_epp, and the static call wrapper amd_pstate_get_epp) return u8 or s16. This makes it difficult to correctly propagate negative error values returned by the underlying MSR read or CPPC helpers (such as rdmsrq_on_cpu or cppc_get_epp_perf). Modify the return type of these functions to int, allowing them to return negative error codes properly. Additionally, in amd_pstate_epp_cpu_init(), fetch the firmware-programmed default EPP value and validate it before assigning it to the EPP variables. If amd_pstate_get_epp() returns an error code, propagate the error and abort the CPU initialization to prevent subsequent configuration failures. Fixes: 555bbe67a622 ("cpufreq/amd-pstate: Convert all perf values to u8") Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Signed-off-by: Marco Scardovi Reviewed-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260609073042.81275-2-scardracs@disroot.org Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit ba6ce23d17db3d114adf13909a9002f1eedcf183 Author: Qianheng Peng Date: Thu Jul 16 16:51:39 2026 +0800 cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active [ Upstream commit 8d31bb1451643f328db0cea0e21e63ef54b4faf2 ] The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. Fixes: 14eb1c96e3a3 ("cpufreq: amd-pstate: Add test module for amd-pstate driver") Suggested-by: Li Xiong Suggested-by: Xibo Wang Signed-off-by: Qianheng Peng Reviewed-by: Zhongqiu Han Link: https://lore.kernel.org/r/1784191899-28957-1-git-send-email-pengqh1@chinatelecom.cn (ML: adjust title) Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 2f923ccc887150d67668f05bbca3c0d68c62f16a 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 09c7565ebdf64d11c4b61d8e90a31717ba573160 Author: Zhang Yi Date: Tue Jul 14 16:00:37 2026 +0800 ext4: skip tail block zeroing for inline data files [ Upstream commit 2fff82f081401a61a47e8171f6392d2b0cde5a30 ] ext4_block_zero_eof() is called from ext4_write_checks() on every append write beyond EOF. For inline data files, ext4_get_block() returns -ERANGE when ext4_load_tail_bh() looks up the tail block. However, this error is currently ignored because the return value of ext4_get_block() in ext4_load_tail_bh() is discarded. Before we fix ext4_load_tail_bh() to properly propagate the error, skip the zeroing for inline data inodes to avoid unnecessary failures or confusion. Fixes: 3f60efd65412d ("ext4: zero post-EOF partial block before appending write") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 83663c0b739480c00cfe785675db87520ec484ed Author: Xiang Mei Date: Thu Jul 9 11:41:01 2026 -0700 ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() [ Upstream commit c7e6b863d298f56522d0d08554bbea7f142e6588 ] For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected. Fixes: 471fbbea7ff7 ("ext4: handle casefolding with encryption") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Andreas Dilger Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260709184101.441348-1-xmei5@asu.edu Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e1e342d9a561c016b8531ec1f4dcefaad9d64954 Author: Guanghui Yang <3497809730@qq.com> Date: Thu Jul 9 14:41:51 2026 +0000 ext4: fix buffer_head leak in ext4_init_orphan_info [ Upstream commit 05704335803b69c1bfa8637b7ada942bf2ee8a41 ] ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path. Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Jan Kara Link: https://patch.msgid.link/tencent_B38798612A159E21450ECF959016371B0807@qq.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 518df61b9b0a5b288dfa72c87246045329c18b8c Author: Selvin Xavier Date: Tue Jul 21 04:54:40 2026 -0700 RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap [ Upstream commit 9b66c9af7172ffcf727214fa0ebe9a5e1ed6eb16 ] bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages. Fixes: ea222485788208 ("RDMA/bnxt_re: Update alloc_page uapi for pacing") Suggested-by: Yousef Alhouseen Signed-off-by: Selvin Xavier Link: https://patch.msgid.link/20260721115440.24021-5-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9ddbc95dac167e3f2d0e3859e6ce022ae0184fc1 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 9e6ec0977f0b9c16fc20efea050e3eea8f66e34b Author: Jeff Johnson Date: Thu Jul 16 13:01:11 2026 -0700 wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() [ Upstream commit 7698656a2f7b045af5a6859766238cefea1b1945 ] Currently, in ath12k_wmi_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. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260716-ath12k_wmi_op_rx-overread-v1-1-327a4b1c2372@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 919c31763d65dfcfca260bedfda76496cac38ed9 Author: Matthew Leach Date: Fri Jul 3 16:56:02 2026 +0100 wifi: ath12k: fix survey indexing across bands [ Upstream commit c42b27336eeffd7926a77604cdefcc8918bed926 ] When running 'iw dev wlan0 survey dump' the values for the channel busy time have the same sequence across bands. This is caused by indexing into the ath12k survey array using a band-local index rather than the global index passed by mac80211. This results in surveys for 5 GHz and 6 GHz channels returning values from 2.4 GHz slots, making the survey unusable on those bands. Further, there are redundant survey slots for multi-radio/single-phy instances. Fix by moving the survey data into ath12k_hw so multiple radios under a single wiphy share one table, and index into it using the global mac80211 index. A new spinlock in ath12k_hw serialises access to the survey array, which is now shared across all radios under a single hw. Band busy-times Before this fix: 2.4 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 5 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 6 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 After this fix, times are independent: 2.4 GHz: 23, 5, 5, 12, 2, 12, 26, 5, 3, 1, 27 5 GHz: 30, 40, 29, 27, 118, 118, 112, 120, 11, 11, 11 6 GHz: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 Tested-on: wcn7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy") Signed-off-by: Matthew Leach Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260703-ath12-survey-band-fix-v3-1-2fb050c2505a@collabora.com [fixed ath12k-check issues] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0fd2c54d8a56a968b40672b39047c15a12ef7786 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 84f87c46cec51f3cab536c840c978c4cfd67f3ad Author: Jeff Johnson Date: Mon Jul 13 09:15:49 2026 -0700 wifi: ath12k: Correctly copy the hint BSSID in WMI scan request [ Upstream commit 7b0bd40e97a00991122122d5888ae455fb2bfc7a ] Currently, in ath12k_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. Compile tested only. Reported-by: Baochen Qiang Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/ Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") 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-1-4ffc4a472992@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8d66010645bc99cb03fbc5c5570d42a34d53e33b Author: Aaradhana Sahu Date: Tue Jun 30 11:50:48 2026 +0530 wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region [ Upstream commit 42399be44b13eafb45c56b1c7d7c92107e50c289 ] Currently, the Q6 region contains a read-only firmware region along with the BDF_MEM_REGION_TYPE and HOST_DDR_REGION_TYPE memory areas. The firmware expects these writable memory regions to be assigned after the Q6 read-only section. However, the ath12k driver currently allocates the HOST_DDR_REGION_TYPE starting from the base of the Q6 region, which includes the read-only firmware area. As a result, the allocated memory regions overlap with the read-only section, causing the firmware to assert during QMI memory allocation. The Q6 memory region layout is as follows: Q6 Reserved Memory +--------------------------------------+ | | | Read-only Firmware Region | | (Q6 RO Region) | | | +--------------------------------------+ <--- bdf_addr_offset | Writable Memory Region | | (BDF + HOST_DDR allocations) | | | +--------------------------------------+ Fix this by allocating the required memory regions only after the end of the read-only region in the Q6 address space. The bdf_addr_offset parameter indicates where the writable region starts. Both HOST_DDR and BDF regions are allocated sequentially after this offset, with each region placed immediately after the previous one to avoid gaps and overlaps. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Fixes: 6757079c5890 ("wifi: ath12k: add support for fixed QMI firmware memory") Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-4-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 39520ff5cdfdff497bdfad9f4c52d6612dd02125 Author: Aaradhana Sahu Date: Tue Jun 30 11:50:47 2026 +0530 wifi: ath12k: refactor QMI memory assignment [ Upstream commit ecb517f97e629d3b8c360cbb5db3fed4d599ea2e ] ath12k_qmi_assign_target_mem_chunk() uses a large switch-case to handle both memory region identification and allocation for each memory request type, leading to redundant allocation logic. Refactor this by introducing ath12k_qmi_get_mem_reg_name() to map memory request types to their corresponding reserved memory region names. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-3-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: 42399be44b13 ("wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region") Signed-off-by: Sasha Levin commit c78e6912404ba04025828e7e1f2d66843ba7e81e Author: Aaradhana Sahu Date: Tue Jun 30 11:50:46 2026 +0530 wifi: ath12k: switch to name-based reserved memory lookup [ Upstream commit 3fe59edd1901c040e5b8e9d2428bf9ec6b4ce630 ] The driver currently retrieves reserved memory regions using index-based lookup, which depends on the ordering of reserved-memory nodes in the device tree. Since different platforms define these regions in varying orders and combinations, this approach is not compatible and can result in incorrect memory region access. Switch to looking up memory regions by name instead of index so it does not depend on node order. Use names already defined in qcom,ipq5332-wifi.yaml, so there are no backward compatibility issues. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: 42399be44b13 ("wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region") Signed-off-by: Sasha Levin commit 2f3635213ecf52ff943f01645f895cb39db8f0dc 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 f2dd3a8580dfdaf908d9d1ec54bd6777a44c6519 Author: Miaoqing Pan Date: Sat Jul 4 15:30:00 2026 +0800 wifi: ath12k: fix ML-STA authentication timeout on QCC2072 [ Upstream commit ff651212f2e237d790a5b36deef9d332360dc272 ] QCC2072 firmware interprets the MLO_LINK_ADD and MLO_START_AS_ACTIVE flags to control the link state during MLO vdev start. MLO_LINK_ADD indicates that a link is being added, while MLO_START_AS_ACTIVE specifies that the link should become active during the start. When an association link is added without setting MLO_START_AS_ACTIVE, the firmware may transition the link into a suspended state. In this case, authentication frames transmitted by the host can be dropped, leading to repeated authentication retries and eventual timeout, for example: wlp1s0: send auth to (try 1/3) wlp1s0: send auth to (try 2/3) wlp1s0: send auth to (try 3/3) wlp1s0: authentication with timed out Avoid triggering this behavior by setting the MLO_START_AS_ACTIVE flag when MLO_ASSOC_LINK is set, which tells the firmware that the current vdev must not enter suspend mode Note that this change relies on firmware behavior observed on the QCC2072 platform. The firmware on WCN7850 and QCN9274 does not use the MLO_START_AS_ACTIVE flag, so this change is effectively a no-op on those platforms Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: d8e1f4a19310 ("wifi: ath12k: enable QCC2072 support") Signed-off-by: Miaoqing Pan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260704073000.3300099-1-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 850211b0ba6ce9a305e2af2bd35b1c75c088ac32 Author: Manish Dharanenthiran Date: Tue Jun 23 11:16:21 2026 +0530 wifi: ath12k: advertise ieee_link_id in vdev start MLO params [ Upstream commit 784f7dabf5d3bce23c69c48a0441ff2b1536f069 ] Firmware builds the AP MLD partner profile from the hw_link_id passed in the vdev start parameters. However, hw_link_id is not always the same as the logical per-MLD ieee_link_id, since ieee_link_id is assigned per MLD and not per pdev. This matters in mixed MLO and SLO setups. For example: MLD 1 - 5 GHz + 6 GHz (2-link MLO): ieee_link_id 0 and 1 MLD 2 - 6 GHz only (1-link SLO): ieee_link_id 0 MLD 3 - 5 GHz only (1-link SLO): ieee_link_id 0 The same physical 6 GHz radio can use ieee_link_id 1 for one MLD and ieee_link_id 0 for another. Pass the correct ieee_link_id to firmware so it can build accurate per-STA profile elements. Add ieee_link_id to wmi_vdev_start_mlo_params for the self link and to wmi_partner_link_info for each partner link. Populate these fields in ath12k_mac_mlo_get_vdev_args() from the corresponding vdev link_id before encoding the WMI command. Introduce two new flags in ML params to indicate to firmware when the new fields are valid: ATH12K_WMI_FLAG_MLO_IEEE_LINK_IDX_VALID BIT(18) for the self link ATH12K_WMI_FLAG_MLO_IEEE_LINK_IDX_VALID_PARTNER BIT(19) for partner links Firmware parses ieee_link_id only when the matching flag is set. Also fix the debug message by using correct format specifiers and host-endian values instead of __le32 values. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Co-developed-by: Hari Naraayana Desikan Kannan Signed-off-by: Hari Naraayana Desikan Kannan Co-developed-by: Karthik M Signed-off-by: Karthik M Signed-off-by: Manish Dharanenthiran Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260623-ieee_link_id-v2-1-8a89d71baf58@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: ff651212f2e2 ("wifi: ath12k: fix ML-STA authentication timeout on QCC2072") Signed-off-by: Sasha Levin commit 1f77d0c58b6ab8ef3741cc876547db9c64fc0f95 Author: Tamizh Chelvam Raja Date: Wed Jul 1 23:54:28 2026 +0530 wifi: ath12k: Set IEEE80211_OFFLOAD_ENCAP_4ADDR after tx_encap_type vdev param [ Upstream commit be72d6aecea491ee202de81fc3a71c7ea9d34d2b ] Currently, IEEE80211_OFFLOAD_ENCAP_4ADDR is set when IEEE80211_OFFLOAD_ENCAP_ENABLED is present in vif->offload_flags at the beginning of ath12k_mac_update_vif_offload(). However, if the WMI vdev set_param for tx_encap_type fails, IEEE80211_OFFLOAD_ENCAP_ENABLED is cleared but IEEE80211_OFFLOAD_ENCAP_4ADDR remains set, leaving the flags in an inconsistent state. Fix this by setting IEEE80211_OFFLOAD_ENCAP_4ADDR only after the tx_encap_type has been configured via the WMI vdev set parameter. Compile tested only. Fixes: 729cad3c3c9e ("wifi: ath12k: Add 4-address mode support for eth offload") Signed-off-by: Tamizh Chelvam Raja Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260701182428.906441-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 2d3cb65c4846ff847bb4b8d8c58264434cc2ed8d Author: Tamizh Chelvam Raja Date: Tue Jun 23 15:35:01 2026 +0530 wifi: ath12k: Advertise multicast Ethernet encapsulation offload support [ Upstream commit e47d6c9bb4165721f61356f5fccae8f7dd78876b ] Advertise IEEE80211_OFFLOAD_ENCAP_MCAST to inform mac80211 that multicast frame encapsulation is handled in hardware. This allows mac80211 to pass Ethernet-formatted multicast frames directly to the driver. In ath12k_wifi7_mac_op_tx(), refine the logic that selects the MLO multicast replication path. Add a sta pointer check so that only unicast Hardware-encap frames use the direct transmit path, while multicast Hardware-encap frames fall through to the MLO replication loop and are transmitted on each active link. In the MLO replication loop, use skb_clone() for Hardware-encap frames. These frames are already in Ethernet format and do not require 802.11 link address rewriting by ath12k_mlo_mcast_update_tx_link_address(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Tamizh Chelvam Raja Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260623100501.2100119-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: be72d6aecea4 ("wifi: ath12k: Set IEEE80211_OFFLOAD_ENCAP_4ADDR after tx_encap_type vdev param") Signed-off-by: Sasha Levin commit b4c728577933753180e3e97f08424d5bcaff705e Author: Yao Kai Date: Mon Jul 6 12:13:13 2026 +0800 ext4: validate readdir offset before accessing dirent [ Upstream commit bc4b7b0414c33b2c8898eb04386df0d21a13dad8 ] A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary. Reported-by: syzbot+5322c5c260eb44d209ed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5322c5c260eb44d209ed Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Yao Kai Reviewed-by: Zhihao Cheng Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260706041313.708346-1-yaokai34@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 439aedfd7ae868d1d7b4930afe66091cb979cd5c Author: Aditya Prakash Srivastava Date: Fri Jul 3 04:54:12 2026 +0000 ext4: use fsdata to track inline data write state and fix race [ Upstream commit 7edbb323bab2b2a609016014caafdb651c898249 ] Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end helper accordingly. Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)). To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely. Reported-by: syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Fixes: 3fdcfb668fd7 ("ext4: add journalled write support for inline data") Suggested-by: Jan Kara Signed-off-by: Aditya Prakash Srivastava Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260703045414.1768-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 9fd3ffc3c51c9deaba99bd7b338fff2d08f52416 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 43ae387c3ae6a11227d096669ddf883e27a39a11 Author: Gerald Yang Date: Fri Jun 26 00:01:23 2026 +0800 ext4: clear stale xarray tags on folios skipped during writeback [ Upstream commit ec524aae479b4b2078c47492b90ec21200bce434 ] In data=journal mode, the writeback thread can hit the WARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the superblock is being remounted read-only during reboot: Workqueue: writeback wb_workfn (flush-253:0) RIP: 0010:ext4_journal_check_start+0x8b/0xd0 Call Trace: __ext4_journal_start_sb+0x3c/0x1e0 mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0 do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0 __writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 And followed by the warning: EXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263: comm (sd-umount): data will be lost This issue is not reproduced every time, but frequently. The reproduction step is to create a VM with 8 CPUs, 16G memory and setup data=journal: sudo tune2fs -o journal_data /dev/vda1 Run fio: rm -f fiotest fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8 --filename=fiotest --filesize=30G --group_reporting Reboot the VM, and check the console output from: virsh console testvm But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty but leaves tags PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which are only cleared by __folio_start_writeback. In data=journal mode, jbd2 checkpoints the journalled data to its final location and clears its own dirty flag without touching folio PG_dirty or xarray dirty flags. The commit f4a2b42e7891 ("ext4: fix stale xarray tags after writeback") fixes when PG_dirty is still set but there is no dirty page. Another case is PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE is still set. In this case, writeback thread checks clean folio and skips it in mpage_prepare_extent_to_map: if (!folio_test_dirty(folio) || ... folio_unlcok(folio); continue And never reaches ext4_bio_write_folio where the commit f4a2b42e7891 clears the stale xarray tags. Print debug logs after the filesystem is remounted read-only: writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 And all folios are actually clean: folio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... We need to clear the xarray stale tags for such clean folios by cycling them through writeback in the skip path, the same way f4a2b42e7891 does in ext4_bio_write_folio. Fixes: dff4ac75eeee ("ext4: move keep_towrite handling to ext4_bio_write_page()") Signed-off-by: Gerald Yang Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260625160127.162272-1-gerald.yang@canonical.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 7720fddd1fe344d14be258a2028f74ebf1569511 Author: Aditya Prakash Srivastava Date: Fri Jun 26 05:48:21 2026 +0000 ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find() [ Upstream commit 03438084a7b8621fb5c762dd3d04cff5f2630fb2 ] Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API. If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle. Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window. If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures. Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety. In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search. Suggested-by: Jan Kara Reported-by: Colin Ian King Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219283 Fixes: 0a46ef234756 ("ext4: do not create EA inode under buffer lock") Signed-off-by: Aditya Prakash Srivastava Tested-by: Colin Ian King Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260626054821.1729-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 169772cd2147c517be5cfda2710d17f8c90d6f10 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 b801158f81fe72b8fb6a8e05c8b11b9d6e32143a Author: Nicolin Chen Date: Mon Jun 15 12:45:33 2026 -0700 iommu/arm-smmu-v3: Declare eats_s1chk and eats_trans as host-endian u64 [ Upstream commit 4455286274474e95f223c68c215d32c864404889 ] arm_smmu_get_ste_update_safe() declares the eats_s1chk and eats_trans locals as __le64, but initializes them from FIELD_PREP(), which returns a host-endian value, and passes them through cpu_to_le64() at the use sites. Sparse reports the following warnings: >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1122:38: sparse: sparse: cast from restricted __le64 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1124:33: sparse: sparse: cast from restricted __le64 Declare both locals as u64 so the type matches FIELD_PREP() and the existing cpu_to_le64() at the use sites performs the host-to-little-endian conversion. No functional change. Fixes: 7cad80048595 ("iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence") Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202606151017.QU0evpH9-lkp@intel.com/ Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Reviewed-by: Jason Gunthorpe Reviewed-by: Pranjal Shrivastava Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 64e29e509906965f301f4e2593a5f6b9b4419cc2 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 e3e12b851953b279fa21c092242c620ce075e4d7 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 99d42aef089a07cfb1d404a7227ac9dc7628b497 Author: Li RongQing Date: Mon Jun 1 08:12:40 2026 -0400 iommu/amd: Fix undefined behavior in devid_write debugfs function [ Upstream commit 843e149989665f8309ad2efe6048dc76591e1f94 ] When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found. Fixes: 2e98940f123d9 ("iommu/amd: Add support for device id user input") Signed-off-by: Li RongQing Reviewed-by: Ankit Soni Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 21d35c5f46e99e9047bb9ded3ecb5ab440dd75b3 Author: Sudeep Holla Date: Wed Jul 22 10:52:50 2026 +0100 firmware: arm_scmi: Fix requested device removal race [ Upstream commit 2c4097e6c4aed276c5e9ec2ab331ab397ea780bf ] scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722095250.2011630-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit c06f2856a1d7e75a5ff247fc05224aa2452e7265 Author: Patrisious Haddad Date: Mon Jul 13 18:38:07 2026 +0300 RDMA/core: Fix potential use after free in ib_dealloc_pd_user() [ Upstream commit 8b90e701342275f414e36e7421c502237df241ad ] When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 91a7c58fce06 ("RDMA: Restore ability to fail on PD deallocate") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-8-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bfc119a40c04bbe3daad826f2160ccbfae6c64ce Author: Patrisious Haddad Date: Mon Jul 13 18:38:06 2026 +0300 RDMA/core: Fix potential use after free in uverbs_free_dmah() [ Upstream commit 2696626a0be5877f445fb647c25ef43930c777e6 ] When accessing a dmah via the netlink path the only synchronization mechanism for the said dmah is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of uverbs_free_dmah(), which is too late, since by that point vendor-specific resources associated with the dmah might already be freed. This can leave a short window where the dmah remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of uverbs_free_dmah(), ensuring that the dmah is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a dmah that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: d83edab562a4 ("RDMA/core: Introduce a DMAH object and its alloc/free APIs") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-7-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 43403fe45379c64fa6276e5a8ede44493e5d2d3d Author: Patrisious Haddad Date: Mon Jul 13 18:38:05 2026 +0300 RDMA/core: Fix potential use after free in ib_free_cq() [ Upstream commit 29dc2f8e1c97372c2871a70088707933515fbd5b ] When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. Fixes: 43d781b9fa56 ("RDMA: Allow fail of destroy CQ") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-6-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 64c72390d8407ea86de712a477c796b07d37abc4 Author: Patrisious Haddad Date: Mon Jul 13 18:38:04 2026 +0300 RDMA/core: Fix potential use after free in counter_release() [ Upstream commit 235ef2d0e750885c29340b0fc40620a7a4f52e12 ] When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction. Fixes: 99fa331dc862 ("RDMA/counter: Add "auto" configuration mode support") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-5-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 95c992c869df54a6a7061f5f3fb6400244f2af8f Author: Patrisious Haddad Date: Mon Jul 13 18:38:03 2026 +0300 RDMA/core: Fix potential use after free in ib_destroy_srq_user() [ Upstream commit 88244ecc71cc0b3ed200f5ef7ddea6686adfd730 ] When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 48f8a70e899f ("RDMA/restrack: Add support to get resource tracking for SRQ") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-4-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8a72a6aad84b3928dbb5e564bff1f56a7ec222ae Author: Patrisious Haddad Date: Mon Jul 13 18:38:02 2026 +0300 RDMA/core: Fix potential use after free in ib_destroy_cq_user() [ Upstream commit 3481bec4dfc4aee24ffea5a547ee95b70b67d9d5 ] When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 08f294a1524b ("RDMA/core: Add resource tracking for create and destroy CQs") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-3-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 001383248e5d754bbddb7ae2a8573bc8501c85d8 Author: Patrisious Haddad Date: Mon Jul 13 18:38:01 2026 +0300 RDMA/core: Fix use after free in ib_query_qp() [ Upstream commit 709ba0e5311bd034eb4d9c1c00cc4e1109d6dc3e ] When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-2-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 56024193f6d73f16dfd0fd5aa6ed439d6a2f9685 Author: Patrisious Haddad Date: Mon Jul 13 18:38:00 2026 +0300 RDMA/core: Add rdma_restrack_begin/abort/commit_del() operations [ Upstream commit 8d186210677c0322db886973bcec9aa4d21b51cd ] Add rdma_restrack_abort_del(), rdma_restrack_begin_del() and rdma_restrack_commit_del() functions to allow deleting a resource from the xarray to effectively prevent future access to it and wait for all current users to finish while preserving its index in the xarray to allow to re-insert it if needed with guaranteed success. This is a preparatory change for subsequent patches in the series which will use these functions to fix the cleanup flow. Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-1-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 709ba0e5311b ("RDMA/core: Fix use after free in ib_query_qp()") Signed-off-by: Sasha Levin commit 638b9a5364c1482e5d104823c1a3884b3d249484 Author: Leon Romanovsky Date: Tue Jul 21 18:00:01 2026 +0300 RDMA/mana_ib: drain QP references after partial table insertion [ Upstream commit 97f7c2262c28ebcae64fc957ee978646684a5ed9 ] mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference. Fixes: 8001e9257eca ("RDMA/mana_ib: extend mana QP table") Link: https://patch.msgid.link/20260721-if-mana-table-store-qp-qids-partiall-v1-1-8fb3d2d2b559@nvidia.com Reviewed-by: Konstantin Taranov Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 61a25b8d333e1eb2a189881d516f8d5194e26840 Author: Myeonghun Pak Date: Tue Jul 21 17:25:45 2026 +0900 RDMA/erdma: Fix CEQ tasklet use-after-free on removal [ Upstream commit 0ca79979384f031d710c4b3bae065dcb5d95aca3 ] Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers. Fixes: f2a0a630b953 ("RDMA/erdma: Add event queue implementation") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260721082545.47395-1-mhun512@gmail.com Acked-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3ec5f37e14bcbec0a6abe92c463c7613906f4e79 Author: Takuma Fujiwara Date: Tue Jul 21 10:57:43 2026 -0500 PCI: j721e: Fix incorrect max_lanes for J7200 [ Upstream commit 7147a7bfce47acd48c3738130bf0bd692bfd80de ] The PCIe Controller in the J7200 SoC supports a 4-lane configuration. However, j7200_pcie_rc_data and j7200_pcie_ep_data incorrectly set .max_lanes = 2, limiting operation to fewer lanes than the hardware supports. Set .max_lanes = 4 for both j7200_pcie_rc_data and j7200_pcie_ep_data to match the hardware capability. See J7200 Technical Reference Manual (SPRUIU1D), section 12.2.3.1.1 for further details: https://www.ti.com/lit/pdf/spruiu1d Fixes: 3ac7f14084f5 ("PCI: j721e: Add per platform maximum lane settings") Signed-off-by: Takuma Fujiwara Signed-off-by: Manivannan Sadhasivam Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20260721155743.3347659-1-t-fujiwara1@ti.com Signed-off-by: Sasha Levin commit 425addfb52c46dd8e481845895379fccfe49d250 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 641f814965d733936ca3618d4d5a12a8fa9be00e Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:30 2026 +0200 bpf: Mark bpf_refcount field as unique [ Upstream commit 61e655391cb19c31f94ecd4354f624c81ce4cf75 ] BPF_REFCOUNT is not marked as a unique field, while it should be. Fix this oversight. Fixes: d54730b50bae ("bpf: Introduce opaque bpf_refcount struct and add btf_record plumbing") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-4-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 373a1e9366e711b89bc5e45bd6edf33ef62402cd Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:29 2026 +0200 bpf: Preserve unique-field state across nested structs [ Upstream commit f08619f060468076e4acbdc10e0713af20d60e65 ] btf_find_struct_field() initializes a fresh seen mask for every recursive descent. Unique special fields in different levels of the same aggregate therefore do not see one another. The duplicate fields can reach btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A crafted user BTF can consequently trigger the warning before map creation checks capabilities. Initialize the seen mask once in btf_find_field() and pass the same pointer through struct, datasec, and nested-struct walks. This gives the entire field traversal one shared uniqueness state. Fixes: 64e8ee814819 ("bpf: look into the types of the fields of a struct type recursively.") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-3-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 92356df4aa2b044b62bc7e45e0d99231af147f29 Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:28 2026 +0200 bpf: Fix offset warn check for bpf_res_spin_lock [ Upstream commit 04e19012efaec2bfd8c3b37fd8a6c3f1fe731ffc ] Sashiko pointed out correctly that the case statement for BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK. Fix it by checking res_spin_lock_off instead. Fixes: 0de2046137f9 ("bpf: Implement verifier support for rqspinlock") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-2-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit a21001465264d58a787a97de5b220e721bf9b78e Author: Kohei Enju Date: Fri Jun 12 20:09:21 2026 +0900 virt: arm-cca-guest: use migrate_disable() for attestation token requests [ Upstream commit 24f55f511b9e1c19dc48d11bfe0dc60c86bdb376 ] The RSI attestation token init and continue calls must be issued from the same CPU. arm_cca_report_new() currently snapshots the CPU number and uses smp_call_function_single() to issue those calls on that CPU. With CONFIG_DEBUG_PREEMPT=y, the smp_processor_id() call used for the snapshot triggers a debug splat [0] because it runs in preemptible context. The snapshot does not pin the task to that CPU; it is only used to choose the target CPU for smp_call_function_single(), which can fail if that CPU is no longer available. Use migrate_disable() and issue the token init and continue operations directly, without the smp_call_function_single() callbacks. This keeps the token request sequence on the same CPU while preserving a sleepable context for the GFP_KERNEL allocations needed after the init call. [0] BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/264 caller is debug_smp_processor_id+0x20/0x30 CPU: 0 UID: 0 PID: 264 Comm: cca-workload-at Not tainted 7.1.0-rc1-00044-g55542ab273f2 #80 PREEMPT(lazy) Hardware name: linux,dummy-virt (DT) Call trace: [...] check_preemption_disabled+0xd8/0xf8 debug_smp_processor_id+0x20/0x30 arm_cca_report_new+0x48/0x278 tsm_report_read+0x154/0x1f8 tsm_report_outblob_read+0x20/0x38 configfs_bin_read_iter+0x118/0x208 vfs_read+0x220/0x318 [...] Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms") Signed-off-by: Kohei Enju Reviewed-by: Suzuki K Poulose Tested-by: Suzuki K Poulose Reviewed-by: Gavin Shan Reviewed-by: Steven Price Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2373496c0dac3a17c523efd3a79970412de07506 Author: Rafael J. Wysocki Date: Tue Jul 21 15:16:31 2026 +0200 ACPI: battery: Adjust charging status validation check [ Upstream commit 77ce4be0d8d53c528d1663ab62a14d93d5853f11 ] Commit bb1256e0ddc7 ("ACPI: battery: fix incorrect charging status when current is zero") added a charge rate check to validate the "charging" status of the battery, but that check is reported to cause some systems to misbehave [1]. Namely, it causes the "not charging" status to be reported on them while the battery is in fact charging (and they were correctly reporting the "charging" status in that case previously). To address that, check if the battery is full in addition to checking the charge rate when the "charging" status is reported by the platform firmware and only change it to "not charging" if the battery is full and its charge rate is zero or it is unknown. Fixes: bb1256e0ddc7 ("ACPI: battery: fix incorrect charging status when current is zero") Reported-by: golne tree Tested-by: golne tree Closes: https://lore.kernel.org/linux-acpi/AM9P193MB158895CFE0DDFA62FCD1DA5ED0F22@AM9P193MB1588.EURP193.PROD.OUTLOOK.COM/ [1] Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6286911.lOV4Wx5bFT@rafael.j.wysocki Signed-off-by: Sasha Levin commit 08fe2eaa609180c1baeb76c2629a9c82263b0427 Author: Feng Jiang Date: Mon Jul 20 06:42:57 2026 +0000 bpf, riscv: Fix extable handling for arena load_acquire [ Upstream commit 5eb8921371c6fd117d4a328b6053dfda38707df8 ] emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip. Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64") Suggested-by: Pu Lehui Signed-off-by: Feng Jiang Reviewed-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260720-bpf-riscv-fix-extable-v4-1-165c0b3b07d5@kylinos.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit a6e11a81da3420fd37f1518d4f238c4d5784086e Author: Pu Lehui Date: Wed Jul 8 06:44:33 2026 +0000 riscv, bpf: Fix kernel stack corruption in tailcall with CFI [ Upstream commit 52fb1756ea1d2759dfef2d86245be00b05dac3a2 ] When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption. Fixes: 30a59cc79754 ("riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled") Reported-by: Sashiko Signed-off-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260708064436.2971933-5-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 2a3a29e90021806ea00527f6458cfd2edb58b42a Author: Pu Lehui Date: Wed Jul 8 06:44:31 2026 +0000 riscv, bpf: Fix memory leak in bpf_jit_free [ Upstream commit 369e4635d04801f394d5bd42556f21029e95ff93 ] When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free(). Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Reported-by: Sashiko Signed-off-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260708064436.2971933-3-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 4c39115eb6e3010d001ecbcf54dcbe34b1f34b93 Author: Ricardo B. Marlière Date: Mon Jul 20 08:13:09 2026 -0300 libbpf: Search /lib64 and /lib in resolve_full_path() [ Upstream commit 7b5ae0481efdac040cea72b4fabd1398109f975b ] attach_probe/uprobe-lib and uprobe_autoattach selftests fail with "failed to resolve full path for libc.so.6" on older non-usrmerged distros, where libc.so.6 lives under a top-level /lib64 or /lib rather than /usr/lib64 or /usr/lib. Add /lib64:/lib to the search paths, alongside the existing /usr/lib64:/usr/lib and Debian multiarch entries. Fixes: 1ce3a60e3c28 ("libbpf: auto-resolve programs/libraries when necessary for uprobes") Signed-off-by: Ricardo B. Marlière Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-3-b450eda93dfe@suse.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 0e94a2ca7905b3583e52441c58579e5d3b58f340 Author: Ricardo B. Marlière Date: Mon Jul 20 08:13:08 2026 -0300 selftests/bpf: Fix lsm_bdev dev_t encoding mismatch [ Upstream commit 71cf3f3275e5f4d7f31bd540608c80535343b427 ] progs/lsm_bdev.c keys its verity_devices hashmap with the raw kernel dev_t read straight off bdev->bd_dev, i.e. MKDEV(major, minor) = (major << 20) | minor. prog_tests/lsm_bdev.c instead builds its lookup key with dev_key = (__u32)st.st_rdev from stat(2), but the stat(2) syscall fills st_rdev via the kernel's new_encode_dev(), a different bit layout: (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12). For any device with a non-trivial major these two values differ, so the lookup can never find what the BPF program stored, and test_lsm_bdev() always fails with: test_lsm_bdev:FAIL:map lookup unexpected error: -2 (errno 2) Reconstruct the raw kernel dev_t from the decoded major/minor instead of casting st_rdev directly, restoring the layout the BPF program actually reads. Fixes: 96f4c251a087 ("selftests/bpf: add block device management selftests") Signed-off-by: Ricardo B. Marlière Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-2-b450eda93dfe@suse.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 912189169df3f923654b5148ad6a1d168244e972 Author: Ricardo B. Marlière Date: Mon Jul 20 08:13:07 2026 -0300 selftests/bpf: Fix make install target [ Upstream commit 0b236ac75d04a235f3574a2208941b22c1e7a965 ] After "make install", test_progs fails because two files end up in the wrong place: - bpftool: TEST_GEN_PROGS_EXTENDED flattens it into $(INSTALL_PATH), losing the tools/sbin/ prefix that detect_bpftool_path() expects. Remove it from TEST_GEN_PROGS_EXTENDED and install it explicitly under tools/sbin/ instead. - *.BTF: resolve_btfids writes resolve_btfids.test.o.BTF as a side-effect of the build but INSTALL_RULE never copies it over. Install all *.BTF files alongside the rest of the per-flavor output. Fixes: f21fae577446 ("selftests/bpf: Add a few helpers for bpftool testing") Fixes: 522397d05e7d ("resolve_btfids: Change in-place update with raw binary output") Signed-off-by: Ricardo B. Marlière Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-1-b450eda93dfe@suse.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e2396b8a562073787e627a5f483f1bc5c452fa6a Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 14:54:18 2026 +0200 bpf: Zero queue and stack outputs on lock failure [ Upstream commit 7ac6e1ae41a09f1dd4baeeff1d028ae49ee01232 ] Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it. Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call. Fixes: a34a9f1a19af ("bpf: Avoid deadlock when using queue and stack maps from NMI") Signed-off-by: Kumar Kartikeya Dwivedi Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260719125419.1782196-1-memxor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 27a3be4e965bfac88e35dd17ec3097a6f5ee637e Author: Yousef Alhouseen Date: Wed Jul 1 18:42:04 2026 +0200 platform/x86: acer-wmi: reject missing gaming WMI results [ Upstream commit caf8342512c3056005f475d350eeca089c3c6623 ] WMI_gaming_execute_u32_u64() returns success when firmware supplies no output object, leaving the caller output untouched. Gaming getters then inspect an uninitialized result value. When the caller requests an output value, return -ENOMSG if firmware supplies no object. Preserve a NULL output pointer as the supported way for callers to ignore the result. Fixes: 2d76708c2221 ("platform/x86: acer-wmi: use WMI calls for platform profile handling") Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2fb8ff81659a57c42bb7b49e8339a2be2a318ef8 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 36bf17bb90cdf7a623499b624b05acde4d2feef5 Author: Xiang Mei Date: Mon Jun 15 12:05:19 2026 -0700 ext4: fix out-of-bounds read in ext4_read_inline_dir() [ Upstream commit 9333cc809f0a89e001b814155a6cb8903a6274df ] ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: dir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dir_buf + pos - extra_offset", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer. Fixes: c4d8b0235aa9 ("ext4: fix readdir error in case inline_data+^dir_index.") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260615190519.946736-1-xmei5@asu.edu Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 32f7ab52875ec7f800ca67e7176e5743a84baddf Author: Yun Zhou Date: Fri Jun 12 08:53:30 2026 +0800 ext4: fix circular lock dependency in ext4_ext_migrate [ Upstream commit a897682793eba5de51ee6f3152760374afa629cf ] Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a circular lock dependency between s_writepages_rwsem and sb_internal (freeze protection). The deadlock scenario: CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount) ---- ---- ext4_ext_migrate() ext4_writepages_down_write() s_writepages_rwsem (write) ext4_evict_inode() sb_start_intwrite() [sb_internal] ... ext4_writepages() s_writepages_rwsem (read) [BLOCKED] iput(tmp_inode) ext4_evict_inode() sb_start_intwrite() [BLOCKED] The tmp_inode is a temporary inode with nlink=0 created solely for building the extent tree. Its eviction does not require s_writepages_rwsem protection, so deferring iput() until after releasing the rwsem is safe. Reported-by: syzbot+212e8f62790f8e0bc63b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=212e8f62790f8e0bc63b Fixes: cb85f4d23f79 ("ext4: fix race between writepages and enabling EXT4_EXTENTS_FL") Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260612005330.1930804-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6e11ac626f9f9fc3a2ed27dfa44ccbe5fb762217 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 355bee5f11acb116cd256588631b4028ca562646 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 2267448f67874cdfa70a04400da79e66572f98cc Author: Zhu Ling Date: Wed Jul 15 09:25:19 2026 +0800 ACPI: EC: Avoid _REG disconnect on GPIO IRQ defer [ Upstream commit e71bdbce27dcaa7f467a3a198cbe723924f05569 ] EC event delivery uses either a GPE or, on ACPI reduced hardware platforms, a GpioInt resource. The GPE path does not have a provider lookup that can defer, but acpi_dev_gpio_irq_get() can return -EPROBE_DEFER for the GpioInt path. ec_install_handlers() currently installs the EC address space handler and executes _REG before looking up the GPIO IRQ. If the GPIO lookup then defers, acpi_ec_setup() tears the handlers down again. Removing the EC address space handler causes ACPICA to execute _REG for disconnect, so firmware may observe an EC OpRegion connected -> disconnected transition during one failed probe attempt. This is observable when the namespace EC reuses a boot EC that has already installed the EC address space handler. A deferred namespace EC probe can disconnect the already usable boot EC OpRegion until a later reprobe connects it again. AML that gates EC field accesses on _REG state can then return fallback values to other drivers during that window. Prepare the GPIOInt IRQ before publishing EC OpRegion availability to AML. This leaves the GPE path unchanged, keeps non-deferred GPIO lookup errors non-fatal as before, and still lets the existing acpi_ec_setup() error path clean up real handler installation failures. Fixes: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Zhu Ling [ rjw: Added an empty code line after a conditional ] Link: https://patch.msgid.link/20260715012556.12043-1-zhuling2709@phytium.com.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c57e238b475e8e1e514499772b8c0db5768be93f Author: Pengpeng Hou Date: Mon Jul 20 19:49:18 2026 +0800 RDMA/nldev: validate dynamic counter attribute length [ Upstream commit 74f49255492a62658f36bf2578d7916f1c6ffad1 ] RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it. Fixes: 3c3c1f141639 ("RDMA/nldev: Allow optional-counter status configuration through RDMA netlink") Reviewed-by: Zhu Yanjun Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260720114918.70323-1-pengpeng@iscas.ac.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d324c4353f64190a032c78d6e07be6d57ddfb2f1 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 bf18426dddbf3ed50294a2547949c7856403f74c Author: Gary Guo Date: Thu Jul 16 15:41:43 2026 +0100 samples: rust: debugfs: fix excessive stack use [ Upstream commit f5256ad60651fc010e2cf6dc7fe195415f496fc9 ] The current implementation creates a 4K array and move it into the box. Klint reports that this causes excesssive stack usage: warning: stack size of `create_file_write` is 4472 bytes, exceeds the 2048-byte limit --> samples/rust/rust_debugfs_scoped.rs:54:1 | 54 | / fn create_file_write( 55 | | mod_data: &ModuleData, 56 | | reader: &mut kernel::uaccess::UserSliceReader, 57 | | ) -> Result { | |___________^ | = note: the stack size is inferred from instruction `sub $0x1178,%rsp` at .text+2205 Use pin-init to create the array in-place instead. Fixes: f656279afde1 ("samples: rust: debugfs_scoped: add example for blobs") Signed-off-by: Gary Guo Reviewed-by: Alexandre Courbot Link: https://patch.msgid.link/20260716144144.3665719-1-gary@kernel.org [ Make the patch rustfmtcheck complient. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 5a9f8b7f11674339b3859b5889179fa8bb7d376c Author: Gary Guo Date: Mon Jul 13 21:14:54 2026 +0100 rust: device: make lifetime on `Core` and `CoreInternal` invariant [ Upstream commit f7acb19abcd867e5d2e1feb6197dcc65aa3b8e45 ] Currently the lifetime on `Core` and `CoreInternal` is covariant. This means that they can be coerced into shorter living lifetimes. On `probe` function, signature has `&'bound Device>`; the type's wellformness would imply `'a: 'bound` and thus the type can be coerced `&'bound Device>`, defeating the purpose of having the lifetime bound to prevent users of the `Core` type to escape the function. Fix this by making the lifetime invariant, so the coercion is impossible. The lifetime here only needs to be "branded" so it does not coerce or unify with other lifetimes, so we do not need to ensure `'bound: 'a`. This requires modifying `nova-core` which relies on this implied bound due to pre-2024 capture rule. The "use" bound can be removed if built with edition 2024. Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized") Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org [ Fixup the debugfs sample to use an explicit lifetime instead of Core<'_>. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 082435d51f2867d80fe285f2bd45b5d37a31006a Author: Viktor Malik Date: Wed Jul 15 13:22:03 2026 +0200 selftests/bpf: Silence maybe-uninitialized compiler warning in libarena [ Upstream commit 5763790965eb3414148720f030b20fd5ccc438ca ] When compiling BPF selftests with -O2, GCC reports a maybe-uninitialized warning in libarena code: In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:11: In function ‘libarena_asan_init’, inlined from ‘run_test’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:59:8, inlined from ‘test_libarena_asan’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:91:2: /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:126:14: error: ‘globals_pages’ may be used uninitialized [-Werror=maybe-uninitialized] 126 | args = (struct asan_init_args){ | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ 127 | .arena_all_pages = arena_all_pages, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 128 | .arena_globals_pages = globals_pages, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 129 | }; | ~ /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h: In function ‘test_libarena_asan’: /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:118:13: note: ‘globals_pages’ was declared here 118 | u64 globals_pages; | ^~~~~~~~~~~~~ Silence the warning by initializing globals_pages to 0. Fixes: cfc00618b9df ("selftests/bpf: Add ASAN support for libarena selftests") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/9f77a5c05c3c731ab2655fd66716ab9de4478b15.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 555e689c46308c6f5e212ecea7a3b59ac9360404 Author: Viktor Malik Date: Wed Jul 15 13:22:02 2026 +0200 selftests/bpf: Silence array bounds warning in global_map_resize [ Upstream commit dcd164ec67f89e0db5ee025ee9e91280052eb737 ] When compiling BPF selftests with -O2, GCC reports an array bounds violation warning in global_map_resize test: In function ‘global_map_resize_bss_subtest’, inlined from ‘test_global_map_resize’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:228:3: /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:64:33: error: array subscript 1 is above array bounds of ‘int[1]’ [-Werror=array-bounds=] 64 | skel->bss->array[i] = 1; | ~~~~~~~~~~~~~~~~^~~ In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:6: ./test_global_map_resize.skel.h: In function ‘test_global_map_resize’: ./test_global_map_resize.skel.h:44:21: note: while referencing ‘array’ 44 | int array[1]; | ^~~~~ This is a false positive because `array` (a BPF map) has been resized from within the BPF program. GCC doesn't know that so let us silence the warning by accessing the array via a plain pointer. Fixes: 08b089567573 ("libbpf: Selftests for resizing datasec maps") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/57765bc465a27923c3c093eba222cc24d08d8c40.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 0fb8a607653196148c4f6a9d9258c7409f358ac4 Author: Viktor Malik Date: Wed Jul 15 13:22:01 2026 +0200 selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256 [ Upstream commit eb5cd154f174f42079a45f4bd7ee8bc20f2ba6f3 ] Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the result of malloc. It is more accurate since malloc returns NULL, not an error code, on failure and it also prevents the following false GCC warning when compiling BPF selftests with -O2: In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:4: /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c: In function ‘test_sha256’: ./test_progs.h:393:22: error: ‘data’ may be used uninitialized [-Werror=maybe-uninitialized] 393 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:28:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 28 | if (!ASSERT_OK_PTR(data, "malloc")) | ^~~~~~~~~~~~~ In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32, from ./test_progs.h:37: /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Fixes: f09f57c74677 ("selftests/bpf: Add test for libbpf_sha256()") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/f9dec09cca0c2aa5eeb4fdcd400a13aa19e2c073.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 05e588ad77154fbe0925ddb1ab598f003aa6ffb4 Author: Viktor Malik Date: Wed Jul 15 13:22:00 2026 +0200 selftests/bpf: Check malloc result with ASSERT_NEQ in test_loader [ Upstream commit 40f986aed81ff4d137ec101c6babbbc642690eac ] Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the result of malloc. It is more accurate since malloc returns NULL, not an error code, on failure and it also prevents the following false GCC warning when compiling BPF selftests with -O2: In file included from test_loader.c:6: test_loader.c: In function ‘verify_stderr’: /bpf-next/tools/testing/selftests/bpf/test_progs.h:393:22: error: ‘buf’ may be used uninitialized [-Werror=maybe-uninitialized] 393 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ test_loader.c:810:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 810 | if (!ASSERT_OK_PTR(buf, "malloc")) | ^~~~~~~~~~~~~ In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32, from /bpf-next/tools/testing/selftests/bpf/test_progs.h:37: /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Fixes: 554e4eb9e4b7 ("selftests/bpf: Reuse stderr parsing for libarena ASAN tests") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/e25d50805fbcb3632f24b488568ab5ba49b82094.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit af33d192af2fb88aa71e8909ab22d787b29d04c7 Author: Pawan Gupta Date: Wed Jul 8 11:40:14 2026 -0700 x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist [ Upstream commit a4c714fe9746bf5a434bb798b26ebba278b798c1 ] Thomas Gleixner pointed out that cpu-type is a per-CPU property while hybrid is a system property; conflating the two in the CPU matching infrastructure is wrong. Currently, on a hybrid system x86_match_cpu() matches any cpu-type. This works if the intent is to find the possibility of a cpu-type in a system. But fails if matching for the cpu-type of a given CPU. Borislav posted a cleanup here: https://lore.kernel.org/all/20260703193222.GFakgORjvxwnZTPRnI@fat_crate.local To make way for the cleanup stop matching cpu-type in cpu_vuln_blacklist. RFDS is the only user, so drop the VULNBL_INTEL_TYPE entries and fold their RFDS bit into the base Alder Lake (0x97) and Raptor Lake (0xB7) blacklist entries. For now open-code cpu-type check in vulnerable_to_rfds(). In the future, if more vulnerabilities need cpu-type matching a helper can be added. No functional change intended. Fixes: 722fa0dba74f ("x86/rfds: Exclude P-only parts from the RFDS affected list") Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260708-cpu-type-vuln-v1-1-85c1d3c704db@linux.intel.com Signed-off-by: Sasha Levin commit b86e65df16da08316b6009434bfc5a84e3f51ffa Author: Frank Li Date: Thu Jul 9 16:29:46 2026 -0400 arm64: dts: imx8-ss-audio: Fix LPCG clock indices for ASRC0 [ Upstream commit 8563591f76ca02c1a6fd70ce986df1d0dde8d249 ] The LPCG clock indices for ASRC0 and AUD_PLL_DIV0 are swapped. The ASRC0 LPCG provides only IMX_LPCG_CLK_4, so update the ASRC0 clock consumer to use IMX_LPCG_CLK_4 instead of the non-existent IMX_LPCG_CLK_0. Likewise, the AUD_PLL_DIV0 LPCG provides only IMX_LPCG_CLK_0, so update its clock consumer to use IMX_LPCG_CLK_0 instead of the non-existent IMX_LPCG_CLK_4. Fixes: 5125617c7a4d3 ("arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif0 and sai[4,5]") Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit cb6b14e24b9922384e5270f8c4cda9b3997b5791 Author: Marco Elver Date: Mon Jul 20 18:08:22 2026 +0200 kcsan: avoid unintended access checking in NMIs [ Upstream commit a8488ecbd7ba44d65b912dfe88a73f438eba2447 ] If a watcher deliberately disables interrupts (either by user choice, or because we're dealing with a scoped reordered access) to avoid detecting any data races in interrupts, NMIs are still able to fire. When we set up a watchpoint on a scoped reordered access, we disabled interrupts because the same CPU cannot observe reordering of its own accesses. To ensure we observe no false positives from NMIs, disable access checking for interrupt contexts as well. Fixes: 69562e4983d9 ("kcsan: Add core support for a subset of weak memory modeling") Signed-off-by: Marco Elver Signed-off-by: Sasha Levin commit bd02d644bd19a2795c018635d273d91e45d2bb95 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 c5643ea4f040acc2f4d1e88f49bd0be51110ff2f Author: Leon Romanovsky Date: Tue Jul 14 13:50:00 2026 +0300 RDMA/bnxt_re: Validate udata before executing commands [ Upstream commit d38c835925d4a3bfdf0a85ff2829ee90c709c561 ] The destroy callbacks currently zero the udata output after tearing down driver resources. If the userspace access fails, uverbs preserves the uobject and allows the destroy callback to run again, even though the driver resource has already been freed. Call ib_no_udata_io() before teardown so udata failures are detected while the resource is still intact, then return success after teardown completes. As part of this change, move ib_respond_empty_udata() to the start of the create and modify flows. While this is not strictly required for general create flows, as the core layer unwinds uobjects on failure, it is necessary for create AH. In _rdma_create_ah(), the HW object is otherwise leaked. Fixes: bed686d8dcd4 ("RDMA/bnxt_re: Use ib_respond_empty_udata()") Signed-off-by: Leon Romanovsky Link: https://patch.msgid.link/20260714-fix-destroy-no-udata-v2-1-734fdcf667d5@kernel.org Acked-by: Selvin Xavier Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ee901a0f465150d4fab0807d4a0d9aa61e7c11e9 Author: Jacob Moroni Date: Thu Jul 2 17:06:46 2026 +0000 RDMA/core: Add ib_no_udata_io() helper [ Upstream commit a833ce42d05624f27ac9b32e939df9caa7b06af3 ] In many cases, a driver op accepts no input data and provides no response. This helper can be used in those handlers to adhere to the uAPI forward/backward compat rules by failing early if invalid udata is provided (whether input or output). Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260702170652.4159201-2-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: d38c835925d4 ("RDMA/bnxt_re: Validate udata before executing commands") Signed-off-by: Sasha Levin commit 5ec111ddc1f727c1e4580aea459842ae5a8359a5 Author: Ibrahim Hashimov Date: Sun Jul 12 14:21:49 2026 +0200 RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] [ Upstream commit 126c757e4cd46f866ddc283143b58eb4d9bf52cd ] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone. Fixes: 8700e3e7c485 ("Soft RoCE driver") Reviewed-by: Zhu Yanjun Signed-off-by: Ibrahim Hashimov Link: https://patch.msgid.link/20260712122149.78142-1-security@auditcode.ai Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ca99431820e8cac19f6a091c04da54cbe8d64f52 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 7e24fd5253fcfb7b1fffe31bd5d1799c3eb5064d Author: Jun Yan Date: Wed Jun 24 21:56:44 2026 +0800 arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe [ Upstream commit 7f1d0cc86cb70fa550163b6f70fd1d484c03218e ] The PCIe PHY node references mipi_pcie_analog_dphy via its phys property. Enable this analog PHY node to make PCIe functionally viable. Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260624135650.727077-5-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit a22abf6d48eebcb98b2e6586f23ade48cf077d23 Author: Jun Yan Date: Wed Jun 24 21:56:42 2026 +0800 arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins [ Upstream commit 45eb76f9ab6854f79690d56d04df227429a536b8 ] The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy) pin description, which is required for NAND controller operation. Add it to the pinmux list. Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260624135650.727077-3-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0c52d48122a13f5cf2916ea5e2be0e96455adb36 Author: Can Peng Date: Sat Jul 18 17:00:54 2026 +0800 phy: starfive: Fix runtime PM cleanup in JH7110 DPHY RX probe [ Upstream commit 97bed336f6a25c9d1115ca95e3aa00e05c3bc271 ] stf_dphy_probe() enables runtime PM before registering the PHY provider. If devm_of_phy_provider_register() fails, probe returns with runtime PM still enabled. The driver also has no remove callback, so runtime PM is left enabled on driver unbind after a successful probe. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on later probe failures and on driver unbind. Fixes: f8aa660841bc ("phy: starfive: Add mipi dphy rx support") Signed-off-by: Can Peng Reviewed-by: Changhuang Liang Link: https://patch.msgid.link/20260718090054.444513-3-pengcan@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit da666984ffda4dde793e3178dcc7c2497fb3d098 Author: Can Peng Date: Sat Jul 18 17:00:53 2026 +0800 phy: starfive: Fix runtime PM cleanup in JH7110 DPHY TX probe [ Upstream commit f40b0241f3a382e99c14de2f28f14a44973407c1 ] stf_dphy_probe() enables runtime PM before getting the clock and reset controls, creating the PHY and registering the PHY provider. If any of those steps fails, probe returns with runtime PM still enabled. The driver also has no remove callback, so runtime PM is left enabled on driver unbind after a successful probe. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on later probe failures and on driver unbind. Fixes: d3ab79553308 ("phy: starfive: Add mipi dphy tx support") Signed-off-by: Can Peng Reviewed-by: Changhuang Liang Link: https://patch.msgid.link/20260718090054.444513-2-pengcan@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cdaa9cb77eb67f2d4921600f6531315040888e29 Author: Rodrigo Alencar Date: Thu Jul 16 13:14:18 2026 +0100 iio: dac: ad5686: missing NULL check on match data [ Upstream commit 572a008526359cdac2fa935dad75e9d50a79792f ] Verify that chip_info pointer is not NULL. If a user binds the driver using driver_override via sysfs with a device name not present in the id_table or of_match_table, match data will be NULL. Fixes: 0eb1728461a1 ("iio: dac: ad5686: drop enum id") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260710113149.53EC51F000E9@smtp.kernel.org/ Signed-off-by: Rodrigo Alencar Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5ed1b048527bebe4529eb6e01c34dcc5d97ba5fe 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 2787034ea01632df70b39a4e24ad4723d07273c5 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 6fc436e1500c5e4f0dde2a3dbadf6d898057be8f 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 f71c94c1a657492e015be227d44c4198a8e7a91d 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 f3ec6702a1d216be61f692cc0a983d6c8fb5ebf7 Author: Koichiro Den Date: Sat Jul 18 03:06:32 2026 +0900 dmaengine: dw-edma: Terminate all descriptors without callbacks [ Upstream commit 99109a51efd28c9a661fbfb9469b023c517b31d1 ] The DMA Engine client documentation says in the "Terminate APIs" section of Documentation/driver-api/dmaengine/client.rst: "No callback functions will be called for any incomplete transfers." dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires. 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-3-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 57cf929a33cb76be3f24886073ae820b4c496914 Author: Leon Hwang Date: Wed Jul 15 22:11:22 2026 +0800 bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn [ Upstream commit 7a0855e73757ee9cf25ba635a1c735018ecba742 ] The BPF_MOV64_PERCPU_REG insn requires JIT to emit native code to for 'dst_reg = src_reg + '. However, the interpreter ignores the 'off' at its ALU64_MOV_X label. The 'off' indicates the insn is BPF_MOV64_PERCPU_REG insn. Then, when the interpreter loads memory from the register, it will hit a page fault. [ 2.545572] BUG: unable to handle page fault for address: ffffffffacaaf034 [ 2.546485] #PF: supervisor read access in kernel mode [ 2.547167] #PF: error_code(0x0000) - not-present page [ 2.547850] PGD 134e63067 P4D 134e63067 PUD 134e64063 PMD 10021c063 PTE 800ffffeca550062 [ 2.548912] Oops: Oops: 0000 [#1] SMP PTI Set jit_required as true in order to disallow interpreter fallback in core.c::__bpf_prog_select_runtime(), if any BPF_ADDR_PERCPU insn is patched to the prog. BTW, rename the helper bpf_map_supports_cpu_flags() to bpf_map_is_percpu_map(). Fixes: 7bdbf7446305 ("bpf: add special internal-only MOV instruction to resolve per-CPU addrs") Signed-off-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260715141122.15783-4-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 17da80d0c7b56579476b6644120bcfea778e531a Author: Leon Hwang Date: Wed Jul 15 22:11:21 2026 +0800 bpf: Disallow interpreter fallback for gotox insn [ Upstream commit 905f716362e1186c1a23447ca279e6d21f795cdb ] The interpreter does not recognize the BPF_JMP|BPF_JA|BPF_X insn, which is used for insn_array map. Thereafter, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.563726] BPF interpreter: unknown opcode 0d (imm: 0x0) [ 2.564557] ------------[ cut here ]------------ [ 2.565206] kernel BUG at kernel/bpf/core.c:2349! [ 2.565882] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when insn_array map is used in the prog in order to disallow interpreter fallback for gotox insn in core.c::__bpf_prog_select_runtime(). Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps") Signed-off-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260715141122.15783-3-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 408b6d3bc19c4aa852ab7ee2f447756e52e69967 Author: Leon Hwang Date: Wed Jul 15 22:11:20 2026 +0800 bpf: Disallow interpreter fallback for arena-related insns [ Upstream commit 34746b5a84ec37c0ea2bf6808c65c5ed8790eb51 ] Since the interpreter does not support the arena-related insns, interpreter fallback should not be allowed for these insns in core.c::__bpf_prog_select_runtime(). Currently, when the interpreter executes the arena ST/LDX/STX insns, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.579196] BPF interpreter: unknown opcode a2 (imm: 0x0) [ 2.579998] ------------[ cut here ]------------ [ 2.580652] kernel BUG at kernel/bpf/core.c:2349! [ 2.581314] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when arena map is used in the prog to disallow interpreter fallback for arena-related insns. Fixes: 6082b6c328b5 ("bpf: Recognize addr_space_cast instruction in the verifier.") Signed-off-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260715141122.15783-2-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 8a08635656037aee9c12231ed384449c4ffb1a93 Author: Yiyang Chen Date: Fri Jul 17 12:53:47 2026 +0000 bpf: Reject arena frees below the arena base [ Upstream commit b5a71cb2db6d84ac0042549dcec266b18429d41e ] bpf_arena_free_pages() accepts scalar arena addresses. The runtime masks the address to the low 32 bits and reconstructs a full user address from the arena base before returning the range to the arena free tree. When the scalar value is below the low 32 bits of the arena base, full_uaddr falls below user_vm_start. The existing upper-end clipping then turns this into an out-of-range free-tree offset. A later allocation can reuse that offset and return an address below the arena mapping. Reject such frees before computing the clipped range. Fixes: 317460317a02a ("bpf: Introduce bpf_arena.") Signed-off-by: Yiyang Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260717-c10-031-public-bpf-next-v2-b4-v2-1-54b555443a7c@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 49882b4d5290d3da626d98634ee4adf988c06e0f Author: Abel Vesa Date: Wed Jul 15 16:29:16 2026 +0300 arm64: dts: qcom: glymur: Add CX power domain to GCC [ Upstream commit 2edbea82d8edbddb2a235b8f988f17b86f075476 ] The GCC GDSCs on Glymur are backed by the RPMh CX power domain. Without describing that parent domain, consumers of GCC-provided GDSCs can enable their local domain without causing the required CX vote to be held. Add the CX power-domain reference to the GCC node so votes from GCC GDSC consumers can propagate to RPMh CX. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260715-glymur-fix-gcc-cx-scaling-v3-3-72eb5adad156@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d7355c6040cf520b4c9ef6fba69ed99a69d8a43 Author: Puranam V G Tejaswi Date: Sat Jul 18 02:11:26 2026 +0530 drm/msm/a6xx: Fix RBBM_CLOCK_CNTL3_TP0 value in a730_hwcg [ Upstream commit 01bcc0398f43099acb407a6067481e635c3e1b84 ] The RBBM_CLOCK_CNTL3_TP0 entry in a730_hwcg has bits[19:16] set to 2 (clock gating enabled for that TP0 stage). As per the latest recommendation, clear this nibble to disable clock gating for this particular stage. Fixes: 9588d2f860a4 ("drm/msm/a6xx: Add A730 support") Signed-off-by: Puranam V G Tejaswi Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/740955/ Message-ID: <20260718-eliza-gpu-v2-1-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 50fb8b5857d5c791e6f07f88cdc02fe8f853125f 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 231bbc04c58f115a505bf3b668ec69ef40a1773b 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 07fee585336ac0787d098ac277af07662925ecea Author: Ewan D. Milne Date: Mon Jul 13 13:33:18 2026 -0400 drivers: base: Remove statistics group if encryption group not created [ Upstream commit 6e328b4a208f7a06df3c1df18d7645c74c90f5f3 ] If transport_add_class_device() gets an error from sysfs_create_group() when creating the encryption group, it does not remove the statistics group in the error path. Adjust the error path to do this properly. v2: Only remove statistics group if tcont->statistics is non-NULL Fixes: bd2bc528691e ("scsi: scsi_transport_fc: Introduce encryption group") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Ewan D. Milne Reviewed-by: Justin Tee Link: https://patch.msgid.link/20260713173318.3060047-1-emilne@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7244dd0f12629484a1936dc5c5837670d8d9f80c Author: Maíra Canal Date: Fri Jul 10 08:43:27 2026 -0300 drm/v3d: Associate BOs with every job that accesses them [ Upstream commit fa98563ab00dbe62fcedfef6bdd34ded7a860d9f ] A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption. Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects. As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded. Fixes: dffa9b7a78c4 ("drm/v3d: Add missing implicit synchronization.") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260710114734.2731000-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 89d415976852712f84cc3bd4522a8fae6ae57dc9 Author: Maíra Canal Date: Thu Jun 4 17:32:21 2026 -0300 drm/v3d: Convert submit helpers to operate on struct v3d_submit [ Upstream commit f59d986943afbb97443cf91f45b1dc2c6fb6bebc ] Generalize the submission helpers so they act on a whole struct v3d_submit (the entire job chain) rather than on individual jobs and a drm_exec. This lets a submission of several chained jobs be locked, fenced, and finalized as a single unit, and is the groundwork for collapsing the indirect CSD path into one chain. The following helpers were generalized: - v3d_lookup_bos() - v3d_lock_bo_reservations() (renamed to v3d_submit_lock_reservations()): - v3d_attach_fences_and_unlock_reservation() - v3d_setup_csd_jobs_and_bos() Now, the locking helper now iterates over all jobs and locks the union of their BOs under one DRM exec, using DRM_EXEC_IGNORE_DUPLICATES to tolerate shared BO references. The fence-attach helper similarly walks every job and attaches the chain's last fence to all touched BOs. Also, v3d_submit_jobs() becomes the single submit-and-finalize entry point and callers no longer need to open-code fence attachment, reservation unlocking, etc. Update CL/TFU/CSD/CPU ioctls to use the new helper signatures. The CPU ioctl still uses two struct v3d_submit instances (one for the CPU job, one for the indirect CSD jobs) and keeps its manual two-pass fence-attach flow. Converting the indirect CSD path into the unified chain is done in the next commit. No functional change. Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-8-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit 87bdadba51c57dcbd058df6ae73cf74bc3b718e2 Author: Maíra Canal Date: Thu Jun 4 17:32:20 2026 -0300 drm/v3d: Make v3d_get_cpu_indirect_csd_params() a pure parser [ Upstream commit 719ea1f03984f959700326aaec04b5bcdf3ca982 ] v3d_get_cpu_indirect_csd_params() currently does double duty: it parses the indirect CSD extension and, while still inside the extension parser, also creates the CSD/clean jobs and locks their BOs through a separate DRM exec context. This nested submission deviates from the standard flow and makes it hard to fold the indirect CSD path into the unified submit chain. Stash the parsed drm_v3d_submit_csd args in struct v3d_indirect_csd_info and have the parser only fill in the parameters. Then, move job creation (v3d_setup_csd_jobs_and_bos()) into v3d_submit_cpu_ioctl(), where is the proper place to create jobs. No functional change, but prepares to move the CPU ioctl into the unified submission chain. Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-7-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit d7c6dfcd286dbb31d3fb44926b01ff081c3a9cbc Author: Maíra Canal Date: Thu Jun 4 17:32:19 2026 -0300 drm/v3d: Introduce struct v3d_submit and convert CL/TFU/CSD ioctls [ Upstream commit 57df8fa619c75928aa962683ad4f8026a26f9b76 ] As the V3D driver grew with time, different types of submission were added and the submission code grew more complex, but the driver stuck with the same abstractions. Nowadays, the submission ioctls don't submit a single job, but a chain of jobs: 1. v3d_submit_cl_ioctl() submits a BIN job (optional), RENDER job (mandatory), and a CLEAN_CACHE job (optional). 2. v3d_submit_csd_ioctl() submits a CSD, and a CLEAN_CACHE job. 3. v3d_submit_tfu_ioctl() submits a TFU job. Therefore, each ioctl submits a chain of jobs in which each job depends on the previous one. However, this concept is not well represented in software at the moment. To address this, introduce a new concept: the struct v3d_submit, which groups the submission state and represents the submission chain formed by an ordered array of jobs. Add new helpers to allocate, add jobs to the chain and submit jobs to the scheduler, all based on the new struct. Convert v3d_submit_cl_ioctl(), v3d_submit_tfu_ioctl() and v3d_submit_csd_ioctl() to the new pattern. Each ioctl now follows the same flow: add jobs -> attach perfmon -> lookup BOs -> lock reservations -> submit chain -> attach fences -> put jobs. The CPU ioctl is left on the old helpers for now; its indirect CSD path requires some restructuring that will be addressed in the next few commits. Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-6-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit 941522179e62fc23ae75c9fd71ad35691a4a4caf Author: Maíra Canal Date: Thu Jun 4 17:32:18 2026 -0300 drm/v3d: Migrate BO reservation locking to DRM exec [ Upstream commit e4a131d1851e217a0ebbd8632a705f6bb5a67672 ] Replace the drm_gem_(un)lock_reservations() + ww_acquire_ctx pattern with DRM exec across all submit ioctls. Just a straightforward conversion; no functional change. Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-5-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit cfb009ab261863dc99f353e982a7b035c9a0b116 Author: Maíra Canal Date: Thu Jun 4 17:32:16 2026 -0300 drm/v3d: Extract v3d_job_add_syncobjs() helper [ Upstream commit 57d78cbc16c930f698616d4db16aa85a49a356f7 ] Move the syncobj dependency setup out of v3d_job_init() into its own v3d_job_add_syncobjs() helper and make the queue that the job was submitted a variable in struct v3d_job, so that v3d_job_add_syncobjs() can use it. No functional change. This prepares for the next commit which changes the error handling, and for a later consolidation that separates job allocation from syncobj attachment. Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-3-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit a3e81f48c9e61d8fcbff886e46c48f035bcc5a63 Author: Maíra Canal Date: Thu Jun 4 17:32:14 2026 -0300 drm/v3d: Drop unused drm_encoder.h include from v3d_drv.h [ Upstream commit cc29c864ee50b9c145fa847406b3535026511917 ] The V3D driver has no display pipeline, so nothing in the driver requires drm_encoder.h. Remove the stale include. Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-1-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Stable-dep-of: fa98563ab00d ("drm/v3d: Associate BOs with every job that accesses them") Signed-off-by: Sasha Levin commit 02438d15b0f41e19f03fd6fd2f8ac7b0a26582a3 Author: Namhyung Kim Date: Mon Jul 6 16:48:35 2026 -0700 perf build: Fix compiler errors with old capstone [ Upstream commit e01c7bd5b1eece254bcbf282db066b12c4815d21 ] It seems RISCV was added in capstone version 5 (released Jul 2023). Unfortunately they are enum constants so cannot check with #ifdef but anyway we can define the symbols. Let's do it using the version number to avoid build errors. It'll fail at runtime though. util/capstone.c: In function 'e_machine_to_capstone': util/capstone.c:186:25: error: 'CS_ARCH_RISCV' undeclared (first use in this function); did you mean 'CS_ARCH_SYSZ'? 186 | *arch = CS_ARCH_RISCV; | ^~~~~~~~~~~~~ | CS_ARCH_SYSZ util/capstone.c:186:25: note: each undeclared identifier is reported only once for each function it appears in util/capstone.c:187:34: error: 'CS_MODE_RISCV64' undeclared (first use in this function); did you mean 'CS_MODE_MIPS64'? 187 | *mode |= (is64 ? CS_MODE_RISCV64 : CS_MODE_RISCV32) | CS_MODE_RISCVC; | ^~~~~~~~~~~~~~~ | CS_MODE_MIPS64 Also note that capstone renamed CS_MODE_RISCVC to CS_MODE_RISCV_C which would cause a different build failure on latest versions. It's reported in https://github.com/capstone-engine/capstone/issues/2977 so I think they will add compatibility layer to prevent the error. Fixes: 12c4737f55f2 ("perf capstone: Determine architecture from e_machine") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c91d07e9668061517605922d5c87f033b184e369 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 c645f6dd1af2ecc70fd3578e141f2f71fa9e4eff 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 37be7bc2c2d09c18e939da20224405864a0090b9 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 529aeba63d448bcc2944cd2b21d9a4a4807fc39f Author: Guangshuo Li Date: Sun Jul 5 11:31:07 2026 +0800 mtd: intel-dg: Fix runtime PM error path in probe [ Upstream commit df6f582df3377af316a60ca8ee0d590b2d03924d ] intel_dg_mtd_probe() allocates region names before enabling runtime PM and before calling pm_runtime_resume_and_get(). If kasprintf() fails while building a region name, the error path jumps to err, which calls pm_runtime_put(). At that point there has not been a successful pm_runtime_resume_and_get() call to balance, so the runtime PM usage count can underflow. Jump to err_norpm from the kasprintf() failure path, as the runtime PM reference has not been acquired yet. Fixes: 779c59274d03 ("mtd: intel-dg: Fix accessing regions before setting nregions") Signed-off-by: Guangshuo Li Reviewed-by: Raag Jadav Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit b07d0469126c198983a7615a2a5c3127c9e3a61b Author: Pengpeng Hou Date: Mon Jul 6 22:47:06 2026 +0800 soc: ti: knav_qmss: Remove debugfs file on teardown [ Upstream commit 3c817862759913097f11467ed4ed2bbf974dabaf ] knav_queue_probe() creates the global qmss debugfs file whose show callback reads the global knav_qdev state. knav_queue_remove() tears down the queue manager resources but leaves the debugfs file published. Save the debugfs dentry in struct knav_device and remove it during teardown before the resources used by the show callback are released. While touching the debugfs_create_file() call, spell the unchanged read- only file mode as 0444. Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706144706.96313-1-pengpeng@iscas.ac.cn Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit fda8fb7e8179561693a786a7af593f6b944a21c1 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 1d36a009c8ee15335ef0a7e890423bd31c1c148a Author: Alex Mastro Date: Wed Jun 17 11:58:01 2026 -0700 vfio: selftests: Avoid VLAs [ Upstream commit 6bc73befe1b4143ebe6a991b2ab133e9f3087128 ] Allocate VFIO ioctl requests dynamically instead of using VLAs. GCC 11.5.0 rejects initialized VLAs with: error: variable-sized object may not be initialized The replaced stack u8 arrays also do not guarantee native struct alignment for the aliased pointers. Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Fixes: 20face8c75ff ("vfio: selftests: Add helper to set/override a vf_token") Assisted-by: Codex:gpt-5.5-high Reviewed-by: Vipin Sharma Reviewed-by: David Matlack Signed-off-by: Alex Mastro Link: https://lore.kernel.org/r/20260617-scratch-amastro-vfio-selftests-avoid-vlas-v4-2-b9f52f1e2c5a@fb.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 6fb4cd8ee68f65a2d30a78125dcd9563079098e3 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 4a6518be316029650301f2a5e8f0def229b895d9 Author: Pei Xiao Date: Wed Jul 1 10:01:09 2026 +0800 ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove [ Upstream commit b6b5d64cb161a28347d64dc3168a636c4abb68d5 ] Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a "removed" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/lkml/178144969601.60470.1257088106279546587@gmail.com/ Fixes: 05e5027efc9c ("Staging: ipack: move out of staging") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/e3b0a90b07f079c5bcd5ca90d1dd3b79bb29adb5.1782870760.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5c8927882b70b47b075d17fb1b9196bccf15c5f4 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 1105f6e7b39221ee41730b54d7ba6f88e1228bfd Author: Breno Leitao Date: Thu Jun 11 04:55:13 2026 -0700 cacheinfo: don't propagate DT/ACPI error when arch supplies info (arm64) [ Upstream commit 274259391c14166fcabae74f9fc0104223ff27a1 ] cache_setup_properties() sets use_arch_info = true when DT/ACPI provide no cache nodes and the arch can derive the topology from CPU registers (e.g. arm64 reading CLIDR_EL1), but still returns the original -ENOENT. cache_shared_cpu_map_setup() bails on that error before the new flag can take effect, so the first CPU brought online always trips a misleading warning: cacheinfo: Unable to detect cache hierarchy for CPU 0 Subsequent CPUs skip cache_setup_properties() entirely because use_arch_info is now true, which is why only CPU0 hits it. This is reproducible on arm64 with the QEMU 'virt' machine, whose default DT has no cache nodes. Clear ret after setting use_arch_info so the caller proceeds and populates the shared cpu map via the arch-supplied leaves. Fixes: ef9f643a9f8b ("cacheinfo: Add use_arch[|_cache]_info field/function") Reviewed-by: Pierre Gondois Signed-off-by: Breno Leitao Reviewed-by: Sudeep Holla Link: https://patch.msgid.link/20260611-cacheinfo-v2-1-6069ef066cf3@debian.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b044a6c443d55bced7ddc31d4d1fb1e0f0d0ae51 Author: Pengpeng Hou Date: Tue Jun 23 09:52:48 2026 +0800 misc: lan966x_pci: depopulate children on populate failure [ Upstream commit f6e2ed54db95286d9512b1cff38264e2f6299814 ] lan966x_pci_probe() applies a device-tree overlay and then populates platform children from the overlaid node. If of_platform_default_populate() creates some children and then fails, the current error path only unloads the overlay. Depopulate the children before unloading the overlay on that failure path, matching the remove path order. Fixes: 185686beb464 ("misc: Add support for LAN966x PCI device") Reviewed-by: Herve Codina Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015248.22721-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab2fe43041412d37f88eb368a99f63f98b31d8ea 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 3ac54631098a799a0e5fce6681167f81f252ac9a 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 4984277bc43f84d7506346a09b29af138246d54a Author: Gui-Dong Han Date: Wed Jun 3 10:11:27 2026 +0800 misc: bcm-vk: Use acquire/release for msgq_inited [ Upstream commit 61b101c6a150057b6d512421ed108aed16e822ea ] bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers. Fixes: 111d746bb476 ("misc: bcm-vk: add VK messaging support") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260603021127.3285057-1-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0b8177cca0c9369c4a3a871d96aa13261b684ab0 Author: Uwe Kleine-König (The Capable Hub) Date: Tue May 26 10:52:07 2026 +0200 misc: pch_phub: Complete enum usage for device identification [ Upstream commit 077b4d1aa01a1b34c5b768b8c7a77c74b35b190b ] Recently an enum was introduced to identify the different hardware variants instead of magic constants. The respective commit however missed to adapt one code location that still checks the old values. As the values shifted by one this is a relevant fix. Fixes: 7b1d4ad96ea4 ("misc: pch_phub: Introduce an enum for device indentification") Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/8a97d9d5fb0a4abf7032324643e3e2337b1347bd.1779785111.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c70f3be8be0d594cd3e3750e6ad5017b8736371c Author: Alexander Usyskin Date: Thu Jul 9 13:47:22 2026 +0300 mei: lb: fix incorrect type in assignment [ Upstream commit 0c419df9c190b80136cc774325f84238e430e905 ] Fix the mix between __le32 and integer by casting the MEI_LB2_CMD constant as __le32 while using it. Fixes sparse waring: drivers/misc/mei/mei_lb.c:284:32: sparse: sparse: restricted __le32 degrades to integer drivers/misc/mei/mei_lb.c:330:40: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] command_id @@ got int @@ drivers/misc/mei/mei_lb.c:330:40: sparse: expected restricted __le32 [usertype] command_id drivers/misc/mei/mei_lb.c:330:40: sparse: got int Fixes: 773a43b8627f ("mei: lb: add late binding version 2") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605091533.79Zcv3CX-lkp@intel.com/ Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260709-fix_type_le-v3-1-478761151e05@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ca4489b3e54666a7cac7294e71a3cf64e5e95286 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 d65abe969dcb76e36e381227603f30c59eed70ed 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 ec5bd6731183eb6f619140c9bef2ee11ed818c20 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 8bf5e01238c33bd166264782f6896fd53ca21674 Author: Arnd Bergmann Date: Thu Jun 11 15:10:07 2026 +0200 gpib: use 'static inline' instead of 'extern inline' [ Upstream commit 6cc667892818fe44bef02193dfb9c3f843ade2b2 ] With GNU inline semantics, an 'extern inline' function is only included in the build if it can be inlined. When the compiler for some reason decides against inlining it, this causes a link failure, as observed in one function in the tnt4882_gpib driver: ld.lld: error: undefined symbol: mite_irq >>> referenced by tnt4882_gpib.c:974 (/home/arnd/arm-soc/drivers/gpib/tnt4882/tnt4882_gpib.c:974) >>> drivers/gpib/tnt4882/tnt4882_gpib.o:(ni_pci_attach) in archive vmlinux.a Change all of the 'extern inline' definitions in gpib to the regular 'static inline' to avoid this. Fixes: 0cd5b05551e0 ("staging: gpib: Add TNT4882 chip based GPIB driver") Fixes: 6c52d5e3cde2 ("staging: gpib: Add common include files for GPIB drivers") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260611131018.3662609-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a53e4bc076ee91f06dce8fd9466ffa9effa0af4 Author: Gui-Dong Han Date: Fri May 22 15:34:47 2026 +0800 gpib: Move stuck SRQ update under lock [ Upstream commit 7ddb521ab097413fbdff483b53b4a8c73a0e2b40 ] Move the stuck SRQ state update into autopoll_all_devices() and keep it under big_gpib_mutex. Except for initialization, keep the stuck_srq users under this mutex. autopoll_all_devices() is only called by autospoll_thread(), so there is no need to return to autospoll_thread() and set this state after dropping big_gpib_mutex. Without the mutex, a newly opened device can clear stuck_srq and have that clear overwritten by the previous autospoll result: autospoll: serial_poll_all() returns 0 and unlocks big_gpib_mutex open_dev_ioctl: open new device and clear stuck_srq with big_gpib_mutex held autospoll: set stuck_srq That leaves the board marked stuck again after the new device is opened. autospoll_wait_should_wake_up() then refuses to poll while stuck_srq is set, so later SRQ handling can be mistakenly suppressed. Without the mutex, atomic_set() and set_bit() only make individual updates atomic. They do not order the two updates or make stuck_srq and status visible as a consistent pair. Taking big_gpib_mutex serializes the state transition with the other runtime users. Keep the existing wakeup behavior unchanged and only move the stuck SRQ state update under the mutex. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260522073447.4117690-1-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2750b16e8539128db0f0ef0396055facec6d3035 Author: Alexander A. Klimov Date: Tue May 26 08:13:15 2026 +0200 tlclk: if sscanf() fails, fall back to 0, not random value [ Upstream commit 75f9481e0479c3faadf4d88baffe84b3d23d5763 ] If sscanf(IN, FMT, &OUT) fails, OUT may be unchanged. So if OUT was never initialized, it may be still uninitialized memory. To prevent such, initialize OUT=0 first. Fixes: 648bf4fb21f5 ("[PATCH] tlclk driver update") Fixes: 1a80ba882730 ("[PATCH] Telecom Clock Driver for MPCBL0010 ATCA computer blade") Signed-off-by: Alexander A. Klimov Link: https://patch.msgid.link/20260526061321.6123-4-grandmaster@al2klimov.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c48e5aa01525577d6b6e782962a5bfb0e1535cb5 Author: Cong Nguyen Date: Wed Jul 15 18:17:10 2026 +0700 staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths [ Upstream commit 41b8209376dffbd7b0b85c8bc4697d9166ac62ef ] issue_beacon(), issue_probersp() and issue_asocrsp() obtain a management xmit_frame together with its xmit_buf from the driver's fixed-size management-TX pools via alloc_mgtxmitframe(). On the normal path the frame is handed to dump_mgntframe(), which transfers ownership and eventually returns both objects to their pools (the frame and, for beacons, the buf in rtl8723bs_mgnt_xmit(); other bufs via the pending-xmitbuf/TX-completion path). Several error/edge paths return early after a successful alloc_mgtxmitframe() but before dump_mgntframe(), so ownership is never transferred and neither object is freed: - issue_beacon(): beacon larger than 512 bytes - issue_probersp(): cur_network->ie_length > MAX_IE_SZ - issue_probersp(): kzalloc() of the SSID scratch buffer fails - issue_asocrsp(): pkt_type is neither ASSOCRSP nor REASSOCRSP Because alloc_mgtxmitframe() removes the frame and buf from their free lists (list_del_init) without placing them on any pending list, an orphaned pair is on no list and referenced by nobody, so it is only reclaimed at driver teardown. Repeated hits progressively exhaust the management-TX pools until alloc_mgtxmitframe() returns NULL and the interface can no longer send beacons or probe/assoc responses. Free the frame and buffer on these paths, matching the existing correct error handling in issue_assocreq(). Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Cong Nguyen Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260715111710.295052-1-congnt264@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b21cb958292ee1e02eb305ff9de09f2f7edd551a 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 56ad47bee6d37ff4f3b2d36f434feac622981a60 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 977659adb341f6e30fb00dcf183f63f29df879e2 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 d0667c263362bb00a7bcbbd0ce51d6ccedf63eb6 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 a88fae3508aa3bf2a7eda12ec8019e99d23e809d Author: Narasimharao Vadlamudi Date: Fri Jul 10 16:37:29 2026 +0530 crypto: aspeed - Propagate platform_get_irq() errors [ Upstream commit eed5fde79651c66e0e24ba3d78a92afb63a76215 ] platform_get_irq() returns a positive IRQ number on success and a negative error code on failure. aspeed_acry_probe() and aspeed_hace_probe() already detect negative returns, but both convert every failure to -ENXIO. Return the original error code so callers can handle errors such as -EPROBE_DEFER correctly. Fixes: 2f1cf4e50c95 ("crypto: aspeed - Add ACRY RSA driver") Fixes: 70513e1d6559 ("crypto: aspeed - Fix check for platform_get_irq() errors") Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6ee726526f08a489c14b1c292647fa233a1957e1 Author: Thorsten Blum Date: Fri Jul 10 09:42:17 2026 +0200 crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping [ Upstream commit 3ae59a2eba64b3648f069aa52eeaaeefdfe4bb2f ] sg_dma_len() is only valid after mapping the scatterlist with dma_map_sg(). However, sl3516_ce_need_fallback() checks it before the source and destination scatterlists are mapped. Thus, a stale DMA length that is not a multiple of 16 could incorrectly force a software fallback when CONFIG_NEED_SG_DMA_LENGTH=y. Remove the invalid checks; the existing scatterlist length checks are sufficient. Fixes: 46c5338db7bd ("crypto: sl3516 - Add sl3516 crypto engine") Signed-off-by: Thorsten Blum Acked-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c5b52d79d6b2ee4f5c34f0e9c9ec593636c55a23 Author: Chia-Yuan Li Date: Tue Jul 14 15:48:11 2026 +0800 wifi: rtw89: fw: use MAC source for IO offload delay command [ Upstream commit 730dbda6dc70d29180eb2a7e9fa36823838bb042 ] The udelay/mdelay helpers set the command source to RTW89_FW_CMD_OFLD_SRC_OTHER (4), which does not fit the two-bit field RTW89_H2C_CMD_OFLD_W0_SRC (GENMASK(1, 0)). The le32_encode_bits() masks it down to 0 (RTW89_FW_CMD_OFLD_SRC_BB), and compiler throws __field_overflow() error. Fortunately it still works because firmware ignores the source field for a delay command. Use RTW89_FW_CMD_OFLD_SRC_MAC as the vendor driver does, and drop the unused RTW89_FW_CMD_OFLD_SRC_OTHER enumerator. Reported-by: Bitterblue Smith Closes: https://github.com/morrownr/rtw89/issues/111 Fixes: ae3d327515f2 ("wifi: rtw89: add IO offload support via firmware") Signed-off-by: Chia-Yuan Li Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260714074811.30124-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit a28a7d9b3bb116da788ae492c90465ec1a7fa6e8 Author: Can Guo Date: Thu Jun 18 07:09:29 2026 -0700 scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context [ Upstream commit 760fc6f0e25a72832c2fcf37ecf5f1b770ec8374 ] TX EQTR may run while devfreq gear scaling has quiesced the UFS tagset. In that context, functions ufshcd_tx_eqtr(), __ufshcd_tx_eqtr() and ufs_qcom_get_rx_fom() allocate memory with GFP_KERNEL. If direct reclaim is triggered, reclaim/writeback can depend on I/O to UFS device. Because the queue is quiesced, this can cause deadlock. Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all allocations in the TX EQTR call tree, including: - params->eqtr_record in ufshcd_tx_eqtr() - eqtr_data in __ufshcd_tx_eqtr() - params in ufs_qcom_get_rx_fom() This is preferred over tagging individual call sites with GFP_NOIO, as it automatically covers any future allocations added anywhere in the call tree without requiring each caller to be aware of this constraint. [mkp: fix label as suggested by Bart] Fixes: 03e5d38e2f98 ("scsi: ufs: core: Add support for TX Equalization") Closes: https://sashiko.dev/#/patchset/20260615132834.2985346-1-can.guo@oss.qualcomm.com?part=2 Signed-off-by: Can Guo Reviewed-by: Ziqi Chen Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260618140941.902000-1-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 576312f027d1595e2a06dbbdf0c2ca5a2cb6241a Author: Pu Lehui Date: Thu Jul 16 12:01:55 2026 +0000 bpf: Sync tail_call_reachable with callee state on entry [ Upstream commit 3513ea9dab6c1a3d2dc8e6160c41f690206948b6 ] Currently in check_max_stack_depth_subprog, when the verifier enters a new callee branch, the local tail_call_reachable is not properly synchronized with the callee's state. Consider a main prog branching into multiple subprogs: subprog0 -> tailcall main < subprog1 -> subprog2 When the verifier finishes checking subprog0 and backtracks to main prog, the local tail_call_reachable state is left as true. As it proceeds to subprog1, this uncleared state leaks into the new branch, falsely marking subprog1 and subprog2 as tailcall reachable. Fix this by explicitly syncing tail_call_reachable with the callee's has_tail_call state on entry. The caller's state is safely preserved and restored via the existing backtracking logic. Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Reported-by: Sashiko Signed-off-by: Pu Lehui Link: https://patch.msgid.link/20260716120157.835937-2-pulehui@huaweicloud.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 09b360eb6ce345996a30fad8c86e9df80f41cd7e Author: Ruoyu Wang Date: Thu Jul 9 14:23:09 2026 +0800 drm/msm: Only fini scheduler after successful init [ Upstream commit e2332abed2a4d3caa59052095dc16e4ce44791ea ] msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails. If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized. Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Signed-off-by: Ruoyu Wang Patchwork: https://patchwork.freedesktop.org/patch/738905/ Message-ID: <20260709062309.4168362-1-ruoyuw560@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit d684f756d029d81db1cd64cd9645556e53fcc784 Author: Jie Zhang Date: Fri Jun 5 01:38:22 2026 +0530 drm/msm: Fix task_struct reference leak in recover_worker [ Upstream commit 40b793714ad8f393ab3d469f9d00b20ebda46257 ] get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery. Fixes: 25654a1756a4 ("drm/msm: Update global fault counter when faulty process has already ended") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730662/ Message-ID: <20260605-assorted-fixes-june-v1-6-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 8fc6a356f498d99e6a4eb670b45277fb155c695c Author: Jie Zhang Date: Fri Jun 5 01:38:21 2026 +0530 drm/msm/a6xx: Fix IRQ storm during msm_recovery test [ Upstream commit bc024d325e98b6b2806e00455e030622fb8e1820 ] Once a hang is triggered by the msm_recovery test, the gpu error irq remains asserted and triggers an interrupt storm. In the worst case, this IRQ storm lands on the CPU core where the hangcheck timer is scheduled, blocking it from running. This eventually leads to CPU watchdog timeouts. To fix this, mask the gpu error irqs during msm_recovery test and enable them back during the recovery. Fixes: 5edf2750d998 ("drm/msm: Add debugfs to disable hw err handling") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/730660/ Message-ID: <20260605-assorted-fixes-june-v1-5-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 197912ffbb657849553734933f7a201c92cce27d Author: Jie Zhang Date: Fri Jun 5 01:38:20 2026 +0530 drm/msm/a6xx: Fix A621 GPUCC register list for state capture [ Upstream commit d052d0358fb89b59718b9c24871d72006d4b89b0 ] A621 uses an incorrect GPUCC register list during state capture. The existing list matches A623/A663. Rename it accordingly and add a dedicated A621 GPUCC register list. Fixes: 11cdb81b3c1b ("drm/msm/a6xx: Fix gpucc register block for A621") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/730659/ Message-ID: <20260605-assorted-fixes-june-v1-4-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9d52bfc956c7738700f4c67ce5e7d530350f5056 Author: Jie Zhang Date: Fri Jun 5 01:38:19 2026 +0530 drm/msm/a6xx: Fix A663 GPUCC register list for state capture [ Upstream commit fc7ccbc6174b79ffab5be5dca5b6e253df22f030 ] The GPUCC register list for A663 is incorrect, which can cause out-of-bounds register access during GPU state capture. Update it to use the correct register ranges. Fixes: 5773cce8615c ("drm/msm/a6xx: Add support for A663") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/730656/ Message-ID: <20260605-assorted-fixes-june-v1-3-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit dc64cf9d71428234389b635d142cb5fe07d57eab Author: Jie Zhang Date: Fri Jun 5 01:38:18 2026 +0530 drm/msm: Recover HW before retire hung submit [ Upstream commit b303e1d52811de7d1bcf793560754d4df68d4a1c ] During recovery, it is not safe to retire the hung submit before we recover the GPU. Retiring the submit triggers BO free and that can result in GPU pagefaults since the GPU may be actively accessing those BOs. To fix this, retire the submits after gpu recovery is complete in recover_worker(). Fixes: 1a370be9ac51 ("drm/msm: restart queued submits after hang") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Acked-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730655/ Message-ID: <20260605-assorted-fixes-june-v1-2-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 51fcee9d4140b08428bff9a9b2dc85ab74185557 Author: Shivam Rawat Date: Fri Jun 5 01:38:17 2026 +0530 drm/msm/a6xx: Fix stale rpmh votes after suspend [ Upstream commit d9108bfdb746edacdb05bd27959a4ae63c6c7f3f ] There are stale RPMH votes (BCM votes) observed after GMU suspend. This is because the rpmh stop sequences are skipped during gmu suspend. Fix this and also move GMU to reset state to avoid any further activity. Fixes: f248d5d5159a ("drm/msm/a6xx: Fix PDC sleep sequence") Signed-off-by: Shivam Rawat Signed-off-by: Akhil P Oommen Tested-by: Neil Armstrong # on SM8650-HDK Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730652/ Message-ID: <20260605-assorted-fixes-june-v1-1-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 105aaff286a153bfde3c1f5be534e6ded1f64342 Author: Dan Carpenter Date: Thu Jun 11 13:27:30 2026 +0300 drm/msm/adreno: fix use after free on error path in a6xx_gpu_init() [ Upstream commit b8a9c9c5787bed1243e5364c89ca66c26b4e4d83 ] The a6xx_destroy() function frees "a6xx_gpu" and so "adreno_gpu" points to freed memory. Preserve the error code before freeing the memory to avoid a use after free. Fixes: d158886cba08 ("drm/msm/adreno: Trust the SSoT UBWC config") Signed-off-by: Dan Carpenter Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/732275/ Message-ID: Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b00290d1dc23a5ef9a0d3103aad1fe2274e86569 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 eb9f221498757c10ed4386f1a6b5351b4ff241eb 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 a1c4229ebeb465b73a9bad1c16d062434f33942f Author: Mikko Perttunen Date: Tue Jun 9 17:09:18 2026 +0900 gpu: host1x: Avoid double device_add when clients already present [ Upstream commit 254290869fd234b85119c48dbb98efa5fcd41a31 ] host1x_device_add looks through the idle clients list to populate subdevs, and any matches entries are moved from the subdevs list to the active list. If all subdevs are populated, device_add will be called on the device. The secondary "subdevs list empty" check will then incorrectly again call device_add. However, this would require a convoluted scenario since clients don't typically end up on the idle clients list. Fix by checking whether the device was already added before adding again. Fixes: fab823d82ee5 ("gpu: host1x: Allow loading tegra-drm without enabled engines") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-2-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit 082b353c05b8eaf07e03fc1918c176cd3c216e25 Author: Avraham Stern Date: Wed Jul 15 22:04:31 2026 +0300 wifi: iwlwifi: mei: pass correct argument to function [ Upstream commit 905f57aefde4f4092a411c8a55856182fb1c7598 ] The first argument to iwl_mei_write_cyclic_buf() should be the cldev but the q_head pointer is passed instead. Fix it. Fixes: 652291601459 ("iwlwifi: mei: don't rely on the size from the shared area") Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.24cea60c6428.I42301010c31487b1458faa967b22c8320b0cfd23@changeid Signed-off-by: Sasha Levin commit bc7a7ad93070879c74cdcb107ebb1a02ec212712 Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:29 2026 +0300 wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments [ Upstream commit 9318bc0c41b24705690cf80d1596cf6b711e7027 ] Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well. Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.60121deecf2c.Iebc891c95a7bd1b2a093b0bb88532db446a758ee@changeid Signed-off-by: Sasha Levin commit f7f770d12e6e928006f89a59291074e5fea82886 Author: Avraham Stern Date: Wed Jul 15 22:04:27 2026 +0300 wifi: iwlwifi: mei: check SAP message length before reading it [ Upstream commit 7d8cc301bcba233f31b589a45f4c1c97f2bb90d6 ] Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow. Fixes: bcd68b3dbe78 ("wifi: iwlwifi: mei: fix tx DHCP packet for devices with new Tx API") Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.f0026ce26218.I00a856d3aacae1caac605c708f7362689b734234@changeid Signed-off-by: Sasha Levin commit 2a77cb320e3998afa5e1ed0e95908b226aae9ed6 Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:22 2026 +0300 wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser [ Upstream commit f6a6c01cbc046f68e6916a7e047a1bc881c8c9ab ] iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised. Fixes: 12d60c1efc29 ("iwlwifi: mvm: scrub key material in firmware dumps") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.355998ec4fbe.I40f3427657b897e911bdf4ebf8e494745508d126@changeid Signed-off-by: Sasha Levin commit 769e1910d41fdd01453cef4ae032a3c162f029f8 Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:20 2026 +0300 wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs [ Upstream commit 71e67b4b59337b2f9f4fef976a27de2dad7aabf2 ] The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc. Fixes: 2b69d242e29b ("wifi: iwlwifi: fw: print PC register value instead of address") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.a61c65f34e87.Ie5f1a7ca43e0cc5a0ddc8305b0448ddffc09cd18@changeid Signed-off-by: Sasha Levin commit 1d74ddb6da546f293e5575bc945d7d346ecdafd1 Author: Namhyung Kim Date: Fri Jul 10 17:04:16 2026 -0700 perf stat: Fix duplicate output with --for-each-cgroup [ Upstream commit c16af17927e0b9105f2964338f9341e0faf7edaa ] Currently it produces following output with duplicate events when --for-each-cgroup option is used. It seems perf stat adds them when it handles default events but didn't copy some fields in evsel__clone(). $ sudo perf stat -a --for-each-cgroup / true Performance counter stats for 'system wide': 8,440,165 duration_time / 8,439,895 duration_time / 8,440,015 duration_time / 8,440,024 duration_time / 8,440,075 duration_time / 8,440,095 duration_time / 330 context-switches / # 679.4 cs/sec cs_per_second 485.69 msec cpu-clock / # 57.5 CPUs CPUs_utilized 70 cpu-migrations / # 144.1 migrations/sec migrations_per_second 71 page-faults / # 146.2 faults/sec page_faults_per_second 12,183,711 branch-misses / # 10.9 % branch_miss_rate (5.15%) 111,981,297 branches / (5.15%) 95,844,809 branches / # 197.3 M/sec branch_frequency (35.49%) 65,611,429 cpu-cycles / # 0.1 GHz cycles_frequency (98.32%) 24,170,987 cpu-cycles / (95.12%) 18,552,509 instructions / # 0.8 instructions insn_per_cycle (95.12%) 22,405,293 cpu-cycles / (64.78%) 6,840,383 stalled-cycles-frontend / # 0.31 frontend_cycles_idle (64.78%) cpu-cycles / stalled-cycles-backend / # nan backend_cycles_idle stalled-cycles-backend / # nan stalled_cycles_per_instruction instructions / stalled-cycles-frontend / 0.006546057 seconds time elapsed Some events weren't counted. Try disabling the NMI watchdog: echo 0 > /proc/sys/kernel/nmi_watchdog perf stat ... echo 1 > /proc/sys/kernel/nmi_watchdog But I'm worrying about opening same events multiple times. Probably due to grouping, but I'm not sure if it's beneficial in the end. Without duplication, it seems it won't cause multiplexing (assuming no other users at the same time). Fixes: a3248b5b5427d ("perf jevents: Add metric DefaultShowEvents") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b3ce55b4a9da29645fe8e3c583cb02abe6ec2d3c Author: Praveen Talari Date: Thu Jul 16 13:55:45 2026 +0530 spi: geni-qcom: Fix sticky ret causing wrong return value on invalid proto [ Upstream commit 2c1c13da3a3a639d2ac7221e1a5e57945cbc7235 ] spi_geni_init() reuses 'ret' after it has already been set by the runtime PM acquire check earlier in the function. When an invalid protocol is later detected, the function returns this stale 'ret' value instead of a proper error code, so it can end up returning 0 (or some other non-error value) even though the protocol check failed. Fix this by returning -EINVAL directly on both invalid-proto paths. Fixes: d8e9ea989acb ("spi: qcom-geni: Fix missing error check on pm_runtime_get_sync()") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202607122241.qzP3QAXF-lkp@intel.com/ Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Acked-by: Mukesh Kumar Savaliya Link: https://patch.msgid.link/20260716-fix_return_error_code-v1-1-3295003aacd5@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3296c42d1c3c1f7f2dadd5093cf373bc3380ae27 Author: Iker Pedrosa Date: Thu Jul 9 12:53:24 2026 +0200 drm/solomon: remove unneeded variables in blit functions [ Upstream commit e5320be8a585a9286f231305d0d443d59c24e46c ] Remove unneeded 'ret' variables in ssd130x_fb_blit_rect(), ssd132x_fb_blit_rect(), and ssd133x_fb_blit_rect() functions. These functions initialize ret to 0 and return it unchanged, so return 0 directly instead. Fixes: 2258f03989af ("drm/solomon: Move calls to drm_gem_fb_end_cpu*()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606301409.I0ctsf41-lkp@intel.com/ Signed-off-by: Iker Pedrosa Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260709-fix-ssd130x-v1-1-1272cb3dc85e@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit 51a548f546519a2b923776662f31b0730d5767ad Author: Geert Uytterhoeven Date: Thu Jul 9 12:47:44 2026 +0200 soc: renesas: r8a78000: Drop duplicate "default ARCH_RENESAS" [ Upstream commit 07231087d5e24c4d9c578c824b96f8af913f7324 ] The Kconfig entry for ARCH_R8A78000 contains both "default y if ARCH_RENESAS" and "default ARCH_RENESAS", which are sort-of duplicates. Drop the latter, to restore consistency with the other ARM64 entries. Fixes: 5284d0b09d1bdc69 ("soc: renesas: Identify R-Car X5H") Reported-by: Marek Vasut Closes: https://lore.kernel.org/a069d50d-030d-4189-ae9d-37f989829da4@mailbox.org Signed-off-by: Geert Uytterhoeven Reviewed-by: Marek Vasut Reviewed-by: Kuninori Morimoto Reviewed-by: Duy Nguyen Link: https://patch.msgid.link/64de6e95719a6dec7412cf7e917a42749e738b99.1783593775.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit fa8dc4d73314c1de68446fd3df8c7f8029073f85 Author: Abel Vesa Date: Wed Jul 15 16:29:15 2026 +0300 clk: qcom: gcc-glymur: Enable runtime PM [ Upstream commit 8d4f342369d0d77f32a0211692442d3b6d455872 ] Enable runtime PM for the controller so the common GCC probe path resumes the attached domain while registering clocks, resets and GDSCs. This lets GDSC consumers propagate their votes through the GCC provider to the CX parent domain. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260715-glymur-fix-gcc-cx-scaling-v3-2-72eb5adad156@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 64de7f5c2d5cdd9be9a69125148892b38a2eede8 Author: Ian Rogers Date: Mon Jul 6 20:40:17 2026 -0700 perf jevents: Add more components to the metric sorting order [ Upstream commit 557f8b3ca8c8e58d5bc3084734bc7a470b043922 ] Nazar Kazakov reported non-deterministic builds due to the metrics being reordered in the jevents.py output. The metrics were largely only being sorted by name, add in the expressions and descriptions. Reported-by: Nazar Kazakov Closes: https://lore.kernel.org/linux-perf-users/20260706175624.692736-1-nazar.kazakov@codethink.co.uk/ Fixes: 40769665b63d ("perf jevents: Parse metrics during conversion") Tested-by: Nazar Kazakov Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 789395e53ebf4edd4dae2f2c51fe91f1c1998c10 Author: Namhyung Kim Date: Mon Jul 13 16:45:36 2026 -0700 perf sched: Free subcommand string after perf sched stats [ Upstream commit e1f522ac439f94d56cf0d9a3c82d1953646d377a ] The first entry of the sched_usage is dynamically allocated in parse_options_subcommand() so it should be released at the end. Do not return from a subcommand directly. Fixes: 064790a3d4a8 ("perf sched stats: Add support for diff subcommand") Reviewed-and-tested-by: Swapnil Sapkal Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7a936fa41c55ce1d8bde8011135d5c0917899280 Author: Namhyung Kim Date: Mon Jul 13 16:45:35 2026 -0700 perf sched: Fix memory leaks in perf sched stats report [ Upstream commit 60de2c6561ae57b5f2c50efecc1fa1f0081f731a ] The second pass data is not saved in the list and only used to calculate delta from the first pass. Let's free the data after use. Fixes: 5a357ae6ad63 ("perf sched stats: Add support for report subcommand") Reviewed-and-tested-by: Swapnil Sapkal Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit cf3282cf46be61fe9accfa2237a87e5f393b85aa Author: Namhyung Kim Date: Mon Jul 13 16:45:34 2026 -0700 perf sched: Add missing perf_session__delete() [ Upstream commit 2bd4ad6914ed73189ccc2fb2740e94dafd1a9a8f ] The perf sched stats record missed to release the session and ASAN reported a leak. Fixes: c3030995f23b ("perf sched stats: Add record and rawdump support") Reviewed-and-tested-by: Swapnil Sapkal Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c2d4db21ad2d57d52fee874546296073e5d86d84 Author: Luca Weiss Date: Fri Jul 10 11:53:57 2026 +0200 arm64: dts: qcom: milos: Add reset for sdhc_2 [ Upstream commit c3eceb0627605564f102dc0f5ca4a6060ca57fd4 ] Add the missing reset (BCR) for sdhc_2. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260710-milos-sdhc2-reset-v1-1-c7a155a517ba@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c5d8ff2d2f0552a1cfdbfa9f8d21684cb05e184c Author: Dmitry Baryshkov Date: Thu Jun 4 19:22:24 2026 +0300 arm64: dts: qcom: sm8250: correct frequencies in the Iris OPP table [ Upstream commit 68ea007df9293fcb29d38219d73094bbf4b59673 ] The OPP table for the Iris core is wrong, it copies the VDD table from the downstream kernel, but that table is written for the video_cc_mvs0_clk_src, while the upstream uses video_cc_mvs0_clk for OPP rate setting (which is clk_src divided by 3). Specify correct frequencies in the OPP table. Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") Reported-by: Konrad Dybcio Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Signed-off-by: Dmitry Baryshkov Reviewed-by: Vishnu Reddy Link: https://lore.kernel.org/r/20260604-iris-venus-fix-sm8250-v7-2-7bd2f0e5bae8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9362c436aec0b07c21dc6ed390e696cd3d356826 Author: Dmitry Baryshkov Date: Thu Jun 4 19:22:23 2026 +0300 arm64: dts: qcom: sm8250: sort out Iris power domains [ Upstream commit d5c8efda722eb1f67cfe299b71f13dab93746934 ] On SM8250 Iris core requires two power rails to function, MX (for PLLs) and MMCX (for everything else). The commit fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") added only MX power rail, but omitted MMCX voltage levels. Add MMCX domain to the Iris device node. Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") Reported-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260604-iris-venus-fix-sm8250-v7-1-7bd2f0e5bae8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6f73a043f8248f15392a55df6f35d612c2c5edcd Author: George Moussalem Date: Mon Jun 8 09:09:18 2026 +0400 arm64: qcom: ipq5018: Add GEPHY RX and TX clocks [ Upstream commit 742dc058588bf1233647dcd95738c0afc621435d ] Add RX and TX clocks for the IPQ5018 GEPHY to enable the datapath. Fixes: f5f2b835e316 ("arm64: dts: qcom: ipq5018: Add GE PHY to internal mdio bus") Reviewed-by: Dmitry Baryshkov Signed-off-by: George Moussalem Link: https://lore.kernel.org/r/20260608-ipq5018-gephy-clocks-v4-3-fb2ccd56894b@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f9f86d8363a7407d7402f45280077e55e89890e9 Author: George Moussalem Date: Thu May 21 11:55:58 2026 +0400 arm64: dts: qcom: ipq5018: Correct CMN PLL reference clock rate [ Upstream commit 5e92312a1d7542be9a0e588467bfbb2ca123eaac ] The correct CMN PLL reference clock rate for IPQ5018 is 4.8 GHz. The CMN PLL driver did not account for the ref clock divider which is 2 for IPQ5018. Therefore, the computed rate was twice the actual output. With the driver now accounting for the CMN PLL reference clock divider (commit: 88c543fff756), set the correct reference clock rate. Fixes: c006b249c544 ("arm64: dts: ipq5018: Add CMN PLL node") Signed-off-by: George Moussalem Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260521-ipq5018-cmn-pll-rate-fix-v2-1-04b28a92e0f2@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d857673a07694649febe57be2a0d449bd465582 Author: Gopikrishna Garmidi Date: Tue Jun 2 02:48:20 2026 -0700 arm64: dts: qcom: glymur-crd: merge duplicate &pmh0101_gpios node extensions [ Upstream commit 63b9c63716d452a71d4c5346e0dba4212b94c6a1 ] The &pmh0101_gpios node is extended twice in glymur-crd.dtsi. The first extension defines the nvme_reg_en pinctrl state for the NVMe regulator enable GPIO (gpio14), and the second adds key_vol_up_default for the volume-up key (gpio6). Merge both pinctrl states into a single &pmh0101_gpios block to avoid the duplicate node extension. No functional change intended. Fixes: a5ad8a8e473c ("arm64: dts: qcom: Commonize Glymur CRD DTSI") Signed-off-by: Gopikrishna Garmidi Reviewed-by: Pankaj Patil Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260602-merge-duplicate-pmh0101-gpios-node-v2-1-251107b3d9fe@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 31901797093e040ddf9aa9a175966f8b0c01a5f3 Author: Abel Vesa Date: Thu Jul 9 12:12:11 2026 +0300 arm64: dts: qcom: eliza: Enable first QUPv3 wrapper by default [ Upstream commit e78c2cf207c1ebf4558b709308199ee21de478ac ] Since each serial engine will be enabled as needed in each board dts, there is no point of disabling the first QUPv3 wrapper in SoC dtsi. So enable it by default. This is also now in line with the other SoCs, and also with the second QUPv3 wrapper. Fixes: 844807e1f89d ("arm64: dts: qcom: eliza: Add QUPv3, GPI DMA, SDHCI and LLCC nodes") Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260709-dts-qcom-eliza-enable-qupv3-1st-v1-1-e9a6904d0dea@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit be3f5db2d705b2ea837337dac59e172ba293cee5 Author: Pengyu Luo Date: Mon Jun 29 14:59:03 2026 +0800 arm64: dts: qcom: sc8280xp-x13s: Fix the drive-strength of mclk pin [ Upstream commit 09531bb8e0de5081fdbe215877dd7f2ec8b2f0e1 ] The value can be retrieve via windbg on Windows. lkd> !dd f111000 L8 ctl_reg => 0x284 in drivers/pinctrl/qcom/pinctrl-msm.c function msm_gpio_dbg_show_one() ... drive = (ctl_reg >> g->drv_bit) & 7; // (0x284 >> 6) & 7 == 2 ... seq_printf(s, " %dmA", msm_regval_to_drive(drive)); // (drive + 1) * 2 == 6; ... So the value is 6, not 16, it matches Windows now. Fixes: 21927e94caa5 ("arm64: dts: qcom: sc8280xp-x13s: Enable RGB sensor") Signed-off-by: Pengyu Luo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629065905.15651-2-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 74689c170832f484f78d910903e0bb2417481507 Author: Konrad Dybcio Date: Thu Jun 25 10:42:43 2026 +0200 arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO [ Upstream commit 569413a98a1761782a0770aa85d20a2c78893279 ] Update the 'enable-gpio' property name to 'enable-gpios' to conform to the bindings for the TI DRV2604 haptics module. While at it, use the GPIO_ACTIVE_HIGH define instead of the raw literal. Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5") Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260625-topic-ti_drv2604_dtwarn-v1-1-76e91fcafbe8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fb97d1d6c20692e15247fa5c8b894b2325e38aee Author: Denis V. Lunev Date: Wed Jul 15 20:34:52 2026 +0200 x86/mm/pat: Take cpa_lock around large-page collapse [ Upstream commit 1aac65f3e651334259ecb2a5f5ddb81c01f02599 ] Loading and unloading modules concurrently on several CPUs on a KASAN build, with a short delay injected at the CPA page-table lookup to widen the window, faults within minutes: BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 Write of size 8 at addr ffff888181139718 by task modprobe ... The buggy address belongs to the physical page: pfn:0x181139 ... page_type: f2(table) cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and frees the old PTE-table pages, while __change_page_attr() fetches a PTE pointer from a lockless lookup_address_in_pgd_attr() and writes it with set_pte_atomic() only later. When module text is served from a shared large ROX mapping the two run on the same PMD: CPU A (module load) CPU B (module finalize) ------------------- ----------------------- execmem_make_temp_rw set_memory_nx __change_page_attr split 2M -> 4K table P kpte = &P[i] (lockless) execmem_restore_rox set_memory_rox (CPA_COLLAPSE) cpa_collapse_large_pages rebuild leaf PMD flush_tlb_all pagetable_free(P) set_pte_atomic(kpte, ...) -> writes into freed P P is a page-table page (page_type: table), reused at once, so the write corrupts whatever got the page next: a bad-pte or bad-page splat, or a fatal fault once P has been turned into read-only text. The flush_tlb_all() before the free does not close this: its IPI only serializes against page-table walkers that run with interrupts off (e.g. GUP-fast); the walk in __change_page_attr() runs with interrupts on, so nothing stops it from holding a stale pointer into P. Serialize the collapse - the PMD rebuild, TLB flush and PTE-table free - under cpa_lock, the same lock __change_page_attr() now takes unconditionally since commit ("x86/mm/pat: stop gating cpa_lock on debug_pagealloc_enabled()"), so a concurrent walker can no longer hold a pointer into a table the collapse is about to free. Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Denis V. Lunev Signed-off-by: Dave Hansen Acked-by: Kiryl Shutsemau (Meta) Link: https://patch.msgid.link/20260715183453.2381141-1-den@openvz.org Signed-off-by: Sasha Levin commit 9ff718df547372d70ca20ad8e66a3fb1300936b2 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 b375b66a4722219bf84c823987506a287a0e08bc Author: Hongling Zeng Date: Fri Jul 10 16:01:40 2026 +0800 perf: evsel: Fix error handling in tp_format lookup [ Upstream commit 4968708beaad53940b67e4952e34a97d8768091d ] In evsel__tp_format(), when trace_event__tp_format*() returns an error, IS_ERR() checks the local variable 'tp_format', but PTR_ERR() incorrectly uses 'evsel->tp_format' which hasn't been assigned yet. Fix this by using PTR_ERR(tp_format) to extract the error code from the correct variable. Fixes: 6c8310e8380d ("perf evsel: Allow evsel__newtp without libtraceevent") Signed-off-by: Hongling Zeng Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2907676ed67aa41c3ddc6bdbc30f61d0659fe538 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 688f621a8d9c4e2a8acc71c21c1e8b7db8721e7f Author: Stephan Gerhold Date: Mon Jul 6 17:37:17 2026 +0200 remoteproc: qcom_q6v5_mss: Fix MDM9607 subsystem control instance ID [ Upstream commit 846baa5ab461e24d31f942dcdff1932e8516dd00 ] On MDM9607, the modem firmware exposes the QMI subsystem control service with instance ID 0x22 (34), as visible e.g. with qrtr-lookup: $ qrtr-lookup Service Version Instance Node Port 43 2 34 3 1 Subsystem control service Currently, qcom_q6v5_mss uses ssctl_id 0x12 for all platforms. The QMI service never shows up with this ID, leading to the following error when trying to shutdown the modem: qcom-q6v5-mss 4080000.remoteproc: timeout waiting for ssctl service Set the correct ssctl_id to allow clean shutdown of the modem firmware with the subsystem control service. ssctl_id 0x22 is also used by other modem-only Qualcomm platforms in qcom_q6v5_pas, such as SDX55. Fixes: 4fe236a1d024 ("remoteproc: qcom_q6v5_mss: Add MDM9607") Signed-off-by: Stephan Gerhold Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-2-f59e728af621@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit beab49fb74054192ac12ce20cf7fb52fddf42426 Author: Stephan Gerhold Date: Mon Jul 6 17:37:16 2026 +0200 remoteproc: qcom_q6v5_mss: Make ssctl_id configurable per platform [ Upstream commit 6aa64a4c89faec9daff36828df38f8f69498a870 ] Currently, qcom_q6v5_mss hardcodes 0x12 as the instance ID for the subsystem control (ssctl) QMI service. However, some platforms (e.g. MDM9607) provide the service with a different instance ID (0x22). Make it possible to override the ssctl_id per platform by adding it to the platform-specific rproc_hexagon_res struct. The same pattern also exists already inside qcom_q6v5_pas. Signed-off-by: Stephan Gerhold Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-1-f59e728af621@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 846baa5ab461 ("remoteproc: qcom_q6v5_mss: Fix MDM9607 subsystem control instance ID") Signed-off-by: Sasha Levin commit 73a9119d57e7a982b6d5a827cbd4605cf14feee4 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 b12839d2af89349196bd837fe3358e528ac2a640 Author: Rafael J. Wysocki Date: Wed Jun 24 19:33:08 2026 +0200 cpufreq: intel_pstate: Fix setting minimum P-state at init time [ Upstream commit db53c573d31d07d5d782c5312d37cb33be788eba ] If HWP is enabled, writes to MSR_IA32_PERF_CTL have no effect, so intel_pstate_get_cpu_pstates() should not attempt to call intel_pstate_set_min_pstate() to set the minimum P-state for the given CPU in that case. Accordingly, remove the intel_pstate_set_min_pstate() call from intel_pstate_get_cpu_pstates() and make both intel_pstate_cpu_init() and intel_cpufreq_cpu_init() call that function in their non-HWP code paths. The HWP code path in intel_pstate_cpu_init() does not need to update the current P-state of the CPU directly at all because it is taken care of the processor automatically, but the HWP code path of intel_cpufreq_cpu_init() should update it in principle to initialize the DESIRED_PERF field in MSR_HWP_REQUEST. For this purpose, make it call intel_cpufreq_hwp_update() and pass the minimum P-state limit to it as the current target value along with the current minimum and maximum limits. Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5090465.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit ae56bcb41607d87a92c8b855fa9f5dc1692376ae Author: Anas Khan Date: Thu Jul 2 16:58:28 2026 +0530 drm/amd/display: remove duplicate link_dp_panel_replay.h include [ Upstream commit dcda83715716ac828454094ed9c6e17150a0092f ] link_dp_irq_handler.c includes "link_dp_panel_replay.h" twice. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 1e5cd4adfc54 ("drm/amd/display: move panel replay out from edp") Signed-off-by: Anas Khan Reviewed-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c71783a6ed19ade183467897d3aafe3efc392bae Author: Dyllan Kobal Date: Tue Jun 23 00:58:04 2026 +0000 drm/amd/display: fix wrong register field in dccg35_set_hdmistreamclk_src_new [ Upstream commit db9c882f83d3f3e08069f52d0d2ebf9d131c9ae4 ] dccg35_set_hdmistreamclk_src_new() updates HDMISTREAMCLK_CNTL but passes DPSTREAMCLK0_SRC_SEL as the field identifier in the second REG_UPDATE_2 slot. The current behavior is harmless on DCN3.5 because both fields share the same bit layout, but it is still incorrect and could break on future hardware revisions. Fixes: d36771a03412 ("drm/amd/display: Add DCCG DIO, HPO, OPP, and OPTC support for FRL") Signed-off-by: Dyllan Kobal Reviewed-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7ccdcfbb8617c1224b5743c8ae47633843938ad2 Author: Gleb Markov Date: Mon Jun 29 16:09:06 2026 +0300 drm/amd/display: Remove unused-but-set variable hubp from [ Upstream commit b736792e5bd4a62f24e8d1e310bf4a75bfbeaaaa ] The final check of hubp for NULL covers all remaining lines of code, since the value of hubp does not change until the end of the method. This check is redundant because hubp1 is already dereferenced within the macro. If it were NULL, the program would have already failed to proceed. Remove the left part of the expression with the logical "&&". Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: be1fb44389ca ("drm/amd/display: Check null pointers before used"). Signed-off-by: Gleb Markov Reviewed-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6970ec944567f109ac4240f9aea58158ee8a18cd Author: Geoffrey McRae Date: Mon Jun 29 02:04:13 2026 +1000 drm/amd/display: Fix DM I2C teardown race [ Upstream commit e4ae30a12aa95942814957d8bc1ce7366a7107d7 ] DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr Fixes: 5b3eca05cfb0 ("drm/amd/display: Use devm_i2c_add_adapter to simplify i2c cleanup logic") Signed-off-by: Geoffrey McRae Acked-by: Alex Deucher Reviewed-by: Leo Li Cc: Alex Deucher Cc: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f0c4b7ca24d2e2618a70826881d69b237e36bcc0 Author: Gregor Herburger Date: Wed Jul 15 09:35:36 2026 +0200 OPP: Fix cleanup ordering [ Upstream commit ce46fede7792cedd247e34b48bc8a02eb90c7848 ] Commit 173e02d67494 ("OPP: Initialize scope-based pointers inline") added initialization for all pointers. In some cases, the ordering was changed so that *opp_table was initialized after *opp. This also changes the order of the registered cleanup functions. When the cleanup happens, this can cause use-after-free errors when the last reference is released and the release function _opp_kref_release tries to access the already freed opp->opp_table. Initialize *opp_table before *opp again to fix this and ensure the correct cleanup order. Fixes: 173e02d67494 ("OPP: Initialize scope-based pointers inline") Signed-off-by: Gregor Herburger Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 7d102d1f0631807a491a140f67c9628dea85dfd2 Author: Ruoyu Wang Date: Wed Jul 8 22:33:43 2026 +0800 media: ipu6: Do not free aux device pdata after init [ Upstream commit 9be07216af4cfc4813e1a46ce26407d31ea845de ] ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: cb3117b074ae ("media: intel/ipu6: add IPU auxiliary devices") Signed-off-by: Ruoyu Wang Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit de9be39cefda1ecd762e6a913665c01f7bb18100 Author: Eugen Hristev Date: Tue Jun 9 20:05:23 2026 +0300 media: bcm2835-unicam: Fix asc leaked in error/remove path [ Upstream commit 253c9659e25131b0169f718e7d094ac1aa0d9279 ] v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64 Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface") Signed-off-by: Eugen Hristev Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit c4b00825780a438a7847d2cb2fab7f6eff35d2c5 Author: Julian Braha Date: Sun Jul 12 00:59:39 2026 +0100 media: platform: amd: fix unmet dependency for VIDEO_V4L2_SUBDEV_API [ Upstream commit 95a99456ff354a1bad4b4032ed1d044d608bd438 ] Currently, VIDEO_AMD_ISP4_CAPTURE selects VIDEO_V4L2_SUBDEV_API without ensuring MEDIA_CONTROLLER is enabled, causing an unmet dependency: WARNING: unmet direct dependencies detected for VIDEO_V4L2_SUBDEV_API Depends on [n]: MEDIA_SUPPORT [=m] && VIDEO_DEV [=m] && MEDIA_CONTROLLER [=n] Selected by [m]: - VIDEO_AMD_ISP4_CAPTURE [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && DRM_AMDGPU [=m] && DRM_AMD_ISP [=y] && HAS_DMA [=y] && VIDEO_DEV [=m] Many other options in this subsystem select MEDIA_CONTROLLER, let's do the same here. This unmet dependency bug was detected by kconfirm, a static analysis tool for Kconfig. Fixes: 9a54c285630c ("media: platform: amd: Introduce amd isp4 capture driver") Signed-off-by: Julian Braha Reviewed-by: Bin Du Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 76511a617ae4bd5877bba878cdafda8acbead2f3 Author: Biren Pandya Date: Sun Jul 5 01:46:28 2026 +0530 media: i2c: rdacm21: Fix missing media_entity_cleanup() [ Upstream commit 04c053379c3a33460b581953c4f5b36de39439ac ] The driver misses calling media_entity_cleanup() on the probe error path and during remove, leaking resources if probe fails after entity initialization or when the driver is unloaded. Fix this by adding media_entity_cleanup() to the rdacm21_probe() error handling path and to rdacm21_remove(). Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 78cdd9438ad3bde614622db476a7d03e6d02da73 Author: Yemike Abhilash Chandra Date: Sun Jul 12 21:42:56 2026 +0530 media: ti: vpe: Select V4L2_FWNODE for VIP [ Upstream commit 46f563185b23443894c4d6aa86942851bda6f5dc ] The VIP driver uses v4l2_fwnode_endpoint_parse() and the v4l2_async_nf_*() notifier APIs, but its Kconfig entry does not select V4L2_FWNODE. Hence kernel test robot reports: vip.c:3236: undefined reference to `v4l2_async_nf_unregister' vip.c:3237: undefined reference to `v4l2_async_nf_cleanup' vip.c:3339: undefined reference to `v4l2_fwnode_endpoint_parse' vip.c:3346: undefined reference to `v4l2_async_nf_init' vip.c:3348: undefined reference to `__v4l2_async_nf_add_fwnode' vip.c:3357: undefined reference to `v4l2_async_nf_register' Select V4L2_FWNODE, which in turn selects V4L2_ASYNC, providing all the missing symbols. Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607031826.vOPABT39-lkp@intel.com/ Signed-off-by: Yemike Abhilash Chandra Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 7c614f83301d464e2fb498d63552490d137ea10d Author: Qingshuang Fu Date: Wed Jul 8 18:08:46 2026 +0800 irqchip/renesas-irqc: Fix generic interrupt chip leak on remove [ Upstream commit 616dd89d81ad9a3cf1cfff4088a4c43e4e00d6ba ] The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback. Fixes: 99c221df33fbfa1b ("irqchip/renesas-irqc: Move over to nested generic chip") Signed-off-by: Qingshuang Fu Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260708100846.506314-1-fffsqian@163.com Signed-off-by: Sasha Levin commit f58abff399f724ca923446c8ef71869a2944f402 Author: Yuho Choi Date: Tue Jun 30 16:29:38 2026 -0400 PCI: keystone: Fix OF node reference leak in init [ Upstream commit 3260336defeb292a91de29e4d1d93469e3cec663 ] of_find_matching_node() returns a device node with its reference count incremented. ks_pcie_init() only uses the returned node to decide whether to register the ARM external abort fault handler, but never drops the reference. Store the lookup result in a temporary variable and release it with of_node_put() once the existence check has been made. Fixes: bc10d0ad540d ("PCI: keystone: Add support to build as a loadable module") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260630202938.1877632-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 578ab48dc684c1b214fd4340f143e1fca1de3c4b Author: Yuho Choi Date: Tue Jun 30 15:52:34 2026 -0400 PCI: xgene: Drop unnecessary OF node reference [ Upstream commit 4869db344e76c9adfb1d9654df442db5371fac71 ] xgene_pcie_probe() stores dev->of_node in port->node with of_node_get(), but the cached node is only used during probe by xgene_pcie_parse_map_dma_ranges(). The driver never releases the extra reference, so the node reference is leaked. There is no need for private OF node ownership here. Use the device's existing of_node directly in xgene_pcie_parse_map_dma_ranges() and remove the cached port->node pointer. Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260630195234.1871951-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit f9ed38e80443acb7453fcbe6faea930ef37313bc 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 68682c9b7b8ca60f8e024b34c91c0f1cec8b5af1 Author: John Groves Date: Mon Jun 15 16:07:38 2026 +0000 dax: fix holder_ops race in fs_put_dax() [ Upstream commit 7a6db2eb6d5da9ade0d4802e25bbec3342ae0187 ] Clear holder_ops before holder_data so that a concurrent fs_dax_get() cannot have its newly installed holder_ops overwritten. cmpxchg() provides release ordering on weakly-ordered architectures, ensuring the WRITE_ONCE(holder_ops, NULL) store is visible to any CPU that observes the holder_data release. Add a WARN_ON() that fires only when the cmpxchg observes a non-NULL value that is not @holder, i.e. fs_put_dax() called by something that is not the current holder. That is an API contract violation; the WARN_ON() does not prevent the damage but makes the bug visible. A NULL cmpxchg result is deliberately tolerated: kill_dax() clears holder_data while a holder is still attached when a device is removed out from under a mounted filesystem (after delivering MF_MEM_PRE_REMOVE). The holder's subsequent fs_put_dax() - e.g. xfs_free_buftarg() after a forced shutdown - then legitimately finds holder_data already NULL, so warning on that case would turn supported device removal into a splat (or a panic with panic_on_warn). Also add a kerneldoc comment documenting that fs_put_dax() must only be called by the current holder. Fixes: eec38f5d86d27 ("dax: Add fs_dax_get() func to prepare dax for fs-dax usage") Signed-off-by: John Groves Reviewed-by: Alison Schofield Link: https://patch.msgid.link/0100019ecc09dcab-2f4aa175-0b84-4b36-9e54-ebff302ebb0a-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit eb412f80311fc7ab6eb3203091a3fe59a5e9fd30 Author: John Groves Date: Mon Jun 15 16:07:30 2026 +0000 dax: read holder_ops once in dax_holder_notify_failure() [ Upstream commit 7ae9d15bdcde0f2955ae13b6a95587f9e23b2359 ] dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value. Fixes: 8012b86608552 ("dax: introduce holder for dax_device") Suggested-by: Richard Cheng Reviewed-by: Richard Cheng Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc09bb56-5ecc9c6b-35ba-44f8-b112-921b01b34478-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit c8c16c2de91141ccdc01e611e0099b6a2c7ff40b Author: John Groves Date: Mon Jun 15 16:07:21 2026 +0000 dax/fsdev: fail probe on invalid pgmap offset [ Upstream commit 755effecd6fc7d8ff18f09135cb5e3cf98c20d55 ] Convert the WARN_ON to a fatal error when pgmap_phys > phys. This condition means the remapped region starts after the device's data region, which is an impossible state. Previously the probe continued with data_offset=0, leaving virt_addr silently misaligned. Now probe returns -EINVAL with a diagnostic message. Fixes: 759455848df0b ("dax: Save the kva from memremap") Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Reviewed-by: Pankaj Gupta Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc0999fa-97574544-8b6b-46cf-9f33-423abdbeee7f-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 7b642bd3d39105eef4d5908970726c5fda291b53 Author: John Groves Date: Mon Jun 15 16:07:10 2026 +0000 dax/fsdev: use __va(phys) for kaddr in direct_access [ Upstream commit ff7c73fca793bd5c29a15ba735b0886f62f3a840 ] Use __va(phys) instead of virt_addr + linear_offset for the kaddr return in __fsdev_dax_direct_access(). The previous code added a device-linear byte offset to virt_addr (which is __va of ranges[0]), but for multi-range devices with physical gaps between ranges, this linear arithmetic crosses the gap and produces a wrong kernel virtual address. Using __va(phys) where phys comes from dax_pgoff_to_phys() is correct for any range layout because the direct map translates each physical address independently. This leaves dev_dax->virt_addr write-only, so remove the field (suggested by Dave Jiang). Fixes: 759455848df0b ("dax: Save the kva from memremap") Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc096de8-8bc254a7-d2cc-44b6-82b1-1394fda8bb41-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 9b0f91dc9147a8601cec3d4d83cf13c6aaf71b27 Author: John Groves Date: Mon Jun 15 16:07:01 2026 +0000 dax/fsdev: clear pgmap ops and owner on unbind [ Upstream commit f48884ac31b6bfc99f36b3f207b8c0cbe5d54bd7 ] fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic device the pgmap is devm-allocated and freed on unbind, so this is harmless. For a static device the pgmap is the shared, long-lived one owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the non-static case), and device.c's probe sets only pgmap->type, never clearing ops/owner. So after fsdev unbinds a static device the stale fsdev_pagemap_ops survives on the shared pgmap. If the device is then rebound to device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure), or the fsdev_dax module is unloaded, a subsequent memory_failure on that pgmap dispatches through the stale -- and possibly freed -- handler. Register a devm action that clears pgmap->ops and pgmap->owner on unbind, symmetric with setting them at probe, so the pgmap carries no fsdev state once fsdev is detached. Suggested-by: Richard Cheng Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax") Signed-off-by: John Groves Reviewed-by: Richard Cheng Link: https://patch.msgid.link/0100019ecc094b6e-fc163bde-0396-4a33-909f-fb88e740be27-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 93c5509033e47c95ea2dc6ec06f4171a441e3071 Author: John Groves Date: Mon Jun 15 16:06:53 2026 +0000 dax/fsdev: don't leave a dangling dev_dax->pgmap on probe failure [ Upstream commit caf906009d12cb21b934f1c4d17cedc6d469429f ] After the dynamic path set dev_dax->pgmap, any later probe failure left dev_dax->pgmap dangling: devres frees the devm_kzalloc'd pgmap on probe failure, and subsequent probe attempts would hit the "dynamic-dax with pre-populated page map" check and fail permanently. Factor pgmap acquisition out into fsdev_acquire_pgmap(), and defer the dev_dax->pgmap assignment until probe can no longer fail. A failed probe now never publishes the pointer at all, so there is nothing to unwind. This also matches kill_dev_dax(), which already clears the dynamic pgmap pointer on unbind: dev_dax->pgmap is now non-NULL only while the pgmap is actually valid. Refactor suggested by Dave Jiang. Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax") Reviewed-by: Dave Jiang Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc092ca1-ffc7a5fd-1252-4be5-882c-fd5efdc102a9-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit d298a0513aaf7d48f2a9f4a90041de910750cfcf Author: John Groves Date: Mon Jun 15 16:06:46 2026 +0000 dax/fsdev: clear vmemmap_shift when binding static pgmap [ Upstream commit e0239229931faf9ca3367e3befcf16f77b2cd45b ] Clear pgmap->vmemmap_shift for static DAX devices. When rebinding a static device from device_dax (which may set vmemmap_shift based on alignment) to fsdev_dax, the stale vmemmap_shift persists on the shared pgmap. Explicitly zero it before devm_memremap_pages() so the vmemmap is built for order-0 folios as fsdev requires. Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax") Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc090eea-7c46f51e-5393-402c-850d-78059bb6d343-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 58db9b927866b0a23a69f1ab199e7a1643dd8242 Author: John Groves Date: Mon Jun 15 16:06:32 2026 +0000 dax/fsdev: fix multi-range offset in memory_failure handler [ Upstream commit e0cb40c3c676786c92ddb7f891a928ce970d6244 ] Fix memory_failure offset calculation for multi-range devices. The old code subtracted ranges[0].range.start from the faulting PFN's physical address, which produces an incorrect (inflated) logical offset when the PFN falls in ranges[1] or beyond due to physical gaps between ranges. Add fsdev_pfn_to_offset() to walk the range list and compute the correct device-linear byte offset relative to ranges[0].start (the device data start) -- the base the holder (xfs, famfs) maps from -- for both static and dynamic devices. V5 walked the pagemap's immutable pgmap->ranges[] instead, to avoid reading the mutable dev_dax->ranges[] from this callback. That had a different problem: it regressed static devices, where pgmap->ranges[0].start can sit data_offset below the data start, so the reported offset came out data_offset too high and the holder would act on the wrong blocks. For dynamic devices the two arrays are identical, so pgmap->ranges[] only ever helped the dynamic case while breaking the static one. Walk dev_dax->ranges[] instead. (Richard Cheng spotted the static regression.) Reading dev_dax->ranges[] here may race a concurrent krealloc() of the range array via sysfs (mapping_store(), under dax_region_rwsem, which this ->memory_failure callback does not hold). That exposure is pre-existing -- the original single-range code read dev_dax->ranges[0] locklessly as well -- so this patch does not make it worse; a proper fix (locking or snapshotting) belongs in a separate change. Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax") Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Signed-off-by: John Groves Reviewed-by: Richard Cheng Link: https://patch.msgid.link/0100019ecc08d74f-ec0d09b8-11e9-4e5b-af48-8c6d382af486-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 154540d584ae1c5e689db87a3024ac46b7d27520 Author: John Groves Date: Mon Jun 15 16:06:24 2026 +0000 dax: fix misleading comment about share/index union in dax_folio_reset_order() [ Upstream commit 3fc3ebf40b5cf077829d8fc5c66ece5b4c6e66c7 ] The comment in dax_folio_reset_order() claims that DAX maintains an invariant where folio->share != 0 only when folio->mapping == NULL, implying folio->share is zero whenever mapping is non-NULL. This is misleading because folio->share and folio->index are a union -- for non-shared folios with mapping != NULL, reading folio->share returns the file page offset (folio->index), which is typically non-zero. Reword the comment to accurately describe the union aliasing: the assignment clears whichever interpretation of the union word is active (index for non-shared folios, share for shared folios), which is correct because the folio is being released in either case. No functional change -- the code was already correct, only the justification was wrong. Fixes: 59eb73b98ae0b ("dax: Factor out dax_folio_reset_order() helper") Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc08b8cd-4ee80eeb-1341-4f67-8478-7298129440e9-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 6beaef33ee5684e2ecd739f3ce0828d6bd5e10b0 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 a8e3a0e8997deb886278898a0b6f19374f49d111 Author: Liang Luo Date: Tue Jul 14 11:20:51 2026 +0800 tools/sched_ext: scx_qmap: Fix stale API name in comment [ Upstream commit 35f9cbbacb671e587c84e992e7b0098c39e895a4 ] The comment above dispatch_highpri() still references scx_bpf_dispatch[_vtime]_from_dsq(), which was renamed to scx_bpf_dsq_move[_vtime]() in v6.13 to unload the overloaded "dispatch" verb. The code below already uses the new names; only the comment was left behind during the rename. Fixes: 5cbb302880f5 ("sched_ext: Rename scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*()") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 92a4e01e2ef89c0a1e2cbfea26568f6bee1ae34f Author: Dan Carpenter Date: Fri Jul 10 22:34:44 2026 +0300 regulator: adp5055: Fix error code in adp5055_of_parse_cb() [ Upstream commit 153bc959ce0f91b4446fb6fb805b8c1d2ca20c75 ] This code accidentally returned the wrong variable instead of a negative error code. Return -EINVAL. Fixes: 147b2a96f24e ("regulator: adp5055: Add driver for adp5055") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/alFJVBbiFNxhqa_1@stanley.mountain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca95b15a0760e7724e61addbdd61050be13b6406 Author: Richard Cheng Date: Fri Jun 26 18:41:02 2026 +0800 cxl/features: Clamp Get Feature output size to the remaining buffer [ Upstream commit 2aeb21fe557ef154f0cdf4f9745ebd8d5b31ca83 ] cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity. Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Signed-off-by: Richard Cheng Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-4-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 16b7c99eff030c6ea11ca24efa4b9f989cc74093 Author: Richard Cheng Date: Fri Jun 26 18:41:01 2026 +0800 cxl/features: Reject Set Features output buffer smaller than the header [ Upstream commit cde18d6c1d913a67ab0afd3d9475ece4be79da50 ] cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required. Fixes: eb5dfcb9e36d ("cxl: Add support to handle user feature commands for set feature") Signed-off-by: Richard Cheng Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-3-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 329ea475581c647a680a6937e353c1a6e2534b40 Author: Richard Cheng Date: Fri Jun 26 18:41:00 2026 +0800 cxl/features: Reject Get Feature count larger than the output buffer [ Upstream commit 4bf6bac375076ced2fa4b3fef8739bd985f93456 ] cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating. Fixes: 5908f3ed6dc2 ("cxl: Add support to handle user feature commands for get feature") Reviewed-by: Kai-Heng Feng Reviewed-by: Koba Ko Reviewed-by: Dave Jiang Signed-off-by: Richard Cheng Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-2-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 4635953b4c1af477e166073521a77de6279f6929 Author: Sudeep Holla Date: Tue Jul 14 13:56:35 2026 +0100 firmware: arm_scmi: Fix transport device teardown lookup [ Upstream commit a14dd8fe0a95db638c550ed984cfe2a7428c783d ] SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails. Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-16-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit c59b3393df1348a12308aaabd5fbc58ed6b21cf5 Author: Sudeep Holla Date: Tue Jul 14 13:56:34 2026 +0100 firmware: arm_scmi: Fix SCMI device destroy lifetimes [ Upstream commit 6abe8fe36b29ff51d1a42c2f338972883f4751a5 ] scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again. Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-15-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3515aed7fe424b79c49ff9cd51f7802a64a4ab7b Author: Sudeep Holla Date: Tue Jul 14 13:56:33 2026 +0100 firmware: arm_scmi: Unwind P2A receiver mailbox setup failure [ Upstream commit f3e3773c4e5e96549d7540d8ddeb4fcd534f6f1d ] mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: fa8b28ba22d9 ("firmware: arm_scmi: Add support for platform to agent channel completion") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-14-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 9958f55eace8b43713c9fc54dcf90e7cdefee413 Author: Sudeep Holla Date: Tue Jul 14 13:56:32 2026 +0100 firmware: arm_scmi: Unwind TX receiver mailbox setup failure [ Upstream commit 6f7c06744d53dc8e047725d411d7f915d9ec35ae ] mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: 9f68ff79ec2c ("firmware: arm_scmi: Add support for unidirectional mailbox channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-13-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 45e54438f4fd814a4c2f7ed9f974c32c133ee7dd Author: Sudeep Holla Date: Tue Jul 14 13:56:31 2026 +0100 firmware: arm_scmi: Fix OF node reference handling [ Upstream commit 659705f5eb378cea462214b74bdc6240cdab53fc ] SCMI devices store the DT node in dev.of_node through device_set_node(), but that helper only assigns the fwnode and of_node pointers without taking an OF node reference. Take a reference when assigning the node and release it from the SCMI device release path. With the device owning that reference, remove the separate channel-side get/put pair from the core driver. Fixes: 96da4a99ce50 ("firmware: arm_scmi: Set fwnode for the scmi_device") Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-12-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3f4cf1edf73652b55933bee12f7e42685abfde36 Author: Sudeep Holla Date: Tue Jul 14 13:56:30 2026 +0100 firmware: arm_scmi: Clear SystemPower flag on create failure [ Upstream commit e4c16ae24ca027d7a72d645b42f976bb3e99b4b0 ] __scmi_device_create() reserves the singleton SystemPower protocol device before registering the SCMI device. If any later step fails, a stale reservation can make a later retry reject SystemPower device creation permanently, for example after probe deferral. A plain global boolean is not enough to track the reservation. A delayed final release of an older SystemPower device could clear the boolean after a newer device has already claimed it, breaking the singleton guarantee for the active device. Track the reservation with the scmi_device pointer itself. Claim it with cmpxchg(NULL, scmi_dev) after allocating the device object, and release it with cmpxchg(scmi_dev, NULL) from the common cleanup helper. This lets the create-failure, explicit destroy and final release paths clear only the reservation owned by the device being cleaned up. Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-11-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 77d2985d1e80e67f32026fc03e975c4c83cc543d Author: Sudeep Holla Date: Tue Jul 14 13:56:29 2026 +0100 firmware: arm_scmi: Drop handle on protocol bind failures [ Upstream commit e3a5c30d233ca5d3e799a80da806554c703bda13 ] The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition. Fixes: 971fc0665f13 ("firmware: arm_scmi: Move handle get/set helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-10-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 09d08581ead9721dd5d2f096d71b138baa115c63 Author: Sudeep Holla Date: Tue Jul 14 13:56:28 2026 +0100 firmware: arm_scmi: Protect device request lookup with RCU [ Upstream commit e6a0e7a49d83e4fa4e1db68d74f99282eb97aa49 ] The SCMI device request notifier looks up protocol OF nodes from the active_protocols IDR. The IDR lookup can run concurrently with protocol activation while probe is still registering protocols and creating their SCMI devices. Wrap the lookup in an RCU read-side critical section as required by the IDR API for lockless readers. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-9-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit ad39c232ffac76f1a5030e36d170c8b21e6bd44a Author: Sudeep Holla Date: Tue Jul 14 13:56:27 2026 +0100 firmware: arm_scmi: Use channel ID for transport teardown [ Upstream commit a71a3d4d8a6e9e399fd988c0e6da47a6ee21c99e ] SCMI protocols can share the BASE transport channel when firmware does not describe a dedicated channel for the protocol. In that case multiple IDR entries can point at the same scmi_chan_info, whose owning transport device was created with cinfo->id. scmi_chan_destroy() used the IDR iterator key when destroying the transport device. If an alias entry is visited before the owning channel entry, the lookup can miss the device because the iterator key does not match the protocol ID used when the transport device was created. The code then clears cinfo->dev, so the later owning entry skips teardown and leaks the transport device. Destroy the transport device using cinfo->id, which is the protocol ID that owns the channel and was used when creating the transport device. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-8-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 0b6e59eb885f985a5ea7beed385adfa9412b324d Author: Sudeep Holla Date: Tue Jul 14 13:56:26 2026 +0100 firmware: arm_scmi: Reject out of range DT protocol IDs [ Upstream commit 59407ccb52130f2c81f4b3cbe4f14114afceb54f ] SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-7-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit bab26acebe55e8ad3ab545abda72faa7ca28c477 Author: Sudeep Holla Date: Tue Jul 14 13:56:25 2026 +0100 firmware: arm_scmi: Avoid IDR updates while cleaning channels [ Upstream commit c38b1e19485aaa820e52cfe162525a8af67563da ] scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-6-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit fbaebd380caa4e1cec9306ca00231da6518a123f Author: Sudeep Holla Date: Tue Jul 14 13:56:24 2026 +0100 firmware: arm_scmi: Free transport channel on IDR failure [ Upstream commit d72e7e5f24687c0490aabf317653caffe0447aeb ] If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-5-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 43aad7687238d6178cb3fdac53c8de3f43bfa028 Author: Sudeep Holla Date: Tue Jul 14 13:56:23 2026 +0100 firmware: arm_scmi: Clean up channels on setup failure [ Upstream commit 687d67be3d87894ef12e8a164434612e0b53cfae ] scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-4-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 5e30d3d16d1a9e599be4dcea872874e65e2c277b Author: Sudeep Holla Date: Tue Jul 14 13:56:22 2026 +0100 firmware: arm_scmi: Quiesce notifications before teardown [ Upstream commit 8e49055d0d495c9c07575ad8e111d9eaf0efb13f ] scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts. Fixes: 1e7cbfaa66d3 ("firmware: arm_scmi: Free mailbox channels if probe fails") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-3-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 74fcaa0a3f7ad3edfde2e8c6cb8ae457a00e0b7a Author: Sudeep Holla Date: Tue Jul 14 13:56:21 2026 +0100 firmware: arm_scmi: Unregister device notifier before IDR teardown [ Upstream commit 66a0bbf30cc14140fe13f63cd594a7c1ee352b75 ] The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-2-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit a1bc587568a4e373db76261dc9561dfc3653917f Author: Sudeep Holla Date: Tue Jul 14 13:56:20 2026 +0100 firmware: arm_scmi: Publish channel state before callbacks [ Upstream commit 0314900dcdde044af0208fed212035dbfaa55843 ] Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-1-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 54be1b7c1eb80ece8dcd1cf88856cdac569f54ee Author: David Stevens Date: Fri Apr 24 12:14:54 2026 -0700 x86/entry/fred: Encode frame pointer on entry [ Upstream commit dab01c597f6bd40e0efe7da967b8374ca1971b79 ] Add missing ENCODE_FRAME_POINTER macro invocation into FRED_ENTER macro, to prevent the unwinder from encountering a NULL stack frame pointer when CONFIG_UNWINDER_FRAME_POINTER is enabled Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: David Stevens Signed-off-by: Dave Hansen Acked-by: H. Peter Anvin (Intel) Link: https://patch.msgid.link/20260424191456.2679717-12-stevensd@google.com Signed-off-by: Sasha Levin commit ccbd20f2168f581d90265da1a925b9b6472a0b05 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 3dfa1b8ccf7c3889b1c13dd3eede7d7e10ffa69c Author: Wei Zhang Date: Sun Jun 28 23:15:28 2026 -0700 wifi: ath12k: fix rx_mpdu_start layout for QCC2072 [ Upstream commit 9eb29fd47595e8128775f8ac57ca671238cb798a ] QCC2072's rx_mpdu_start TLV has a different field layout from QCN9274. Reusing struct rx_mpdu_start_qcn9274 in hal_rx_desc_qcc2072 causes the RX datapath to read the wrong offsets for info2, info4, pn[] and phy_ppdu_id, producing corrupted sequence number, PN, ppdu_id and mpdu-info flags (encrypted, fragment, addr2/addr4 valid). Add a dedicated struct rx_mpdu_start_qcc2072 that matches the actual hardware descriptor layout, and use it in hal_rx_desc_qcc2072. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00188-QCACOLSWPL_V1_TO_SILICONZ-1 Fixes: 28badc78142e ("wifi: ath12k: add HAL descriptor and ops for QCC2072") Signed-off-by: Wei Zhang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260629061529.1993932-1-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 329b10ddc919b8b3c0a847bde991517afe4ab2d5 Author: Baochen Qiang Date: Mon Jun 29 15:01:18 2026 +0800 wifi: ath12k: fix MLO peer delete race [ Upstream commit 01cc0f59aac3574b6a7b02493a76bc8ed0aa758f ] ath12k_peer_mlo_link_peers_delete() sends WMI peer_delete for every link before waiting for any peer_unmap / peer_delete_resp event. The shared per-radio completion ar->peer_delete_done could not disambiguate which peer a response was for: every call to ath12k_peer_delete_send() did reinit_completion(&ar->peer_delete_done), so when an event for the first link arrived between two sends it raised the count to 1 and the second send promptly cleared it; the wait for the second link then timed out with Timeout in receiving peer delete response Replace the shared completion with a per-radio waiter list, with each pending ath12k_peer_delete() caller queueing an ath12k_peer_delete_wait carrying its (vdev_id, addr) and a private struct completion. ath12k_peer_delete_resp_event() matches the response against the list under ar->data_lock and signals the matching waiter. Also correct the endian conversion in ath12k_peer_delete_resp_event() logging, and add the missing \n in some logging. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: 8e6f8bc28603 ("wifi: ath12k: Add MLO station state change handling") Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260629-ath12k-mlo-peer-delete-race-v2-2-362b25590d19@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit af405d216316d99f9b48733145fc708110011e0f Author: Baochen Qiang Date: Mon Jun 29 15:01:17 2026 +0800 wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback [ Upstream commit f066e1a93703c5be0fd905109d00587541711c97 ] ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via ath12k_peer_create(), which finishes by calling ath12k_dp_link_peer_assign() to publish the dp_link_peer in the dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's link_peers[] array, and in the per-addr rhashtable. If a step after ath12k_peer_create() fails the function jumps to err_peer_del, which open-codes a WMI peer_delete and waits for the unmap / delete_resp events. The wait_for_peer_delete_done() path relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer when the unmap arrives, but err_peer_del never calls ath12k_dp_link_peer_unassign() first. The published references in the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are left pointing at the dp_link_peer that unmap_event then frees, producing dangling pointers and use-after-free on subsequent lookups. Replace the open-coded sequence with a call to ath12k_peer_delete(), which already does ath12k_dp_link_peer_unassign() before sending the WMI command. This drops the published references before the dp_link_peer is freed, in the same order as the normal teardown path in ath12k_mac_remove_link_interface(). Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: 5525f12fa671 ("wifi: ath12k: Attach and detach ath12k_dp_link_peer to ath12k_dp_peer") Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260629-ath12k-mlo-peer-delete-race-v2-1-362b25590d19@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 473ea7aa35615829f0de7a71e8691d69dc24e328 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 8e0c487b0b1b544c60f37275f62f35c547bcce20 Author: Alison Schofield Date: Mon Jul 13 19:04:35 2026 -0700 cxl/port: Restart port enumeration when a sibling adds the dport first [ Upstream commit a623128bc2a1c257cbad97d0582f355fbe7be927 ] Endpoint probes can race while enumerating a shared switch. If a sibling probe adds the dport first, the losing probe finds the dport already present, gets -EBUSY, and fails to enumerate the endpoint. Treat this race the same as the existing port-created case by restarting the port walk, allowing it to find the existing dport and continue enumeration. This race was discovered while testing a cxl_test mixed-granularity topology, where twelve endpoints behind shared switches are probed in parallel during module load. Fixes: 4f06d81e7c6a ("cxl: Defer dport allocation for switch ports") Signed-off-by: Alison Schofield Tested-by: Li Ming Reviewed-by: Li Ming Link: https://patch.msgid.link/20260714020438.1822669-1-alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 7682b617db1f19bc606b5f1badadcf1e63a87b14 Author: Dave Jiang Date: Thu Jul 9 08:58:41 2026 -0700 cxl/features: Serialize multi-part Get/Set Feature transfers [ Upstream commit 77b814c1832fde018c30357b4ec3fcdaa91a1c10 ] A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=1 Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Fixes: 14d502cc2718 ("cxl/mbox: Add SET_FEATURE mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Richard Cheng Link: https://patch.msgid.link/20260709155841.1895915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit ada7aa90eb65d5a561e9766add365e379df7a616 Author: Dave Jiang Date: Mon Jul 6 15:43:22 2026 -0700 cxl/pci: Honor -EPROBE_DEFER from component register setup [ Upstream commit 430c502c80e542e77bcf97db13ec0e8cdf9addb0 ] cxl_pci_setup_regs() for CXL_REGLOC_RBI_COMPONENT can return -EPROBE_DEFER on a Restricted CXL Host (RCD) when the upstream port has not yet been enumerated and the Component Registers must be extracted from the RCRB. cxl_pci_probe() treats every non-zero return from that call as the benign "component registers not found" case, logs a warning, and continues. The rc is then immediately overwritten by the subsequent cxl_pci_type3_init_mailbox() call, so the deferral is silently swallowed. Return -EPROBE_DEFER instead of continuing so the probe is retried once the upstream port is available. Fixes: 733b57f262b0 ("cxl/pci: Early setup RCH dport component registers from RCRB") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Link: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Link: https://patch.msgid.link/20260706224322.714934-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit e77594e0cea67ab1c2317a27aa77a744e26ad6a6 Author: Dave Jiang Date: Thu Jul 9 08:57:14 2026 -0700 cxl/mbox: Break poison list loop on an empty payload [ Upstream commit 8b301c4afbce4bc3f94528441d8d5ce1366504ad ] A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing "Protect against an uncleared _FLAG_MORE" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=3 Fixes: ed83f7ca398b ("cxl/mbox: Add GET_POISON_LIST mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260709155714.1893280-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 5354222bef789758f44cc902c72b701a55ee2f3a Author: Guzebing Date: Mon Jul 13 19:27:44 2026 +0800 cxl/memdev: Fix firmware upload exact-fit handling [ Upstream commit af5035e1b3e400067bb003975936e5407377e7a3 ] cxl_fw_prepare() classifies a firmware image as a one-shot transfer only when its Transfer FW input payload is smaller than the mailbox payload size. An image that exactly fills the payload is therefore treated as a multi-part transfer. The firmware loader invokes cxl_fw_write() only once for that image. Since both offset == 0 and remaining == 0, the multi-part action selection sends INITIATE, never sends END, and then attempts to activate the target slot. Include equality in the one-shot classification so exact-fit images use the FULL action. Fixes: 9521875bbe00 ("cxl: add a firmware update mechanism using the sysfs firmware loader") Signed-off-by: Guzebing Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260713112744.2543829-1-guzebing1612@gmail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit dc0a119613617047db9fcbd746e04f57428e258d Author: Li Ming Date: Mon Jul 13 14:15:31 2026 +0800 cxl/test: Rework cxl_type2_mem_init() to use cxl_mock_platform_device_add() [ Upstream commit 9515af581da976911aea820175afb05be803ae8c ] cxl_type2_mem_init() is used to set up mock CXL type2 memory device for cxl testing, it introduces a known bug fixed by the following commit: commit d90f236f8b9e ("cxl/test: Update mock dev array before calling platform_device_add()") Mock CXL devices require updating the mock device array prior to platform_device_add(), otherwise, the CXL subsystem could fail to recognize the newly added mock device. Switch to cxl_mock_platform_device_add() helper to resolve this ordering issue. Besides, this patch also includes two minor changes. 1. Preserve the original error code returned by cxl_mock_platform_device_add(), rather than unconditionally overriding it with -ENOMEM. 2. Drop redundant NULL check before platform_device_unregister(), as the function internally handles NULL pointer. Fixes: 6b2e585142e6 ("cxl/test: Add hierarchy enumeration support for type2 device") Signed-off-by: Li Ming Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260713061531.56322-1-ming.li@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 455e817515ffc5e5d6331215f6a372a637caed6d Author: Jason Gunthorpe Date: Mon Jul 13 14:09:46 2026 -0300 iommufd: Simplify iommufd_device_remove_vdev() [ Upstream commit 8062148046e1a6417d44e2ed86c04e66c2f4f2a1 ] Peiyang reports that this function indirectly includes a fault injection point through iommufd_get_object() that was intended to cover the uAPI use of object IDs, not in places like this that cannot fail. On deeper inspection this can be written using a dedicated helper to obtain a users refcount relying entirely on the xa locking instead of going through the whole get/put scheme. The new helper doesn't need the fault injection point. Fixes: 850f14f5b919 ("iommufd: Destroy vdevice on idevice destroy") Link: https://patch.msgid.link/r/0-v1-719003d53a5b+38b-iommufd_fault_inj_vdev_jgg@nvidia.com Reported-by: Peiyang He Closes: https://lore.kernel.org/r/870BB9ADBBEDDD1A+37c5bfab-ad32-4fc5-a302-57c81a8432b5@smail.nju.edu.cn Reviewed-by: Nicolin Chen Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 795113f9da49f23edc97d2130d3d4dcb9e2cd291 Author: Lad Prabhakar Date: Wed Jul 8 18:28:49 2026 +0100 arm64: dts: renesas: r9a09g047: Fix PCIe dma-ranges memory space code [ Upstream commit 24afcb87e6aca1ff3face276223eeea0012f8e2b ] The RZ/G3E SoC supports up to 8 GiB of memory. Update the PCIe dma-ranges property to use the 64-bit prefetchable memory space code. Fixes: 1ac57c9830cb ("arm64: dts: renesas: r9a09g047: Add PCIe node") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260708172849.227915-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 531ff98bcec503f2a21babf93f0ae29df3b5c714 Author: Lad Prabhakar Date: Wed Jul 8 18:28:48 2026 +0100 arm64: dts: renesas: r9a09g056: Fix PCIe dma-ranges memory space code [ Upstream commit 3e7259fb8a31c8b784628cfc417998447b0e5629 ] The RZ/V2N SoC supports up to 8 GiB of memory. Update the PCIe dma-ranges property to use the 64-bit prefetchable memory space code. Fixes: 4c443296ff17 ("arm64: dts: renesas: r9a09g056: Add PCIe node") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260708172849.227915-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 92425d1fdebc4242bf4160d6da26651a58bab148 Author: Lad Prabhakar Date: Thu May 28 14:47:50 2026 +0100 arm64: dts: renesas: rzt2h-n2h-evk: Remove unused MII/GMII pins [ Upstream commit c49ad13019771d5161290dc0eacb3ff6186c0953 ] Remove the unused TXER, RXER, CRS, and COL pinmux configurations from the gmac1 (ETH3) and gmac2 (ETH2) pin groups. The Ethernet interfaces on both the RZ/T2H and RZ/N2H EVK boards operate in RGMII mode, which does not utilize these extra MII/GMII sideband signal pins. Update the board switch configuration comments to accurately reflect the pin ranges that are actually in use. Fixes: b272b94fd2239 ("arm64: dts: renesas: rzt2h-n2h-evk: Enable Ethernet support") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260528134752.79813-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit e559626bee8a6632aafc08eedcdb4bf26ca245c5 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 b86dbfe4583bf134932a6cc45bf25b12c10a0b2f Author: Reinette Chatre Date: Mon Jul 13 10:39:43 2026 -0700 fs/resctrl: Fix UAF from worker threads when domains are removed [ Upstream commit 2566b5cd6a275c124e8f154fef6e815f92ec8d5c ] The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains. Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing") Closes: https://sashiko.dev/#/patchset/20260429184858.36423-1-tony.luck%40intel.com # [1] Reported-by: Sashiko Co-developed-by: Tony Luck Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/3f0e0752deb3421606dfc4600f0ab3a4ae098cd7.1783963505.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit 6bd8bfb85257be8e65cff1d9e566aa99418edb96 Author: Dmitry Ilvokhin Date: Wed Jul 8 13:38:34 2026 +0000 perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push [ Upstream commit ad40a000ea598f316ddc0e81e5acc77cc3b1fae0 ] With Zstd compression enabled ('perf record -z'), a single mmap push whose compressed output exceeds the maximum record size makes zstd_compress_stream_to_records() emit several PERF_RECORD_COMPRESSED2 records back to back. record__pushfn() however rewrote only the first record's header to describe the whole blob as one record: event->data_size = compressed - sizeof(struct perf_record_compressed2); event->header.size = PERF_ALIGN(compressed, sizeof(u64)); padding = event->header.size - compressed; ... record__write(rec, map, &pad, padding); perf_event_header::size is a __u16, so once the compressed blob no longer fits in it the header.size assignment truncates and 'padding' (size_t) underflows. write() is then handed that bogus length and fails with EFAULT, aborting the recording: failed to write perf data, error: Bad address The bytes that did reach the file are mis-framed, so reading it back cannot be decompressed. This is easy to hit with a high event rate and a large buffer, e.g.: perf record -z -F max -m 32M --per-thread -- perf test -w thloop 5 1 The single-record fixup is wrong by construction: because header.size is 16 bits a compressed record cannot exceed 64KB, so the compressor must split a push into a chain of records, and the session reader already consumes them as such. Frame each record where it is produced instead: make process_comp_header() set the per-record data_size, 8-byte-align header.size and zero the trailing padding, and let record__pushfn() write the resulting blob, as the AIO path already does. Reduce max_record_size by sizeof(u64) so the per-record alignment padding cannot push header.size past its u16 field. process_comp_header() returns -1 when that padding would not fit the space left in 'dst', so the compressor stops instead of overrunning the output buffer. There is no on-disk format change; a perf.data written by the fixed tool is still read by existing perf. Fixes: 208c0e168344 ("perf record: Add 8-byte aligned event type PERF_RECORD_COMPRESSED2") Reported-by: Farid Zakaria Signed-off-by: Dmitry Ilvokhin Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9f06abd2f64f5d0fee0e548119ea43f6885117ac Author: Dmitry Ilvokhin Date: Wed Jul 8 13:38:33 2026 +0000 perf record: Return the written size from process_comp_header() [ Upstream commit 757155c142f2bc9793e888ab101a5eea2d53f8f8 ] process_comp_header() is called from zstd_compress_stream_to_records() twice per record: once with data_size == 0 to write the record header, and once with the payload size to finalize it. It returns the increment it was passed, and the loop separately decides whether a record still fits by comparing the remaining 'dst_size' against the header size. With the fit check split from the code that writes the record, process_comp_header() cannot reject a record on its own, so any bytes it writes into 'dst' have to be bounds-checked by the caller instead of where they are produced. Pass the space left in 'dst' to process_comp_header(), let it return the number of bytes written or -1 when the header does not fit, and account the compressed payload in the loop. No functional change intended. Signed-off-by: Dmitry Ilvokhin Signed-off-by: Namhyung Kim Stable-dep-of: ad40a000ea59 ("perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push") Signed-off-by: Sasha Levin commit 4c593c62c1499665baebbb41b70e2c9b7e947b86 Author: Reinette Chatre Date: Mon Jul 13 10:39:40 2026 -0700 fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() [ Upstream commit f5bcf539484d2d604c2f2330e09487ea090b21c7 ] A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure. The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check. Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive. The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored. [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ] Fixes: b8511ccc75c0 ("x86/resctrl: Fix use-after-free when deleting resource groups") Closes: https://sashiko.dev/#/patchset/20260515193944.15114-1-tony.luck%40intel.com?part=1 Reported-by: Sashiko Assisted-by: GitHub_Copilot:gemini-3.1-pro Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ben Horgan Reviewed-by: Tony Luck Link: https://patch.msgid.link/8d028bbea582dc382a4cc166b235f75bd5901aea.1783963505.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit 5116fef23016e9774c223e6a11d19282b43b77c8 Author: Liang Luo Date: Mon Jul 13 15:18:08 2026 +0800 tools/sched_ext: scx_flatcg: Fix uninitialized stats on allocation failure [ Upstream commit e07f6bb73efb484043e7fc2ec6d7d6220d1977f7 ] In fcg_read_stats(), the memset() that zeroes the output @stats array sits after the calloc() failure check. When calloc() fails, the function returns without writing @stats. The caller in main() declares acc_stats uninitialized, passes it as the @stats argument, and then reads it unconditionally: __u64 acc_stats[FCG_NR_STATS]; fcg_read_stats(skel, acc_stats); stats[i] = acc_stats[i] - last_stats[i]; // reads garbage Because fcg_read_stats() returns void, the caller cannot detect the failure. Reading the uninitialized array is undefined behavior, and the garbage is further copied into last_stats via memcpy(), corrupting the baseline used by the next interval. This regression was introduced by commit cabd76bbc036 ("tools/sched_ext: scx_flatcg: fix potential stack overflow from VLA in fcg_read_stats"), which replaced the VLA with calloc() and inserted the failure check before the existing memset(). Move the memset() above the calloc() failure check so @stats is always zeroed regardless of allocation outcome. Fixes: cabd76bbc036 ("tools/sched_ext: scx_flatcg: fix potential stack overflow from VLA in fcg_read_stats") Signed-off-by: Liang Luo Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9fb74dce5c650cb23b60f6ba0ffcd5024e948a75 Author: Hans Verkuil Date: Mon Jun 29 08:47:05 2026 +0200 media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream commit 4e72f13d58c4245c177a9d5f54579345554f354d ] When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called. Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities") Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fb66f61a8e7529acf4db7034c3898100fdd9b318 Author: Sami Tolvanen Date: Thu Jun 11 22:17:21 2026 +0000 rust: drm: gpuvm: require Send + Sync for the driver's associated data [ Upstream commit b59ec72fec247b90dc26f17c5b1ee9f1e0fe334c ] DriverGpuVm permitted !Send/!Sync associated data on an abstraction whose handles are shared and dropped across threads: obtain() runs from many threads and the VA API performs deferred cross-thread drops. That is unsound. Require Send + Sync on the trait and its associated data so the GpuVm and UniqueRefGpuVm handle impls need no per-impl bounds. Fixes: 82b78182eacf ("rust: drm: add base GPUVM immediate mode abstraction") Signed-off-by: Sami Tolvanen Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-1-6c7f4ab2778a@google.com Signed-off-by: Alice Ryhl Signed-off-by: Sasha Levin commit 59c557d2474c314bd7fda58e1afa8339cc57de64 Author: Samuel Moelius Date: Sun Jun 28 15:23:32 2026 +0000 iommufd/selftest: Avoid selftest dirty bitmap size wrap [ Upstream commit 4132ba2ae2cf14c289e3fabc1c95ac244d643356 ] IOMMU_TEST_OP_DIRTY sizes its temporary dirty bitmap from length / page_size. Very large selftest ranges can make the DIV_ROUND_UP() additions wrap before allocation, producing a zero-length allocation while the later test_bit() loop still walks the original number of bits. The selftest helper does not need to support unbounded dirty bitmap sizes. Reject requests that would allocate more than SZ_16M for the temporary buffer. Fixes: 79ea4a496ab5 ("iommufd/selftest: Fix buffer read overrrun in the dirty test") Link: https://patch.msgid.link/r/20260628152331.82122.408afd7b466c.iommufd-test-dirty-bitmap-size-wrap@trailofbits.com Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9c6eace8d07e90f038c89eb3b756d65a7e259d48 Author: Xiang Mei Date: Sun Jul 12 16:41:50 2026 -0700 isofs: fix out-of-bounds page array access on empty zisofs block [ Upstream commit 68d4d3e78150c7ed7d1195af63ad1e6ace30c661 ] zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which "if (poffset && *pages)" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted "ZF" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache Fixes: 59bc055211b8 ("zisofs: Implement reading of compressed files when PAGE_CACHE_SIZE > compress block size") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260712234150.3213467-1-xmei5@asu.edu Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 4e0af1264a0ff143cdc95a5af9f212dbac10dca8 Author: James Calligeros Date: Sat Jul 11 11:11:19 2026 +1000 ASoC: apple: mca: increase SERDES reset delay [ Upstream commit cccd721e5aab03e92234faee72b363c9ba60611c ] The SERDES clusters in this peripheral take a long time to warm up. We tried polling the reset bit until cleared, however this is not a reliable signal of readiness to be configured. Only waiting ~25 us to give the cluster a chance to settle makes it work reliably. Increase the 2 us delay to 25 us and hope we never have to do this again. Fixes: d8b3e396088d ("ASoC: apple: mca: Fix SERDES reset sequence") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260711-apple-audio-redux-v4-1-2994d87c2f24@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6247fbddbcdf133dec848c226f0ce1347e11cf73 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 364be5873f2ab0ae9532d0d83318c69d87e4353d 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 83fe4e4f4fbf01d3832a24511c0ddfaccf5df9d8 Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Free RX data on late probe failure [ Upstream commit 8e17e101e04a3dc062e2719da57ff78c1c060632 ] hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal. Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-7-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4204f5c0312ba136181a6e148ffa0bfaf95a4cc1 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 b1e1b25723af44328524c7b54433e4bf0ab9930c Author: Leon Romanovsky Date: Mon Jul 13 07:41:23 2026 -0400 RDMA/rvt: Return NULL after port allocation failure [ Upstream commit 2982eaf3b9d2d953318c74cd6f1b7576ea6d7b1f ] rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation failure. Fixes: ff6acd69518e ("IB/rdmavt: Add device structure allocation") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-1-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0d85891822df0b367f9196116bac09fe9973f416 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 901951d0ed7a737abe5fffdfd970b1719eff9101 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 6514c99d2c7d5fff38afae172c722091cd4b7011 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 26b6b14c7a0368e317a1e9fb5144ebe6f8d495cf Author: Maher Azzouzi Date: Sun Jul 12 18:05:30 2026 +0100 esp: do not unref managed frag pages in esp_ssg_unref() [ Upstream commit 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80 ] esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data(). Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Maher Azzouzi Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5f35a29a5eed3d80befd32050843ac88dea3d61a 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 ed566979f99c5516cad45a76ae25e2a4928ffb67 Author: Guangshuo Li Date: Sat Jul 4 19:25:09 2026 +0800 crash_dump: release keyring reference at the correct time [ Upstream commit ada2e5a44e99113e08ad9b7b71396c6c572204da ] restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys. The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free. When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered. The early error paths after lookup_user_key() also return without dropping the keyring reference. Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming it. Fixes: 62f17d9df692 ("crash_dump: retrieve dm crypt keys in kdump kernel") Signed-off-by: Guangshuo Li Reviewed-and-tested-by: Coiby Xu Acked-by: Baoquan He Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260704112509.3717884-1-lgs201920130244@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 30e78390af056a45a0613e60f09d2bff582d1bbb 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 e6d3c7eae75a4f80e359cf67be25b42c4fb60a69 Author: Atish Patra Date: Tue Jun 2 15:36:35 2026 -0700 crypto: ccp - Fix memory leak in SEV INIT_EX path [ Upstream commit c8e53ada20d352b0f1bdc3e58405a9edab897a2e ] allocated pages in _init_ext_path are never freed and sev_init_ex_buffer is left pointing at the leaked memory in case of any failures during the function.. Fix by adding an error path that frees the pages and clears sev_init_ex_buffer. Make sure we only free the memory if the failure happens before the conversion. Otherwise, we may end up trying to free up converted pages in case of reclaim failure. rmp_mark_pages_firmware failures should be rare enough to avoid more code complexity to track down which pages were reclaimed/leaked vs which are not. Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reported-by: Sashiko Reviewed-by: Tom Lendacky Signed-off-by: Atish Patra Acked-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 364f3841bc22c72b6e2cb72a1e3c91c9c8fc1ef4 Author: Atish Patra Date: Tue Jun 2 15:36:34 2026 -0700 crypto: ccp - Fix possible deadlock in SEV init failure path [ Upstream commit b0e7ec0dab242c5e480121ba12400d0513e37ca2 ] __sev_platform_init_handle_init_ex_path() calls rmp_mark_pages_firmware() with locked=false while the parent function of init_ex_path already acquired the sev_cmd_mutex. In the case of an RMPUPDATE failure for any page after the first, the cleanup path would invoke reclaim pages which would result in a deadlock in sev_do_cmd. Pass locked=true to honor the lock status of the parent function. Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reported-by: Chris Mason Assisted-by: Claude:claude-opus-4-6 Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reviewed-by: Tom Lendacky Signed-off-by: Atish Patra Acked-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5de981b7db1f509dfafe8e205b4d342436306e87 Author: Dmitry Baryshkov Date: Sun Jul 12 14:56:55 2026 +0300 Revert "drm/msm: dsi: fix PLL init in bonded mode" [ Upstream commit 44784327815b2a1ad8bb56b9236770cb538c7c27 ] Commit 93c97bc8d85d ("drm/msm: dsi: fix PLL init in bonded mode") fixed one of the issues with the DSI bonded mode, but broke non-bonded usecase for DSI as reported by Mohit Dsor. Clock divider is being programmed incorrectly, resultin in the wrong display mode being selected. Revert the offending commit, letting Neil to work on a better fix. Fixes: 93c97bc8d85d ("drm/msm: dsi: fix PLL init in bonded mode") Reported-by: Mohit Dsor Closes: https://lore.kernel.org/r/ae07cef84AmXK43H@hu-mdsor-hyd.qualcomm.com Cc: Neil Armstrong Cc: Thorsten Leemhuis Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/739459/ Link: https://lore.kernel.org/r/20260712-msm-revert-dsi-pll-fix-v1-1-40122689ea25@oss.qualcomm.com Signed-off-by: Sasha Levin commit 96379c2dec7252cab85a6bc0d350a656bfc0c7c3 Author: Jens Glathe Date: Mon Jun 8 06:54:39 2026 +0200 drm/msm/dp: add missing drm_edid_connector_update() before add_modes on cached EDID [ Upstream commit b7088d58dccfba87fe8dd2ab7c493ee1d9d09277 ] After the refactor to struct drm_edid, the fast path in msm_dp_panel_get_modes() that already held a cached EDID called drm_edid_connector_add_modes() directly without first calling drm_edid_connector_update(). The new API requires the update step to associate the EDID with the connector. Add the missing call. This restores correct behaviour for the cached-EDID path. Fixes: 5bea90ad9743 ("drm/msm/dp: switch to struct drm_edid") Reviewed-by: Dmitry Baryshkov Signed-off-by: Jens Glathe Patchwork: https://patchwork.freedesktop.org/patch/731125/ Link: https://lore.kernel.org/r/20260608-drm_plug_flaky_edid-v3-1-1ca632938e7f@oldschoolsolutions.biz Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0d37e2503efd1069a74be740eadf63ea17c96810 Author: Allison Henderson Date: Sat Jul 11 09:54:19 2026 -0700 RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state [ Upstream commit 15ae32c4a3551c4c9da457370bdfdd65d171e512 ] When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case. Fixes: 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") Assisted-by: Claude-Code:claude-fable-5 Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260711165419.13486-1-achender@kernel.org Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 24ce944721dcd92ae62e7a448d770e2a3e79f5fd 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 4664368b9bd9d5d79ebad24056b98c34b9fed20f Author: Leon Romanovsky Date: Sun Jul 12 04:37:36 2026 -0400 RDMA/mlx5: Drain RCU callbacks during module teardown [ Upstream commit e37cdd75f8d61c1123d324ae5667ac3da562290e ] devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped. Fixes: 6898d1c661d7 ("RDMA/mlx5: Use RCU and direct refcounts to keep memory alive") 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-2-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 48b72fa0d209a92fb51b834a6080171cfa207b2c 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 ea4a4237b161a24ed8efcd52d1f1e55c4f0c9635 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 13a472452dcd570472be56092d848ae26de3ff4c Author: Chih-Kang Chang Date: Tue Jul 7 17:10:53 2026 +0800 wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready [ Upstream commit 9bf6bd6ed5accb57544d04ded911a2ef1642d48f ] 8852A uses the average beacon RSSI to smooth the RSSI. However, before the average beacon RSSI is available, the RSSI should use the PPDU status RSSI of the received packet to avoid reporting the RSSI as -110 dBm. Fixes: f0f3bf4b370c ("wifi: rtw89: 8852a: report average RSSI to avoid unnecessary scanning") Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260707091056.42771-13-pkshih@realtek.com Signed-off-by: Sasha Levin commit 280145253fd38fa975cc04963ddaf74c7f415011 Author: Leon Hwang Date: Sat Jul 11 20:48:21 2026 +0800 bpf: Mark tracing_multi trampolines as ftrace managed [ Upstream commit 30bdd6d1384d894931f113eb595636092d8e650c ] Since tracing_multi link does not set ftrace_managed, it would fail to release the tracing_multi link when attaching tracing_multi link and then attaching fentry link. [ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97 ... [ 3.733170] bpf_tracing_multi_link_release+0x14/0x30 [ 3.733890] bpf_link_free+0x58/0x130 [ 3.734414] bpf_link_release+0x23/0x30 Fix it by setting 'ftrace_managed = true' in register_fentry_multi(). Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions") Signed-off-by: Leon Hwang Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20260711124822.29406-2-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit b7e2a5c6519adc73be55c3de2cb545e095a0fbc5 Author: Nicholas Dudar Date: Thu Jul 9 14:27:59 2026 -0400 bpf: Require a BPF cpumask for bpf_cpumask_populate() [ Upstream commit 8740156ad33be5071b588b594c55f279457f667c ] bpf_cpumask_populate() writes to its destination with bitmap_copy(), but the destination is typed as struct cpumask *. That allows the verifier to accept borrowed cpumask pointers returned by read-only kfuncs, such as scx_bpf_get_online_cpumask(), as a writable destination. Make the destination a struct bpf_cpumask * so populate follows the same ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue to accept const struct cpumask * inputs. Fixes: 950ad93df2fc ("bpf: add kfunc for populating cpumask bits") Signed-off-by: Nicholas Dudar Acked-by: Tejun Heo Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260709182800.2037938-2-main.kalliope@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit b425cc3913fb127c60fe96b3e34712418f130d52 Author: Brian Masney Date: Wed Jul 8 18:30:06 2026 -0400 clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK [ Upstream commit 499b4cb6710f9a351d8b57a2132f9b4389d8464a ] With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genpd_power_off+0xa0/0x1a8 [ 15.409137] genpd_power_off.part.0+0x180/0x2a0 [ 15.409149] genpd_runtime_suspend+0x218/0x310 [ 15.409155] __rpm_callback+0x50/0x1f8 [ 15.409166] rpm_callback+0x7c/0x90 [ 15.409175] rpm_suspend+0xe8/0x690 [ 15.409185] pm_runtime_work+0xd0/0xe0 [ 15.409195] process_one_work+0x18c/0x518 [ 15.409208] worker_thread+0x190/0x320 [ 15.409218] kthread+0x110/0x130 [ 15.409227] ret_from_fork+0x10/0x20 This clock is force enabled to be on in the probe, and registered with the Common Clk Framework, resulting in them being toggled off after unused clocks are shutdown. This clock is required for the GDSC transitions. Similar to the fix in commit b60521eff227 ("clk: qcom: gcc-x1e80100: Unregister GCC_GPU_CFG_AHB_CLK/GCC_DISP_XO_CLK"), let's just unregister this clock. Link: https://lore.kernel.org/linux-clk/20260626-camcc-sc8280xp-titan-top-v1-1-2ca246886493@redhat.com/ Fixes: ff93872a9c616 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC") Suggested-by: Jagadeesh Kona Signed-off-by: Brian Masney Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260708-camcc-sc8280xp-remove-gdsc-v1-1-dfaab98a3bf5@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b7cd0d057e4fcf945cc9e183b15c00ad791afa89 Author: Pengpeng Hou Date: Tue Jun 23 09:54:15 2026 +0800 bus: qcom-ebi2: use managed resources for clocks and children [ Upstream commit d19a46f7ed8eb54fea61e0eaf7db53ff7babb03c ] qcom_ebi2_probe() enables the EBI2 clocks manually and populates child devices manually. Several later failure paths can then return without disabling the clocks or without relying on the driver core to undo child population. Use devm_clk_get_enabled() for both clocks and devm_of_platform_populate() for children. This lets the driver core unwind the resources automatically and removes the hand-written error labels. Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Pengpeng Hou Reviewed-by: Konrad Dybcio Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260623015415.26975-1-pengpeng@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f98700ea19755ac2beb3903dbef458b04d49af50 Author: Pengpeng Hou Date: Tue Jun 23 09:55:01 2026 +0800 soc: qcom: rpmh-rsc: manage PM notifiers with devres [ Upstream commit 75e918aa876440d8ad559a11d6ab87bddb1ed79a ] rpmh_rsc_probe() registers CPU PM or genpd notifiers before populating child devices. If child population fails, the CPU PM notifier path is not unwound and the genpd path needs open-coded cleanup. Use devm_pm_runtime_enable() for the genpd path and devm_add_action_or_reset() for both notifier registrations. This makes probe failure and driver detach use the same cleanup model while keeping devm_of_platform_populate() responsible for child devices. Fixes: 25092e6100ac ("soc: qcom: rpmh-rsc: Attach RSC to cluster PM domain") Signed-off-by: Pengpeng Hou Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260623015501.31129-1-pengpeng@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a819fd4479c7f8ea63769410fd0ed56d9998aec9 Author: Yu Peng Date: Tue Jun 2 16:11:04 2026 +0800 perf metricgroup: Fix metric expression copy leaks [ Upstream commit ef3af1df4f3372bd8ad47619452a283048b3bc8d ] metricgroup__copy_metric_events() allocates a new metric expression and duplicates metric_name before linking the expression into the destination metric event. Free new_expr when strdup() fails, and free the duplicated metric_name on the later error paths. Fixes: b85a4d61d302 ("perf metric: Allow modifiers on metrics") Signed-off-by: Yu Peng Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ad44537175f7e828b33f7a9f40e24b292cadd89b Author: Yixun Lan Date: Tue Jun 30 12:52:45 2026 +0000 clk: spacemit: k3: fix parent clock of UFS aclk [ Upstream commit 7a588b62679c51abd08171d31df6e44589f0097d ] According to SpacemiT updated clock docs, the previous UFS aclk parent clock was wrong, the correct one is illustrated below, so fix it. --> pll1_d5_491p52 --\ --> pll1_d6_409p6 --| --> pll2_d6 --|--> div --> gate --> ufs_aclk --> pll2_d5 --/ Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Link: https://patch.msgid.link/20260630-06-clk-ufs-support-v1-1-cf7521d1d0fe@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit c4e364ecb8098668a892e7e25c1584a4f2896257 Author: Ian Rogers Date: Thu Jul 9 22:39:06 2026 -0700 perf record: Fix teardown hang on system-wide multi-threaded sessions [ Upstream commit fb4751e79c45cb48cff1c1d86b10a9cc6f6612fe ] Under system-wide (-a) parallel streaming mode (--threads=cpu), background recording threads can be inundated by a continuous firehose of hardware samples generated by the OS. In this state, a background thread's local hit count remains unequal to its sample count, causing it to bypass the blocking fdarray__poll() call entirely on each iteration of its recording loop. Because the termination check relies on the POLLHUP event status populated specifically by fdarray__poll(), bypassing it prevents the background thread from ever recognizing that its control pipe was closed by the main thread. This traps the background thread in an infinite recording loop, hanging the main thread indefinitely as it awaits a termination acknowledgment that never arrives. Ensure teardown completion by adding explicit evlist__disable() calls in the main thread's cleanup paths at out_child: and out_child_no_flush:. Additionally, patch fdarray__filter() to respect the fdarray_flag__nonfilterable flag, preventing it from incorrectly setting the background thread's control pipe file descriptor to -1 and clearing its revents mask upon processing termination POLLHUP signals. Fixes: f94563fac269 ("perf record: fix poll storm when monitored threads exit") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c30c5ae811eea67f693ae93c643fe7296921d3b5 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 a0ac59897309e832bb6e25b6d24c5f921b90231a Author: Xu Yang Date: Fri Jul 10 15:08:34 2026 +0800 usb: chipidea: imx: fix missing ret assignment for dev_err_probe [ Upstream commit 1db5c6b0b9834aee2f14e39764becfcc29d09ccf ] Assign the return value of dev_err_probe() to ret so that the correct error code is propagated when goto err_clk is taken. Fixes: 2e9762f45efb ("usb: chipidea: ci_hdrc_imx: use "wakeup" suffix for wakeup interrupt name") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202607031656.FR3Xrved-lkp@intel.com/ Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260710070834.2744357-1-xu.yang_2@oss.nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 616dfbd3a0b481fb1f39ebd87d59fac33a1776eb Author: Pengpeng Hou Date: Thu Jul 9 20:32:39 2026 +0800 usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure [ Upstream commit 2c5659a7064e7c4c0c51eb9356bcf6726a85773b ] gaokun_ucsi_register_worker() registers the EC notifier before calling ucsi_register(). If ucsi_register() fails, the worker currently only logs the error and leaves the notifier registered. Later EC events can then call into an unpublished UCSI instance. The remove path also unconditionally unregisters both the EC notifier and the UCSI device even if the delayed worker failed before both publication steps completed. Unregister the notifier immediately when ucsi_register() fails, and track only the fully published state. The remove path then tears down the pair only if both publication steps completed. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Reviewed-by: Heikki Krogerus Reviewed-by: Pengyu Luo Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260709123239.62930-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ada6c7692c0c5b91f930d0b2b195420dddc85c2 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 7a5b2e8ec85ace90f80868db0d0570611a24267f Author: Fei Shao Date: Fri Jun 26 16:21:51 2026 +0800 usb: mtu3: allow system suspend during active gadget connection [ Upstream commit e69027c25361b6044c7928715667586cc5469063 ] When operating in gadget mode connected to a USB host, system suspend fails with -EBUSY because active peripheral connections block suspend entry. Fix this by restricting the -EBUSY check to runtime autosuspend (PMSG_IS_AUTO). For system suspend (!PMSG_IS_AUTO), perform soft disconnect to disconnect from the bus and allow MAC sleep. Fixes: 427c66422e14 ("usb: mtu3: support suspend/resume for device mode") Signed-off-by: Fei Shao Link: https://patch.msgid.link/20260626082218.2750459-2-fshao@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 428a82d987fcd8844e8868c85582eae75b4b5c51 Author: Linmao Li Date: Mon Jul 6 09:25:11 2026 +0800 platform/surface: acpi-notify: Check ACPI companion before use [ Upstream commit 2b3a5dabe89e330413af403246b648c1890f368f ] Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION() against NULL during probe") does for the core ACPI platform drivers. Fixes: a9e10e587304 ("ACPI: scan: Extend acpi_walk_dep_device_list()") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d25dd08268aeaceb485189aaa84aa6d68a460291 Author: Linmao Li Date: Mon Jul 6 09:20:56 2026 +0800 platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL [ Upstream commit c38cce70adef874c2a7b5132c14d6c221401deff ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260706012056.524096-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3308b8c5f5a28403611a2f5a46f06aabe4f0c661 Author: Marco Scardovi Date: Wed Jun 17 17:51:04 2026 +0200 platform/x86: asus-wmi: fix resource leaks on probe failure [ Upstream commit ef3daa2b84a2b8499ce9e2ce1c865dca36d39f95 ] During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations. Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves") Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260617155104.10111-1-scardracs@disroot.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e6a9c6b79b70046afdf5a1dbd03b1104536f30c0 Author: Gary Guo Date: Tue Jul 7 13:26:46 2026 +0100 usb: fix UAF when probe runs concurrent to dyn ID removal [ Upstream commit ef8154d8b52d60338c1fd8d793cd8e891c604c14 ] Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs. Fixes: 0c7a2b72746a ("USB: add remove_id sysfs attr for usb drivers") Signed-off-by: Gary Guo Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-7-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e6f57107c1886052d4baaa047a2bc3d0e91be5d Author: Ruoyu Wang Date: Wed Jun 10 20:10:22 2026 +0800 usb: gadget: aspeed_udc: check endpoint DMA allocation [ Upstream commit 97cee53a94be3bd4fd8fbed6071bd2f32dad1ab1 ] ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed. Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver") Signed-off-by: Ruoyu Wang Reviewed-by: Andrew Jeffery Link: https://patch.msgid.link/20260610121022.3-1-ruoyuw560@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9c4bc8f7426aa001387800bf0140bfc5087a6de3 Author: Maoyi Xie Date: Thu Jun 18 14:19:48 2026 +0800 usb: ljca: bound bank_num in ljca_enumerate_gpio() [ Upstream commit dd9483726d0f16c1a56879c3edb65128259a4e2b ] ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[]. Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Signed-off-by: Maoyi Xie Acked-by: Sakari Ailus Link: https://patch.msgid.link/178176358875.3352358.6059116660356914900@maoyixie.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 969bf1c64b840bcc6e96a3ca97a7caac8b3647f1 Author: Xu Rao Date: Tue Jun 16 16:54:39 2026 +0800 usb: typec: tcpm: fix EPR AVS APDO maximum voltage decoding [ Upstream commit 29741ca40b7b780ba14c4c3ffef190f908864fe9 ] pdo_epr_avs_apdo_max_voltage_mv() extracts the EPR AVS minimum-voltage field instead of the maximum-voltage field. As a result, an EPR AVS APDO with different minimum and maximum voltages is decoded as having identical limits. The currently visible effect is that tcpm_log_source_caps() reports a min-min voltage range. Extract PDO_EPR_AVS_APDO_MAX_VOLT in the maximum-voltage accessor. Fixes: f82890c98f3e ("tcpm: Parse and log AVS APDO") Signed-off-by: Xu Rao Link: https://patch.msgid.link/48301FCEC9F3CA14+20260616085439.987664-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 36315a330e067f7773196940552feacb1debbef1 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 58952c83dfe6ea3294a74734d2d1018c1120779a Author: Nuno Sá Date: Fri Jun 12 15:57:57 2026 +0100 usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error paths [ Upstream commit 621707dc67c9846fd876d7579ec951d92aa033f1 ] The error paths for endpoint-disabled (ESHUTDOWN) and request-allocation failure (ENOMEM) in ffs_dmabuf_transfer() jump to err_fence_put which calls dma_fence_put() on the fence. However, at that point the fence has only been kmalloc'd — dma_fence_init() has not been called yet, so the refcount and the fence ops are uninitialized. Calling dma_fence_put() on such an object leads to undefined behavior. Use kfree() instead, since the fence is just a plain allocation at this stage, and rename the label to err_fence_free to reflect the actual cleanup action. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Nuno Sá Reviewed-by: Paul Cercueil Link: https://patch.msgid.link/20260612-fix-f_fs-fence-cleanup-v1-1-79f489b0efe9@analog.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3819c6f255a37c4d085ce9f264f9f11bf3c2c6bb Author: Qing Ming Date: Tue May 19 22:33:19 2026 +0800 usb: gadget: uac: validate rate list length before storing [ Upstream commit 844d83d5964b87919b958ff48405188c6ddae9cc ] UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++]. Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts. With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c:1669:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 The same reproducer against the UAC2 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c:2087:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths. Fixes: 695d39ffc2b5 ("usb: gadget: f_uac1: Support multiple sampling rates") Fixes: a7339e4f5788 ("usb: gadget: f_uac2: Support multiple sampling rates") Signed-off-by: Qing Ming Link: https://patch.msgid.link/20260519143319.147494-1-a0yami@mailbox.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 59faa59c25a0a098fbc86275408d7c8405015702 Author: Guangshuo Li Date: Wed Jul 8 21:17:26 2026 +0800 serial: qcom-geni: do not advance stale DMA completions [ Upstream commit 7ea38c49e7178960926657863299face6dc0e1b0 ] The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining. If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer. A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes. Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo. Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708131726.768692-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 494bb296407fe75d1643adbb827e0721d98926fc Author: Yuho Choi Date: Tue Jun 30 17:40:43 2026 -0400 serial: ma35d1: Fix OF node reference leaks in console init [ Upstream commit 8dfea56f350b3dc826f35711802ad6ae8fae0748 ] ma35d1serial_console_init_port() stores matching UART device nodes in ma35d1serial_uart_nodes[] with an extra of_node_get() so that console setup can later read the "reg" property. However, the stored references are never released after console setup has finished using them. Drop the stored node reference after ma35d1serial_console_setup() reads the "reg" property, and clear the array slot to avoid leaving a stale pointer behind. Also release the iterator reference before breaking out of for_each_matching_node(), since the normal iterator advance will not run in that path. Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260630214043.1887351-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 606f769df00d8c8e4dab2976dd1f1f32632efbaa Author: Fushuai Wang Date: Fri May 22 18:10:42 2026 +0800 serial: 8250: Clear CON_PRINTBUFFER on port re-registration [ Upstream commit d338ab1d90603f875c4f7ed223406535378173a5 ] When two PnP devices map to the same physical port, the serial8250 driver removes and re-registers the console structure for the same port. During re-registration, the console structure still has CON_PRINTBUFFER set from the initial registration, which causes console_init_seq() to set console->seq to syslog_seq. This results in re-printing the entire system log buffer, which may lead to RCU stall on slow serial consoles. Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate log printing. Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") Suggested-by: Greg Kroah-Hartman Signed-off-by: Fushuai Wang Link: https://patch.msgid.link/20260522101042.21976-1-fushuai.wang@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08182086dca4eaf54b9baacadefa546915571d75 Author: Ricardo Ribalda Date: Mon Jun 29 11:30:46 2026 +0000 media: platform: amd: use refcount_t instead of atomic_t [ Upstream commit 0baf8f42110b7c361bb3f6a8a78c0958a23e4e32 ] We are using the refcnt variable for refcounting. Use the refcount_t type instead, as it has support for saturation and underflow. This also makes cocci happier, as it will fix the following warning: ./platform/amd/isp4/isp4_subdev.c:394:6-25: WARNING: atomic_dec_and_test variation before object free at line 395. Fixes: 4c5feef6a62c ("media: platform: amd: Add isp4 fw and hw interface") Signed-off-by: Ricardo Ribalda Reviewed-by: Pratap Nirujogi Reviewed-by: Bin Du Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 55bb98850f392eb48be033248d631488edf0e84b Author: Praveen Talari Date: Fri Jul 10 15:42:44 2026 +0530 spi: qcom-geni: Fix missing error check on pm_runtime_get_sync() [ Upstream commit d8e9ea989acb54508477e4a8c9d9eaf8217e0081 ] spi_geni_init() calls pm_runtime_get_sync() to power up the device before accessing hardware registers, but never checks the return value. If the runtime resume fails, the function silently proceeds to read and write hardware registers on a device that may not be powered up, leading to register access faults. Fix this by replacing pm_runtime_get_sync() with the PM_RUNTIME_ACQUIRE_IF_ENABLED() macro and checking the result via PM_RUNTIME_ACQUIRE_ERR(), propagating any error back to the caller immediately before any hardware access occurs. Since the macro handles its own cleanup on failure, the out_pm label and the corresponding pm_runtime_put() call are no longer needed. Replace all goto out_pm paths with direct return ret statements and remove the label entirely. Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Konrad Dybcio Signed-off-by: Praveen Talari Link: https://patch.msgid.link/20260710-fix_sticky_-einval_after_pm_runtime_api_failure-v4-2-be81d6c15043@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7bfa711f311a584002e16ecd750627306deb805c Author: Linmao Li Date: Fri Jul 10 17:43:55 2026 +0800 platform/x86: asus-wireless: Fail probe when there is no ACPI match [ Upstream commit 4aefd66ef7822cf7d3f53146dcee0b71021ed2b7 ] Every platform driver can be forced to match a device that does not match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device ACPI companion object need to verify its presence. asus_wireless_probe() returns success when acpi_match_acpi_device() finds no match, leaving behind an input device that never reports anything because the notify handler is not installed. Worse, when the driver is force-bound to a device without an ACPI companion, probe still succeeds and stores a NULL companion pointer, which asus_wireless_remove() later passes to acpi_dev_remove_notify_handler(), leading to a NULL pointer dereference on unbind. Return -ENODEV when the device does not match the ID table. This also covers the missing-companion case, because acpi_match_acpi_device() rejects a NULL device. Perform the check before allocating any driver state, instead of after the input device has already been registered. Fixes: f7e648027d7e ("platform/x86: asus-wireless: Convert ACPI driver to a platform one") Suggested-by: Rafael J. Wysocki Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260710094355.186143-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 73e2e363a96612cd508632b4795a1e93720b6b7e Author: Tengda Wu Date: Wed Jul 1 03:53:35 2026 +0000 perf capstone: Fix kernel map reference count leak [ Upstream commit d3c9fca531e2465f3a8f585965f3d10e1a6595ff ] In print_capstone_detail(), maps__find() is used to locate the kernel map. This function increments the reference count of the found map object. However, the current implementation fails to call map__put() after the map is no longer needed, leading to a reference count leak. Fix this by adding a map__put(map) call to properly release the reference after use. Fixes: 92dfc59463d5 ("perf annotate: Add symbol name when using capstone") Signed-off-by: Tengda Wu Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 01f6c6ff9ebfbec08dbfb8a59a30c82ddec5d613 Author: Liang Luo Date: Thu Jul 9 18:03:40 2026 +0800 selftests/sched_ext: Fix bpf_link leak on early return in prog_run [ Upstream commit e655c1f1bd14804f398df7da029c4a7e3f9ccd7f ] In prog_run's run(), the bpf_link is attached early but only destroyed on the success path. The three SCX_EQ assertions between attach and destroy expand to a direct 'return SCX_TEST_FAIL', so if any of them triggers, bpf_link__destroy() is never reached and the BPF scheduler stays loaded. All subsequent tests then fail to attach because SCX is not in the DISABLED state. Convert those assertions to explicit checks that jump to a unified 'out' label which always runs the cleanup, matching the pattern used in cyclic_kick_wait.c. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Liang Luo Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 891aee54b39d2f576b7391fcb2628fad0fba30c7 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 56a3846830ac95a472297d0cbba75cbff29540bb Author: Nicholas Dudar Date: Thu Jul 9 11:58:36 2026 -0400 bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max [ Upstream commit 2aaf67f0516fde29620d0edfc29c01b9ea7ad430 ] check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field: meta->r0_size = reg->var_off.value; ... regs[BPF_REG_0].mem_size = meta.r0_size; regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound. Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set. Fixes: eb1f7f71c126 ("bpf/verifier: allow kfunc to return an allocated mem") Signed-off-by: Nicholas Dudar Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260709155837.1879230-2-main.kalliope@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit bce6b48af3abf7468d12ef4933f21bd8c1d822e9 Author: Val Packett Date: Sun Feb 1 17:55:03 2026 -0300 remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 [ Upstream commit 3dbc90b9c22ea96e37bf55f6011e63b5123ec668 ] The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators. Signed-off-by: Val Packett Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Reviewed-by: Konrad Dybcio Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Link: https://lore.kernel.org/r/20260201210230.911220-1-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5aed51501447ebb925b0ce0d7d923a9d5ce0bf9e Author: Felix Gu Date: Fri Jan 16 20:11:03 2026 +0800 remoteproc: qcom_q6v5_adsp: Fix reference leak for device node [ Upstream commit 8c952807c2cebd5e9e9b37146c9383229794c129 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference. Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox") Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_EDC2253D3B1C22217E1259E07765D269100A@qq.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f3614622dc41f3dd99bb4f691da253814e4e6cae Author: Daniel Borkmann Date: Thu Jul 9 17:31:30 2026 +0200 bpf: Drop scalar id on sign-extending narrowing stack fills [ Upstream commit 2cb5f4ca695ebe552647e5ba4aad6934d6a43bae ] When a spilled scalar is filled back with a sign-extending narrowing load (BPF_MEMSX), check_stack_read_fixed_off() copies the spilled register including its scalar id, but coerce_reg_to_size_sx() then sign-extends the filled register's value. If the same slot is also filled with a plain zero-extending load (BPF_MEM), both destination registers share the id yet hold different values. A later 'if == const' then refines the sign-extended register through sync_linked_regs() to a value it does not have at runtime (e.g. the verifier believes 0x80000000 while the register is 0xffffffff80000000), which can be turned into an out-of-bounds access. Drop the shared scalar id at the sign-extension site in check_mem_access() when sign extension actually changes the value, mirroring the BPF_MOVSX handling in check_alu_op() (no_sext = reg_umax < 2^(size*8-1)). Fixes: 3cd5c890652b ("bpf: Let the verifier assign ids on stack fills") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit acc190322250562d5f28860f4ae1ebaf3e304fc2 Author: Armin Wolf Date: Wed Jul 8 21:55:49 2026 +0200 platform/x86: lg-laptop: Fix LED resource handling [ Upstream commit 3e91964aa74ab261aa15d9d96318eded2fd9d22a ] The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally. Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device. Fixes: ae26278829a8 ("platform/x86: lg-laptop: Use correct event for keyboard backlight FN-key") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260708195553.7762-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 392c19faec6bf4cb72fb02322e2a61e198dd8f72 Author: Armin Wolf Date: Fri Jun 12 19:34:50 2026 +0200 platform/x86: dell-wmi-base: Fix handling of ultra performance key [ Upstream commit adfd6846bea13667ff28f8aaf00c32fbd69825ab ] The commit message of commit 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so "buffer" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread. Fixes: 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f59cd5007055cc0cdac1621d1cecff2d295ff8d0 Author: Armin Wolf Date: Fri Jun 12 19:34:49 2026 +0200 platform/x86: dell-wmi-base: Fix resource leak on module load failure [ Upstream commit 072841e02cf9c00a7e8a9c567a14239e02ca47ad ] We need to properly clean up the SMBIOS request and the privacy driver when the module load fails. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ef59ff891adf9bd696917f71f841fdb23c245790 Author: Armin Wolf Date: Fri Jun 12 19:34:48 2026 +0200 platform/x86: dell-privacy: Fix race condition [ Upstream commit ca9338dbc64759b30741b12017c050b33c94dfa2 ] Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3fd86a5d6facb6618f63a76d499f28007cef878f Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:14 2026 +0200 ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling [ Upstream commit 3a56321d0aceee2a0bd80d23366401c131ff8350 ] The loop in riscv_acpi_add_prt_dep() includes error conditions that are handled in a dubious - if not outright wrong - way, by continuining the loop (which skips and misses the entry pointer update to point to the next entry). Rewrite the loop as a for loop (that handles the continuation correctly) and wrap the condition and update statements using helper functions to make it cleaner. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-4-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 088c1c85921344d7244ca2e8d5d336ae7461de6e Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:13 2026 +0200 ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() [ Upstream commit 20435bda13f1219891ed0ce41207e320a916ff9c ] In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which would leave link_handle uninitialized. Fix it by checking the acpi_get_handle() return status and skip the entry if it fails. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-3-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b0f9c3418735b429275e292781277679f5285fe5 Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:12 2026 +0200 ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination [ Upstream commit 64ae310bffa477cd11029c818bec489f4b8a845e ] In riscv_acpi_add_irq_dep() the main loop condition would currently stop the loop if an interrupt descriptor contains an interrupt for which the respective GSI handle is NULL, which is not correct because subsequent interrupts in the interrupt descriptor might still have a GSI dependency that must not be skipped. Rework riscv_acpi_add_irq_dep() and the riscv_acpi_irq_get_dep() call chain to fix it - by not forcing the loop to stop in order to guarantee dependency detection for all the interrupt entries in the CRS descriptor. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-2-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8f194dee0c0d1223255bae1429e1939882f540fc Author: John Ogness Date: Fri Jul 3 16:20:31 2026 +0206 printk: Fix possible console use-after-free [ Upstream commit 36630cafbeede0b64c370edb2f7b4094327ee1e0 ] When emitting a record via legacy printing, it is possible that a handover to another legacy printing context occurs. When a context has performed a handover, the console SRCU read lock is released and the pointer to the console struct might now be invalid. Therefore, after calling nbcon_legacy_emit_next_record() or console_emit_next_record(), it is necessary to check if a handover occurred _before_ further @con usage. Sashiko pointed out that console_flush_one_record() was not doing this. In console_flush_one_record(), after emitting a record, move the further usage of @con after the handover check. Fixes: c158834b223f ("printk: nbcon: Use nbcon consoles in console_flush_all()") Reported-by: Sashiko Closes: https://lore.kernel.org/lkml/20260630170903.099D61F000E9@smtp.kernel.org Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://patch.msgid.link/20260703141521.202813-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit a09efb1e256f0b9e7d365cfd1b48948e619334bf Author: Manuel Fombuena Date: Thu Jul 2 23:35:58 2026 +0100 leds: st1202: Validate LED reg property against channel count [ Upstream commit cf197514bdfd3877f42b5dce1efd40b7b686547e ] The reg property from the device tree is used directly as an array index into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS would cause an out-of-bounds write during probe. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849718B43321DB7E5A05D17BC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f1a049284bcb7c9466b7a12e875de887c563a111 Author: Manuel Fombuena Date: Thu Jul 2 23:34:37 2026 +0100 leds: st1202: Disable channel when brightness is set to zero [ Upstream commit 0767335233a8cbab00bbe260a4e4bd380c7677fd ] When brightness_set() is called with LED_OFF, only the ILED register is zeroed; the channel enable bit is left set from probe time. A hardware channel enabled with ILED=0 still draws a small residual current, causing a dim glow even when the LED is supposed to be off. Fix this by splitting st1202_channel_set() into a lockless inner function __st1202_channel_set() and a locking wrapper, then calling the inner function from brightness_set() while it already holds the mutex. The channel is now disabled when value is zero and re-enabled when non-zero, in the same lock region as the ILED write. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497F11B30FE7D74CAA25135C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6d711caa9f2404637deb9a6416b87ff078cbe824 Author: Manuel Fombuena Date: Thu Jul 2 23:33:16 2026 +0100 leds: st1202: Fix brightness having no effect while pattern mode is active [ Upstream commit 7cbe470366bdd43c7e8114fb2c4d74fa69093121 ] Once a hardware pattern is running (PATS=1), writing to the brightness sysfs attribute only updates the ILED register. The visible output is ILED x Pattern_PWM / 4095, so the change has little effect and the LED never returns to steady static operation as the user expects. The LED1202 has a single global sequencer shared across all channels. Stopping it in brightness_set() to force static mode would halt running patterns on all other active LEDs. Instead, set all 8 PWM slots for the channel to ST1202_PATTERN_PWM_FULL before writing ILED. With every step at full duty cycle, the output is ILED x FULL / 4095 = ILED regardless of the sequencer state, without disturbing other channels. This also enables basic LED operation without the pattern trigger: with the trigger set to none, the brightness sysfs attribute fully controls the LED as a simple on/off device. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497570FD162D0D42A9864E3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 14bb601435c026e42e3614a31bd67253a4f359b5 Author: Manuel Fombuena Date: Thu Jul 2 23:30:50 2026 +0100 leds: st1202: Set all pattern PWM slots to full after clearing pattern [ Upstream commit d2ca0e2b6d6430f9c60bb2e0ee0b2b3dc4e5d86a ] pattern_clear() sets all PWM registers for the channel to LED_OFF (0). In static mode (PATS=0), the LED output is ILED x Pattern0_PWM / 4095; with Pattern0 at zero the LED remains dark regardless of the ILED value. The LED1202 has a single global sequencer shared across all channels. If another channel starts the sequencer after this one has been cleared, the cleared channel runs through all 8 steps at zero duty cycle and stays dark regardless of ILED. Set all 8 PWM slots to ST1202_PATTERN_PWM_FULL so that ILED alone controls the channel brightness in both static and sequencer modes. Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849732C162CFE9E2C525AC16C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Stable-dep-of: 7cbe470366bd ("leds: st1202: Fix brightness having no effect while pattern mode is active") Signed-off-by: Sasha Levin commit 037359b67bb9c07034d269a3b8d42562e208fcbd Author: Manuel Fombuena Date: Thu Jul 2 23:31:55 2026 +0100 leds: st1202: Fix spurious pattern sequence start in setup [ Upstream commit dcc31246aaf0d330a3ba9a725f56c33e6d634caa ] st1202_setup() writes PATS and PATSR to the Configuration register as its final step, which starts the hardware pattern sequencer during device probe before any patterns have been programmed. This causes the device to run a sequence with whatever values happen to be in the pattern registers at the time. Remove the write. The device reset at the start of setup restores all registers to their power-on defaults, leaving PATS and PATSR cleared. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849724B0FF00255F4760FAE0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2e3900c92db2772b8f42ccb9d43b0da5afc2145c Author: Manuel Fombuena Date: Thu Jul 2 23:29:39 2026 +0100 leds: st1202: Fix pattern duration prescaler and pattern_clear skip marker [ Upstream commit d32f8bdc2b417a3013e1316a54a0b314f973bbc1 ] The PATy_DUR register encodes duration as N × 22.2 ms, with register value 0 reserved as a pattern skip indicator (§7.10). The driver incorrectly subtracted 1 from the register value: value / ST1202_MILLIS_PATTERN_DUR_MIN - 1 This caused two problems: - All programmed durations were off by one step (~22 ms too short). - Writing the minimum duration (22 ms) produced register value 0, silently skipping the pattern step instead of setting a 22 ms duration. The maximum duration constant was also wrong at 5660 ms. The 8-bit register saturates at 255, giving a maximum of 5610 ms (22 ms × 255). Values above 5653 ms were already producing a uint8_t overflow and writing 0 to the hardware. Fix the formula by removing the erroneous subtraction, and derive the maximum from the register width so the relationship is explicit. Update the documentation to reflect the correct maximum. This exposes a secondary issue: pattern_clear() was calling st1202_duration_pattern_write() with ST1202_MILLIS_PATTERN_DUR_MIN to reset unused slots, accidentally relying on the broken formula to produce register value 0. With the corrected formula, the same call writes 0x01 (22 ms), leaving unused slots as valid 22 ms zero-PWM steps and making the LED appear off for 7 × 22 ms out of every cycle. Write 0 directly to the duration registers in pattern_clear() so unused slots are always explicitly marked as skip, independently of the conversion formula. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 523902fc6f2e0fb292dc9c69e01e16871bf841ad Author: Manuel Fombuena Date: Thu Jul 2 23:27:22 2026 +0100 leds: st1202: Stop pattern sequence before reprogramming [ Upstream commit 9c019a8cb95d820e0bd03e75cfbad2c5b13941b7 ] The LED1202 datasheet (section 4.8) states that modifications to the Pattern Sequence Repetition register (PAT_REP) and pattern duration registers are only applied after the sequence has completed or been stopped. When the device is running in infinite loop mode (PAT_REP = 0xFF) the sequence never completes on its own, so these writes are silently ignored by the hardware. Neither pattern_clear() nor pattern_set() stop the running sequence before modifying pattern registers, causing any subsequent pattern reprogramming to have no effect when the previous pattern was set to infinite repeat. Fix this by clearing PATS in the Configuration register before touching any pattern registers in both functions, ensuring the hardware accepts the new values immediately. Note that the LED1202 has a single global pattern sequencer shared by all channels: PATS, PATSR, the duration registers, and PAT_REP are chip-wide. Stopping the sequencer in pattern_clear() therefore halts any pattern running on other channels. This is an inherent hardware constraint; pattern_set() restarts the sequencer when a new pattern is programmed. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84978D0F499774773C7DA1FCC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e9d1f11c7049877dd86eaafc00c38f1a52940912 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 2c1795907ac5a2cb60230666a1851b7cfb12d077 Author: AngeloGioacchino Del Regno Date: Thu Jul 9 11:20:21 2026 +0200 arm64: dts: mediatek: tungsten-smarc: Remove unnecessary cells [ Upstream commit dee885034faf7c9b265987407ab303b464ed0058 ] Remove unnecessary address and size cells from both the disp_dsi0 and the xhci2's ethernet usb device subnode to fix a dtbs_check warning for avoid_unnecessary_addr_size. Fixes: 9fda4a8a479f ("arm64: dts: mediatek: add device tree for Tungsten 510 board") Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 585a58a6568d2623abc58703936e1d7a1d150233 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 5af7fdb7659b0de354f9a2aa743199f5c2474aa3 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 697c84154983e7d266b5e389f0d2680399d14b03 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 35ebd93daaec0c75b84afdbecf3ed4ee54414982 Author: Daniel Borkmann Date: Thu Jul 9 09:34:22 2026 +0200 bpf: Fix security_bpf_map_create error handling [ Upstream commit 36ffa86c42f91c8a57071e024afc4ffb51a8958f ] Commit 5816bf4273ed ("lsm,selinux: Add LSM blob support for BPF objects") made the LSM hook wrappers for BPF object creation clean up the LSM state internally upon denial, e.g. security_bpf_map_create() internally calls security_bpf_map_free() when the bpf_map_create hook returns an error. map_create() however still routes a denial to its free_map_sec label, which invokes security_bpf_map_free() a second time, so the bpf_map_free hook fires twice for a single denied map. In-tree LSMs are unaffected in practice since the blob kfree() inside security_bpf_map_free() is NULL-safe and idempotent and none of them implement bpf_map_free, but a BPF LSM program attached to that hook observes double invocations. Route the denial to free_map instead. Fixes: 5816bf4273ed ("lsm,selinux: Add LSM blob support for BPF objects") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260709073422.379247-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 90f661bcfaf3ab5daab0107a4fdc6504889c75cb Author: Akari Tsuyukusa Date: Mon Jun 29 23:59:44 2026 +0900 iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX [ Upstream commit aebaa93f3da1572877579c2e15ebf27be2dcc7fb ] The mt2701_m4u_in_larb[] array contains 4 (for LARB0 to LARB3) elements, meaning mt2701_m4u_to_larb() can legitimately return 3. The current check `if (larbid >= MT2701_LARB_NR_MAX)` incorrectly rejects valid LARB3 with -EINVAL. Fix this off-by-one error by updating MT2701_LARB_NR_MAX to 4. Note that this does not cause immediate issues with the current mt2701.dtsi and mt7623n.dtsi because it only defines 3 LARBs: mediatek,larbs = <&larb0 &larb1 &larb2>; Thus, larbid never reaches 3 in the existing upstream device tree. Fixes: de78657e16f4 ("iommu/mediatek: Fix NULL pointer dereference when printing dev_name") Signed-off-by: Akari Tsuyukusa Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 21c6445366795fa3a89954e1d318e7c8afdef843 Author: Tiezhu Yang Date: Wed Jul 8 18:18:06 2026 +0800 bpf: Reject programs with inlined helpers if JIT is not available [ Upstream commit f1c27922576edccb99d0257827d09bd05c0304a6 ] When an architecture (such as LoongArch, ARM64, and RISC-V) implements bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper call offset (insn->imm) in bpf_do_misc_fixups(). This is because the helper is expected to be inlined by the JIT compiler later. Therefore, insn->imm remains as the raw helper enum ID. However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or if JIT compilation fails dynamically (e.g., due to OOM), the program falls back to the BPF interpreter. When the interpreter executes (__bpf_call_base + insn->imm) with the unpatched raw ID, it jumps into an invalid address space, triggering an instruction alignment fault or a kernel panic. Although these helpers have valid C implementations in the kernel, the omission of offset rewriting makes runtime interpreter fallback fatal. Fix this by setting 'prog->jit_required = 1' when helper call rewriting is skipped for JIT inlining. This ensures that such programs are safely rejected if JIT is not available, preventing the runtime kernel panic. Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()") Suggested-by: Alexei Starovoitov Suggested-by: KaFai Wan Acked-by: Leon Hwang Signed-off-by: Tiezhu Yang Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 8467d5a2fb87e0fef7209dcd480d3a1d4a313c7c Author: Tiezhu Yang Date: Wed Jul 8 18:18:05 2026 +0800 bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call() [ Upstream commit 9a6df65d5c6a9947ddab4e563e329720f44b8747 ] Introduce a 'jit_required' bitfield flag in struct bpf_prog to track whether a BPF program strictly requires the JIT compiler to run. This prevents a dangerous runtime fallback to the interpreter for features that are only implemented in the JIT compiler. Currently, bpf_prog_has_kfunc_call() is used only for kernel function calls, replace the kfunc-specific helper with the new 'jit_required' flag. This makes it easy to support other JIT-only BPF features, such as inlined helpers. Suggested-by: Alexei Starovoitov Suggested-by: KaFai Wan Suggested-by: Leon Hwang Acked-by: Leon Hwang Signed-off-by: Tiezhu Yang Signed-off-by: Eduard Zingerman Stable-dep-of: f1c27922576e ("bpf: Reject programs with inlined helpers if JIT is not available") Signed-off-by: Sasha Levin commit 8f3f64faee335eb678fd7dca7b95dfe3d0b271fd Author: Yuho Choi Date: Wed Jun 3 15:51:42 2026 -0400 bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation [ Upstream commit 6f12862600bb70e599a614d706a095ea5f8f9858 ] mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize(). Fixes: 297c77a0f273 ("bus: mhi: ep: Add support for creating and destroying MHI EP devices") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260603195142.2189386-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 2b2a903bee56d312539046d9defa8023eec94760 Author: Sanghyun Park Date: Wed Jul 8 16:21:04 2026 +0900 bpf: Fix use-after-free on mm_struct in bpf_find_vma() [ Upstream commit 47b079e2117a2ee52e21f8b72935900c702fc0b5 ] bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm Fixes: 7c7e3d31e785 ("bpf: Introduce helper bpf_find_vma") Signed-off-by: Sanghyun Park Reviewed-by: Puranjay Mohan Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20260708072106.199637-2-sanghyun.park.cnu@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit cab81e3ad948565a72279fc725658f442caa988c Author: Breno Leitao Date: Tue Jun 16 05:09:34 2026 -0700 efi: fix stale reference to efi_recover_from_page_fault() [ Upstream commit 718ee46ba4d95d28d50d3f6437afbbe2be531175 ] efi_recover_from_page_fault() was renamed to efi_crash_gracefully_on_page_fault(), but the comment above enum efi_rts_ids was not updated. Use the current name. Fixes: c46f52231e79 ("x86/{fault,efi}: Fix and rename efi_recover_from_page_fault()") Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 86d11c594d60b255b526fa5260f669463fb1a063 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 8e29690f91286e488a10c552cf58b61a93a18b0d Author: Tanushree Shah Date: Wed Jul 8 16:56:08 2026 +0530 perf dso: Fix kallsyms DSO detection with fallback logic [ Upstream commit 8c5f60344b07f839267c0c835962e2206143be85 ] The current kallsyms detection in dso__is_kallsyms() uses the dso_binary_type enum which fixes the issue of kallsyms being cached in the build-id cache for out-of-tree modules. However, during build-id injection in perf record/inject, dso_binary_type has not been explicitly set yet,so dso__binary_type() returns DSO_BINARY_TYPE__NOT_FOUND instead of DSO_BINARY_TYPE__KALLSYMS for the kernel DSO. The current check then fails to identify it as kallsyms, causing build-id symlinks to not be created in ~/.debug/.build-id/ and perf archive to fail with "Cannot stat" errors. Steps to reproduce the issue: 1. rm -rf ~/.debug/.build-id 2. perf record sleep 1 3. perf archive Fix by falling back to matching long_name against the known kallsyms strings explicitly when binary_type is not yet set (== DSO_BINARY_TYPE__NOT_FOUND). Use strcmp() for exact matching of fixed names and strict validation for guest kallsyms with embedded PID to prevent path traversal attacks. Fixes: ebf0b332732d ("perf dso: fix dso__is_kallsyms() check") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 20740a2115723958b3e2b061a7c3762d8cefb4ef Author: Sandipan Das Date: Wed Jul 8 00:34:01 2026 +0530 perf vendor events amd: Reintroduce deprecated Zen 5 core events [ Upstream commit eda39f98bbc5ce8b7b0be10193d2de38ed59da6c ] Maintain backward compatibility by reintroducing the events that were previously removed by commit 047979af3bf6 ("perf vendor events amd: Update Zen 5 core events"). Also set the deprecated flag and update the descriptions to point users to the correct alternative. Reported-by: Ian Rogers Closes: https://lore.kernel.org/all/CAP-5=fV_czvd-z4N7K+_SabxuOm9UUHRyBxNuchrtAgJL3OqOw@mail.gmail.com/ Fixes: 047979af3bf6 ("perf vendor events amd: Update Zen 5 core events") Signed-off-by: Sandipan Das Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7ff668cfc3960ed5b944ac35129f18a15ea08b74 Author: Geoffrey McRae Date: Sun Jun 28 15:37:02 2026 +1000 drm/amdgpu/mes: Fix hung_queue_db_array loop limit for multi-XCC [ Upstream commit 2c256086a363f01f9840a57949506eccf5c990a6 ] The loop iterated only AMDGPU_MAX_MES_PIPES times, leaving entries uninitialized for multi-XCC GPUs. This causes null pointer dereferences when accessing arrays indexed by XCC ID >= 2. Extend the loop to cover all XCCs (AMDGPU_MAX_MES_PIPES * num_xcc), matching other per-XCC arrays. Fixes: a132fc9bc2f8 ("drm/amdgpu: Fixup boost mes detect hang array size") Signed-off-by: Geoffrey McRae Reviewed-by: Amber Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 272c97f9286d5dcf305940abb80ec7c597c9de53 Author: Daniel Borkmann Date: Wed Jul 8 09:53:39 2026 +0200 bpftool: Check EVP_Digest when computing excl_prog_hash [ Upstream commit 576bcaa1f5c208af0f590c9622247da87b49c05f ] bpftool_prog_sign() ignores the return value of EVP_Digest(). If the digest computation fails (context allocation failure, or a digest fetch failure under OpenSSL), EVP_Digest() returns 0 and leaves the output buffer untouched, but the function still reports success. Fixes: 40863f4d6ef2 ("bpftool: Add support for signing BPF programs") Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260708075343.358712-5-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c4058355d27488a3cd31c60c032335f77c4fdcfc 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 6be64cca6527f7fc99b05abf54f22db91bbc116f 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 62efee351566321ad72a4abaf6eb7d972590585d Author: Bjorn Andersson Date: Thu Jun 11 22:22:02 2026 +0000 usb: typec: ucsi: unregister debugfs entries on teardown [ Upstream commit eed73a65ab609b79d53de88cccc34b36dfe753c4 ] ucsi_register() creates per-instance debugfs entries, but ucsi_unregister() keeps them around until ucsi_destroy(). Drivers like ucsi_glink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log: debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi' Unregister debugfs entries as part of ucsi_unregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe. Assisted-by: Codex:GPT-5.5 Signed-off-by: Bjorn Andersson Fixes: df0383ffad64 ("usb: typec: ucsi: Add debugfs for ucsi commands") Tested-by: Konrad Dybcio # X1E80100 CRD Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260611-usci-unregister-debugfs-v1-1-f4a518a94f27@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d67607e7749527850619a10d3ed033b02dcea516 Author: Dan Carpenter Date: Fri Jun 26 13:38:22 2026 +0300 thermal/drivers/rcar: Fix error checking in probe() [ Upstream commit dd04ad1cdabcad51e34b74b4e91b9aeb7180d05d ] This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of "priv->zone". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly. Fixes: bbcf90c0646a ("thermal: Explicitly enable non-changing thermal zone devices") Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Dan Carpenter Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/aj5WnseULiwgmlWv@stanley.mountain Signed-off-by: Sasha Levin commit 437d6d15936db87485afabf7d52754b7b19cc787 Author: Vidhu Sarwal Date: Sat Jul 4 14:00:31 2026 +0530 staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() [ Upstream commit b298b80814dd0fc3cb1c8c0e0082fc14fdb5fecf ] ipu7_resume() calls pm_runtime_get_sync() before resuming the device. If the runtime PM resume fails, the usage count remains incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count on failure and avoids the leak. Keep returning 0 on error, as resume callbacks should not propagate failures to the PM core, matching the behaviour of the ipu6 driver. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Vidhu Sarwal Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit acd23fc1af6f7fac1d2b105ae8d5628c1b812adc Author: Vidhu Sarwal Date: Sat Jul 4 14:00:30 2026 +0530 staging: media: ipu7: fix pm_runtime refcount leak in ipu7_init_fw_code_region_by_sys() [ Upstream commit 843644e1c3347670498d247d7cd20dff1569181c ] ipu7_init_fw_code_region_by_sys() calls pm_runtime_get_sync() before accessing the firmware code region. If resuming the device fails, pm_runtime_get_sync() leaves the runtime PM usage count incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count automatically on failure and avoids the leak. The ipu6 driver uses pm_runtime_resume_and_get() in the equivalent location. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Vidhu Sarwal Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 19d5566b84ca1af0256d0d0003e1a081580c3ba3 Author: Nicholas Dudar Date: Wed Jul 8 05:07:50 2026 +0200 bpf: Reject writes through untrusted BTF pointers [ Upstream commit ac65c710cc643cbc52b899627577357867249530 ] check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases. Fixes: 282de143ead9 ("bpf: Introduce allocated objects support") Signed-off-by: Nicholas Dudar Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Eduard Zingerman Reviewed-by: Amery Hung Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 1238e1c7e5d3d0ef37124475047fc0731752dbf8 Author: Tanushree Shah Date: Thu Jun 4 12:25:19 2026 +0530 perf data convert json: Fix trace_seq memory leak in process_sample_event() [ Upstream commit dcb87c88952046ef43cb5ba3a5b95eb29c362a16 ] Unlike the in-kernel trace_seq which uses a statically allocated buffer, the userspace traceevent library's trace_seq uses a dynamically allocated one. Therefore, every trace_seq_init() call must be paired with a trace_seq_destroy(), otherwise it produces a memory leak. In process_sample_event(), a trace_seq is initialized for each field when formatting tracepoint raw_data, but the matching trace_seq_destroy() is never called, leaking memory for every field of every sample processed. Add the missing trace_seq_destroy() after using the trace_seq buffer to properly free the allocated memory. Detected with Valgrind on a perf.data file with 2,729 tracepoint samples: Before: definitely lost: 55,537,664 bytes in 13,559 blocks After: definitely lost: 0 bytes in 0 blocks Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6993d1fdb9de2788ac4185c790c8a9b00cb9f6b3 Author: Jiawei Sun Date: Tue Jul 7 23:38:00 2026 +0800 perf record: fix poll storm when monitored threads exit [ Upstream commit f94563fac26912ef5a51fd16ae1d83f17b24b19d ] When `perf record` samples a multi-threaded process and one of the target threads exits during the session, perf itself may start burning 100% CPU (up to 200% across two cores) until the session ends. A single dead fd is sufficient to trigger this; it can be reproduced with 15 pthreads in a compute loop where one thread exits halfway through. The root cause is two independent instances of the same defect: dead perf_event ring-buffer fds are left in a pollfd array. When a monitored thread exits, the kernel closes its ring-buffer fd, which then returns POLLHUP. POSIX specifies that poll() always reports POLLHUP and POLLERR regardless of the events mask, so any dead fd left in the array makes poll() return immediately every time, spinning in a tight loop: 3 seconds: 256,600 poll() calls, 0 context switches, only 21 write() Woken up count goes from ~0 to 1,300,000+ There are two affected poll paths, fixed together here: 1. Record main loop, via fdarray__filter() (tools/lib/api/fd/array.c). Since commit 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") it only zeroes events/revents without setting fd to -1, so poll() keeps reporting POLLHUP for the entry. Setting fd = -1 makes poll() skip it, matching the pattern already used in the control-fd path at tools/perf/builtin-record.c:1673. 2. BPF sideband thread, perf_evlist__poll_thread() (tools/perf/util/sideband_evlist.c). This thread polls for PERF_RECORD_BPF_EVENT but, unlike the main record loop, never calls fdarray__filter() at all, so dead fds accumulate forever and it spins at 100% CPU: Before fix: dJiffies=101, wchan=0 (running) After fix: dJiffies=0, wchan=do_sys_poll (blocking) Fixed by calling the existing evlist__filter_pollfd() helper after evlist__poll(), mirroring the main record loop. is included for the POLLERR/POLLHUP macros (previously unused there). The two fixes compose: fix 1 makes poll() ignore dead fds (fd=-1); fix 2 ensures the sideband thread actually performs the filtering. Both paths are affected in all kernels from v5.1/v5.9 to the current master (7.2-rc1); the source of both functions is byte-identical across them. BPF event recording is preserved: after the fix, perf.data still contains PERF_RECORD_BPF_EVENT records and bpf_prog_info entries. Verified on perf 6.1.76, 6.6.143 and 7.2-rc1 with a minimal reproducer (Woken up 1,300,000 -> 3, CPU 100% -> 0%) and an A/B orthogonal test: keeping the unpatched binary but preventing the target thread from exiting also makes the storm disappear, confirming the trigger. Fixes: 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") Fixes: 657ee5531903 ("perf evlist: Introduce side band thread") Signed-off-by: Jiawei Sun Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f7a1cf9f679da5c1f007232fcd3396dc3989d1fc Author: Loic Poulain Date: Mon Jun 29 21:22:56 2026 +0200 clk: qcom: gcc-qcs8300: Use retention for USB power domains [ Upstream commit d8638610e0c9ebab2800b7ad6c2c2a3737090da9 ] The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.1.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-2-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8dcdeb8e2337c620efde657b07be103e74ae907e Author: Loic Poulain Date: Mon Jun 29 21:22:55 2026 +0200 clk: qcom: gcc-qcs8300: Use retention for PCIe power domains [ Upstream commit 11b170abe4d324cac0d15a410282d1ec2b6bafa0 ] As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. Fix the PCIe link not surviving upon resume, and GDSC error: gcc_pcie_0_gdsc status stuck at 'off' Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-1-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6ccc420af8188055e97ad873fbb1059cf9d30515 Author: Konrad Dybcio Date: Tue Jun 16 11:08:52 2026 +0200 arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net [ Upstream commit d5f5c089858f7accd1e4574c0c09d811e90eb51f ] Describe and wire up the power supplies for the eDP panel and its backlight. Previously, this was only working because of settings inherited from the bootloader. Fixes: 20dea72a393c ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-4-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d6f9c6e845235b4f293ae186e9c1d8cc5abf533 Author: Konrad Dybcio Date: Tue Jun 16 11:08:51 2026 +0200 arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes [ Upstream commit 0b1c6d2a65fc41aa0d5f6617dd04043384678d61 ] Align with the contemporary way of naming regulator nodes (regulator- prefix) in preparation for adding more of them. Reorder the renamed entries to match the expectations of the DT coding style doc. Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-3-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: d5f5c089858f ("arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net") Signed-off-by: Sasha Levin commit c7e72d6d5126e2ba8879f751fd7cdf801d49a71b Author: Konrad Dybcio Date: Tue Jun 16 11:08:50 2026 +0200 arm64: dts: qcom: sc8180x-primus: Describe the display power net [ Upstream commit 80bf2eb87bfbf1b7bc7b12228cbcc710b0a26275 ] Describe and wire up the power supplies for the eDP panel and its backlight. Previously, this was only working because of settings inherited from the bootloader. Fixes: 2ce38cc1e8fe ("arm64: dts: qcom: sc8180x: Introduce Primus") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-2-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c64326ede83c26b092525f717e1047c235725f1a Author: Konrad Dybcio Date: Tue Jun 16 11:08:49 2026 +0200 arm64: dts: qcom: sc8180x-primus: Rename regulator nodes [ Upstream commit ae51d9396f9318189e91578878409d8ada152edb ] The nodes would be sorted correctly, if their names started with "regulator-" (which is the style used in the latest submissions). Touch that up. Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-1-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 80bf2eb87bfb ("arm64: dts: qcom: sc8180x-primus: Describe the display power net") Signed-off-by: Sasha Levin commit 9ff0ec945a73f4117f0af27484dcf4f9bdfe0a84 Author: Richard Acayan Date: Mon Jun 1 22:17:22 2026 -0400 arm64: dts: qcom: sdm670-google: add lpi reserved gpios [ Upstream commit 71dd62dac8e2d03f952587f8985a859fce422815 ] Add reserved GPIOs for the Pixel 3a, which blocks access to the sensor GPIOs. The hunk in the original patch was dropped in the commit because it depended on an unapplied patch, which is now commit fe9f4a46895d ("arm64: dts: qcom: sdm670-google: add common device tree include"). Fixes: c4b423835ee7 ("arm64: dts: qcom: sdm670: add lpi pinctrl") Signed-off-by: Richard Acayan Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602021722.30760-1-mailingradian@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 488c42ff7f42fba4fd4a0d75de2b1b4f6ac5d58d Author: Yedaya Katsman Date: Mon Jun 8 23:10:23 2026 +0300 arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Fixup panel compatible [ Upstream commit f135fd1bc76d052f1bf4b1cc987cd47fe0a71d8a ] The change to the panel compatible was missed, fix it. This compatible is already in the driver. Fixes: 493cb869874c ("arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Enable MDSS and add panel") Signed-off-by: Yedaya Katsman Reviewed-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260608-b4-compatible-s6e8fc0-fixup-v2-1-d23f373603a3@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 07bb368ae12b85fb95b1cae9eaa456cfd2c71af4 Author: Jérôme de Bretagne Date: Thu Jun 4 18:18:40 2026 +0200 arm64: dts: qcom: sc8280xp-arcata: Fix top USB-C DP alt mode [ Upstream commit 16065c4ec1e7ca595f4fa363dc2251c6bdf1f6b3 ] The top USB-C port (usb0) didn't switch to DP alt mode, as reusing the same GPIO 101 as on the SC8280XP CRD or Lenovo ThinkPad X13s was not working on the Surface Pro 9 5G. Investigation [1] by Jens on the Windows Dev Kit (WDK2023), the other sc8280xp-based "blackrock" model from Microsoft, found a reference to GPIO 100 in the DSDT in addition to 101. Switching to GPIO 100 fixed the issue on blackrock, as it does on arcata to enable external screen when using the left-side top USB-C port. [1] https://lore.kernel.org/all/20250609-blackrock-usb0-mux-v1-1-7903c3b071e4@oldschoolsolutions.biz/ Cc: Jens Glathe Fixes: f6231a2eefd4 ("arm64: dts: qcom: sc8280xp: Add Microsoft Surface Pro 9 5G") Reviewed-by: Konrad Dybcio Signed-off-by: Jérôme de Bretagne Link: https://lore.kernel.org/r/20260604-surface-sp9-5g-for-next-v3-4-6aa6f6612c10@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 40bd77fa2857ccfa77b885b77d44cea406f24a4c 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 fade2037ee2aae2ac8658a4e7ab541fa8cd03104 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 02533b6cf5f6933af93638c8baf6846c362428d0 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 609ebd03deee4567052003020934f57af6441231 Author: Brian Norris Date: Tue Apr 28 13:06:59 2026 -0700 arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit 2a906f0b4f037b3fe5f790a48f88549a86288fdf ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: / { firmware { ranges; coreboot { compatible = "coreboot"; reg = <...>; ...; }; }; }; Notably, the /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20260428200712.2660635-8-briannorris@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ac2f3219b3303cf2976137be1dab393190370226 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 ad25b583d5919e75eee6512559070955ea6386f6 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 1f0c3c0c36c7aedf55a60d9c71c4bd258b8937ce Author: Malaya Kumar Rout Date: Sat Jul 4 15:04:28 2026 +0530 time/namespace: Validate nanosecond field in proc_timens_set_offset() [ Upstream commit 06aba58e58492d2b8eae059274caed29025ea96e ] The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition. Fixes: 04a8682a71be ("fs/proc: Introduce /proc/pid/timens_offsets") Signed-off-by: Malaya Kumar Rout Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260704093429.89350-1-malayarout91@gmail.com Signed-off-by: Sasha Levin commit a36bf15ab84c5b6b6bbaefb85257b902fe2d6fd7 Author: Malaya Kumar Rout Date: Sat Jul 4 14:25:33 2026 +0530 timers/migration: Fix memory leak in tmigr_setup_groups() error path [ Upstream commit eddfded4196542deda7cb2da3d7ebef83f7ccfa4 ] When the WARN_ON_ONCE(i >= tmigr_hierarchy_levels) assertion triggers, the function returns -EINVAL without freeing the 'stack' memory allocated via kzalloc_objs() at the beginning of the function. Add kfree(stack) before returning to prevent the memory leak. Fixes: 6c181b5667ee ("timers/migration: Convert "while" loops to use "for"") Signed-off-by: Malaya Kumar Rout Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260704085533.87098-1-malayarout91@gmail.com Signed-off-by: Sasha Levin commit 7099de4de14af657ad8378da2b9df5c433a9ba95 Author: Yuho Choi Date: Fri Jul 3 12:53:37 2026 -0400 timekeeping: Unwind aux clock sysfs children on failure [ Upstream commit f2eee7e31ccd4bc87d047d8670cc2ec39cf36647 ] tk_aux_sysfs_init() creates one child kobject per auxiliary clock. If a later child or sysfs group creation fails, the current error path only puts the parent kobjects and leaves earlier children and groups behind. Store the child kobjects during init and remove the successfully created groups and kobjects on failure. Fixes: 7b5ab04f035f ("timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths") Signed-off-by: Yuho Choi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260703165337.168445-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 2a4ffc16d3a78a381cc38a67d877d1564a1e059d 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 d739c63bfa38524228c2f5b26ba8c10fa4f277f2 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 dd32537936976dbad4a0f453c63c203614ab8d4c Author: Kemeng Shi Date: Thu Jul 2 11:30:46 2026 +0800 irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its() [ Upstream commit 698a8648ca8051d34722b09b8a8088c741120ac3 ] Fix its node leak when its_probe_one() failed in gic_acpi_parse_madt_its(). Fixes: 9585a495ac936 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260702033050.1583-3-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit de5d0190c97fe6c0693178b6cdb7a86ab2b983c4 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 10f639168da5904ebc14761f50f4d89c7d3ef884 Author: Wang Yan Date: Fri Jul 3 20:09:51 2026 +0800 selftests/lsm: Fix memory leak in attr_lsm_count [ Upstream commit 0cee720cfd51402cfcb14d96cb326a36c13b823a ] The calloc-allocated buffer in attr_lsm_count() is never released on any exit path, including both the normal return path and the early return when read_sysfs_lsms fails, resulting in a heap memory leak. Add free() for the buffer on all return branches to fix the leak. Fixes: d3d929a8b0cd ("LSM: selftests for Linux Security Module syscalls") Signed-off-by: Wang Yan Reviewed-by: William Roberts Tested-by: William Roberts Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit ab0c755ad5e7acac2df0248c4e1bdf932684c7c3 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 88500a86ab79f01c568de6ed00f5b1c5c79f11d5 Author: Maxim Khmelevskii Date: Fri Jul 3 14:51:35 2026 +0200 s390/bpf: Replace ly instruction with llgf [ Upstream commit 5f6cc299938b561cb01e343bab7042611fcee12a ] cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does. Fixes: 9012cf2491e3 ("s390/bpf: Inline smp_processor_id and current_task") Signed-off-by: Maxim Khmelevskii Signed-off-by: Daniel Borkmann Reviewed-by: Ilya Leoshkevich Link: https://sashiko.dev/#/patchset/20260414142930.528751-1-max%40linux.ibm.com Link: https://lore.kernel.org/bpf/20260703125648.919196-5-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e626a50d07d43421cbf7bfb5a084b33a5e276b6e Author: Yiyang Chen Date: Tue Jun 30 08:41:26 2026 +0000 bpf: Reject MEM_ALLOC BTF accesses past object bounds [ Upstream commit 9c9ee0324c774490ae953162aaaf4561d222bd93 ] BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen Reviewed-by: Amery Hung Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 5280e0d3d6a5c020bc8704c538469bdd955d64b3 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 09160051954886b0882dd6e01db14371a0b41da5 Author: Emil Tsalapatis Date: Mon Jul 6 14:17:27 2026 -0400 selftests/bpf: libarena: Clean up allocation state before buddy tests [ Upstream commit 14c2b770d15d5b0d814cdef114de55e01a281e00 ] Summary: The buddy allocator requires the global BPF buddy allocator to not be already initialized. However, the test currently merely resets the allocator before the buddy tests instead of destroying it, and the test worked because the buddy test happened to run first. Properly destroy the allocator instead of resetting it. Fixes: b1487dc1b181 ("selftests/bpf: Add selftests for libarena buddy allocator") Signed-off-by: Emil Tsalapatis Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260706181730.21731-4-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c812c2ff5507dedb2ad64316b085ecb9bcf816ca 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 08d6d9800e2e1456d00ae6a257201acce4d00360 Author: Thomas Weißschuh Date: Fri Jul 3 08:04:08 2026 +0200 kbuild: unset sub_make_done before calling kselftest build system [ Upstream commit e77f165d26f72c280654cff248f5106cb9a53951 ] The kselftest build system may recourse back into kbuild when building test modules. In that case kbuild needs to parse the new flags passed from the command line, instead of using the ones inherited from the kbuild invocation. Force that command line reevaluation. The same was done for scripts/install.sh in commit 14ccc638b02f9ec ("kbuild: cancel sub_make_done for the install target to fix DKMS") Reported-by: Zelin Deng Closes: https://lore.kernel.org/all/20260525083721.27857-1-zelin.deng@linux.alibaba.com/ Fixes: c9bb03ac2c66 ("kbuild: reduce output spam when building out of tree") Signed-off-by: Thomas Weißschuh Acked-by: Miroslav Benes Acked-by: Petr Mladek Tested-by: Zelin Deng Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260703-makefile-unset-submake-done-v1-1-6899248f3d6a@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 911190f0b9511c3c81f2f2484414c1ae26f636b3 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 b2243ffaac14cc3639b5b32a371aac37f96ee554 Author: Ayush Mukkanwar Date: Mon Jun 15 22:57:34 2026 +0530 staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown [ Upstream commit c0a9a8586a63fda49e61a6b83360feac2a60d898 ] cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash. Fixes: 3368c784bcf7 ("Staging: Octeon Ethernet: Convert to NAPI.") 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-2-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 41a79bd9e5a74f8f483b3b206d10567912874fb4 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 b7fa32159dc5106abd8c9a954d0291e5f11f76e7 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 cfcc5a41a9664eb68023aae4cd0d485b256bd7c7 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 d13a82297796b339528343ae4071ff3dcecedd4d Author: Rong Zhang Date: Wed Jun 3 02:51:42 2026 +0800 staging: sm750fb: Add missing Kconfig dependency [ Upstream commit da8fd33e7d6af4c069668c2d42234b969f706885 ] The sm750 frame buffer driver depends on FB_IOMEM_FOPS, but its Kconfig somehow misses it. Fix it by making FB_SM750 select FB_IOMEM_FOPS, as other frame buffer drivers do. Fixes: dc0ad215e5d8 ("staging/sm750fb: Initialize fb_ops with fbdev macros") Signed-off-by: Rong Zhang Link: https://patch.msgid.link/20260603-sm750-fb-iomem-kconfig-v1-1-7f6a3046cce2@rong.moe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dd5767bd42401342eef81319a7d98733aac0f122 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 fbf9e0f2d5369824df051cbd7b35dd9b4adc3a0c 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 1c2a4ab6efa26415dd131b8c222e7893fda03435 Author: Cen Zhang Date: Tue Jul 7 00:18:22 2026 +0800 wifi: mac80211_hwsim: avoid NULL skb in stop queue drain [ Upstream commit 158438cd6ad69d6dd7d871582c38baf22169fede ] mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate. Fixes: bd18de517923 ("mac80211_hwsim: drop pending frames on stop") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260706161822.921039-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b2adb0e2f313e26a040b7ee233ecadd484233734 Author: Manivannan Sadhasivam Date: Tue Jun 16 21:45:19 2026 +0530 PCI: qcom: Skip PERST# GPIOs provided by downstream PCIe devices [ Upstream commit 3edb3a038d423480efeb204dbc6ddc9a292f8ecb ] Currently, the pcie-qcom driver recursively parses the PERST# GPIO from all child nodes defined in DT and acquires them. But this creates issues with PERST# GPIO provided by one of the child devices like the PCIe switch port. In this case, the RC driver cannot acquire the PERST# GPIO since it will be provided by the child PCIe device which was not yet enumerated during RC driver probe. Fix this by checking if the GPIO provider is a child of the RC's DT node (i.e., sits behind this PCIe controller). If so, skip it, as PERST# should be controlled by the respective PCIe client driver implementation. GPIOs provided by external GPIO controllers (e.g., TLMM in Qcom SoCs) continue to be handled normally. Fixes: 2fd60a2edb83 ("PCI: qcom: Parse PERST# from all PCIe bridge nodes") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260616-pci-qcom-perst-fix-v1-1-27600d6ae357@oss.qualcomm.com Signed-off-by: Sasha Levin commit c6eca03162e1c9c17aca04a13c3318f579f2cb52 Author: Ruoyu Wang Date: Sat Jun 20 16:04:06 2026 +0800 bus: qcom-ebi2: Fix clock leak on probe failure [ Upstream commit 64774dea58969194ea5c27fa639954e551a87024 ] qcom_ebi2_probe() enables the EBI2X and EBI2 clocks before it walks child nodes and populates child devices. If reading a child node's reg property fails, or if of_platform_default_populate() fails, probe returns without disabling either clock. Route those failure paths through the existing clock cleanup labels so a failed probe does not leave the clocks prepared and enabled. Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260620080406.1970447-1-ruoyuw560@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f28e119378322cbfd13e0d5ce49e627a14002646 Author: Dmitry Baryshkov Date: Fri May 15 13:56:36 2026 +0300 arm64: dts: qcom: sc8280xp: sort reserved memory regions [ Upstream commit 53275adfb07d416a32004612227265939d0df00d ] Move memory region reserved for the GPU to its proper place in DT. Fixes: 6e9612ced0c9 ("arm64: dts: qcom: sc8280xp: create common zap-shader node") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260515-iris-sc8280xp-v7-2-2e21f6db1897@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7a9ab46f1e2ebb3a87d7ea8e4c3e03db5e24ccfe Author: Taniya Das Date: Wed Jun 17 16:37:52 2026 +0530 clk: qcom: gcc-glymur: Move EVA clocks to critical clock list [ Upstream commit 7399034fd78615ba826b864fca2e4572f13cf8e3 ] The gcc_eva_ahb_clk and gcc_eva_xo_clk branch clocks should not be registered as standalone GCC branch clocks. Drop these clocks from the GCC clock list and instead add their CBCR registers to the GCC critical clocks list to ensure they remain enabled during early boot. If these clocks are registered as normal branch clocks, they may be gated, which breaks access to the EVA clock controller during clock controller probe, thus leave them as critical clocks similar to other subsystem AHB and XO clocks. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260617-evacc_glymur-v2-1-905108dacaaa@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 784d168036a4b9a6ed84f9dc10003b5721588bb7 Author: Pradyot Kumar Nayak Date: Fri May 22 15:26:39 2026 +0530 arm64: dts: glymur-crd: Add reset GPIO to touchscreen node [ Upstream commit f64ef325f1d9ca9d005b7124c2bf065bb0b99c3d ] The touchscreen module on Glymur/Mahua CRDs is different from the one used on Hamoa CRDs and requires the reset-gpios to be wired to the device. Without this in place the reset line will remain permanently asserted during resume leaving the device offline and causing all I2C transactions to fail with -ENXIO. Error Logs: i2c_hid_of 3-0038: failed to change power setting. i2c_hid_of 3-0038: PM: dpm_run_callback(): i2c_hid_core_pm_resume [i2c_hid] returns -6 i2c_hid_of 3-0038: PM: failed to resume async: error -6 Add the reset GPIO so the driver can deassert the line on resume, restoring I2C communication with the device. Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen") Signed-off-by: Pradyot Kumar Nayak Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260522-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-v1-1-c7653924acdc@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 368b8e4299650204e8e28fbc8e0aa660a7f55933 Author: Gopikrishna Garmidi Date: Mon Jun 29 03:22:57 2026 -0700 arm64: dts: qcom: glymur-crd: Move common board nodes to shared DTSI [ Upstream commit 711e6f11640f800f649d416b260c7f8555b0c955 ] Mahua CRD is pin-to-pin compatible with Glymur CRD, as verified against schematics; only the external peripherals connected differ. Move the common board nodes from glymur-crd.dts to glymur-crd.dtsi to enable reuse by Mahua CRD. Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Pankaj Patil Signed-off-by: Gopikrishna Garmidi Link: https://lore.kernel.org/r/20260629-glymur-mahua-common-nodes-v3-1-98cc00943359@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: f64ef325f1d9 ("arm64: dts: glymur-crd: Add reset GPIO to touchscreen node") Signed-off-by: Sasha Levin commit 45f5512f1311359cac79cc93d2b89d168618d8c7 Author: Sibi Sankar Date: Mon May 11 18:13:21 2026 +0530 arm64: dts: qcom: glymur-crd: Add Embedded controller node [ Upstream commit 44c655a08c9ee9590e64f8306a66917bbb629970 ] Add embedded controller node for Glymur CRDs which adds fan control, temperature sensors, access to EC state changes through SCI events and suspend entry/exit notifications to the EC. Signed-off-by: Sibi Sankar Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Co-developed-by: Anvesh Jain P Signed-off-by: Anvesh Jain P Tested-by: Anthony Ruhier Link: https://lore.kernel.org/r/20260511-add-driver-for-ec-v9-3-e5437c39b7f8@oss.qualcomm.com [bjorn: Added i2c alias for &i2c9] Signed-off-by: Bjorn Andersson Stable-dep-of: f64ef325f1d9 ("arm64: dts: glymur-crd: Add reset GPIO to touchscreen node") Signed-off-by: Sasha Levin commit 6f1ed14f6c5e14e0d7604e6cf841384a7f143625 Author: Gopikrishna Garmidi Date: Tue Jun 2 09:51:35 2026 -0700 arm64: dts: qcom: glymur: Fix gcc clock specifier for usb_mp_qmpphy nodes [ Upstream commit eca50d95b60cdcabb82a8e1b727fad2547e52f1d ] usb_mp_qmpphy0 and usb_mp_qmpphy1 have #clock-cells set to 0 so they take no specifier. Drop the erroneous QMP_USB43DP_USB3_PIPE_CLK argument. This fixes the following dtbs_check warning: clock-controller@100000 (qcom,glymur-gcc): clocks: [[59, 0], ..... [0]] is too long from schema $id: http://devicetree.org/schemas/clock/qcom,glymur-gcc.yaml Fixes: 4eee57dd4df9f ("arm64: dts: qcom: glymur: Add USB related nodes") Signed-off-by: Gopikrishna Garmidi Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Pankaj Patil Link: https://lore.kernel.org/r/20260602-glymur-fix-usb-mp-qmpphy-clock-specifier-v1-1-19c6f44d5655@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 144094da5b9171b24903543f344d6db7dee06081 Author: Gopikrishna Garmidi Date: Mon May 18 04:16:17 2026 -0700 arm64: dts: qcom: glymur: Fix unit-address mismatch for spmi_bus2 [ Upstream commit 82a766b68cd4d323b302a28082fbb7924f1146e6 ] The spmi_bus2 node was named spmi@c48000, but its reg property specifies the base address as 0x0c448000. Fix the node name to spmi@c448000 to match the actual register base address. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Gopikrishna Garmidi Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260518-glymur-fix-spmi-bus2-unit-addr-v1-1-27d6edca51e8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da9ddc8ba43cae26b8db5a12f3b49af89b079f9a Author: Konrad Dybcio Date: Mon May 18 11:54:39 2026 +0200 arm64: dts: qcom: hamoa: Fix clocks for HSPHYs [ Upstream commit 115894bc201b0cd1799d239875a1b40924f0ef7b ] The tertiary controller's HSPHY has its own toggle in TCSR, while the primary one is wired directly to the XO clock. Fix that. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260518-topic-hamoa_hsphy_clk-v1-1-d85203756505@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 19c802bcaf7643229d5f13855a34d5e3b0942c98 Author: Biswapriyo Nath Date: Mon Mar 30 10:13:48 2026 +0000 arm64: dts: qcom: sm6125: Use 64 bit addressing [ Upstream commit 88f8e2ca76ee9999c1f21d020362e6588a6d5ef5 ] SM6125's SMMU uses 36bit VAs, which is a good indicator that we should increase (dma-)ranges - and by extension #address- and #size-cells to prevent things from getting lost in translation (both literally and figuratively). Do so. Fixes: 7bb7c90e0ac1 ("arm64: dts: qcom: Add Redmi Note 8T") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603141433.MDqfoVHn-lkp@intel.com/ Reviewed-by: Konrad Dybcio Signed-off-by: Biswapriyo Nath Link: https://lore.kernel.org/r/20260330-ginkgo-add-usb-ir-vib-v3-1-c4b778b0d7f8@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f78fcc42099fee55ee86c0e88fc82b8c788af793 Author: Luca Weiss Date: Tue May 5 17:08:35 2026 +0200 arm64: dts: qcom: sm7225-fairphone-fp4: Fix address in fb node name [ Upstream commit f6e65005fe55c3d09287851523de06367cbf0bc2 ] 'reg' is 0xa0000000 so the node name is missing a zero. Add it, so that the reg and address in the node name matches. No functional impact. Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260505-sm6350-misc-v1-3-0b9efc22690c@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e7483891df45e733ce9c9ba579f5d24df31a465f Author: Jens Glathe Date: Fri May 1 11:11:29 2026 +0200 arm64: dts: qcom: sc8280xp-blackrock: switch to uefi rtc offset [ Upstream commit f52102fc9ccbbb3c4bc01a29f3194fe07f9602f5 ] On many Qualcomm platforms the PMIC RTC control and time registers are read-only so that the RTC time can not be updated. Instead an offset needs be stored in some machine-specific non-volatile memory, which a driver can take into account. On platforms where the offset is stored in a Qualcomm specific UEFI variable the variables are also accessed in a non-standard way, which means that the OS cannot assume that the variable service is available by the time the RTC driver probes. Use the new 'qcom,uefi-rtc-info' property to indicate that the offset is stored in a UEFI variable so that the OS can determine whether to wait for it to become available. [1]: https://lore.kernel.org/r/20250423075143.11157-4-johan+linaro@kernel.org Fixes: 16a7fed11714 ("arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023") Signed-off-by: Jens Glathe Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260501-blackrock-rtc-v1-1-bddf3e37fa94@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4b6f2aebaa922e798d7192753a1a53fb4e8a2e96 Author: Jie Gan Date: Tue Apr 28 13:54:21 2026 +0800 arm64: dts: qcom: monaco: fix wrong connection for the replicator [ Upstream commit bf949e86fb5c3034b70b62c9ee31b3d88d5f7fb5 ] Fix the wrong connection for the qdss replicator device. Fixes: 4f791e008807a ("arm64: dts: qcom: monaco: Add CTCU and ETR nodes") Signed-off-by: Jie Gan Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260428-fix-monaco-coresight-dt-v2-1-2293259bbd10@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bee77cd34ce837cb626b62877f2682e163c10609 Author: Taniya Das Date: Mon Apr 27 12:08:56 2026 +0530 clk: qcom: gxclkctl: Use custom disable callback for gx_gdsc [ Upstream commit badf361c00c802738c776fb5f4e8b08b4d0bad1c ] The GX GDSC represents a special GPU power domain that must not be disabled during normal runtime PM flows. As per the GMU architecture, GX GDSC should only be force-disabled during GMU/GPU recovery, where the OS explicitly resets the GX power domain. However, when managed by the generic GDSC runtime PM path, GX GDSC may be disabled during GMU runtime suspend, resulting in warnings such as: gx_clkctl_gx_gdsc status stuck at 'on' and failures in gdsc_toggle_logic() during rpm suspend. Use the newly added custom disable callback for gx_gdsc to ensure the GDSC is toggled only in recovery scenarios, while preventing unintended disable attempts during normal GMU runtime PM operations. Reported-by: Pengyu Luo Closes: https://lore.kernel.org/all/CAH2e8h4Vp9fJYAUUbOmoHSKB25wakPBvmpwa62BTRqgRQbMWuw@mail.gmail.com/ Reported-by: Alexander Koskovich Closes: https://lore.kernel.org/all/gwVAH2mJerU4dBInw8pKmOs5aQK55Q7W6q_UQAlLFCsEgX6eyvSgXAWbNNMqAX4WmPlYCKUSMhfkr5Jry4Ps5EqnxYZqEEDd3Whwv7ZXGlc=@pm.me/ Fixes: 5af11acae660 ("clk: qcom: Add a driver for SM8750 GPU clocks") Reviewed-by: Konrad Dybcio Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-2-797e54b3d464@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dee085f96cb91e18d915c33efc6be506ac3b531f Author: Jagadeesh Kona Date: Mon Apr 27 12:08:55 2026 +0530 clk: qcom: gdsc: Add custom disable callback for GX GDSC [ Upstream commit 0661ee1d650facefdf61401c7d00eb96fad40b10 ] The GX GDSC is a special power domain that should only be disabled by OS during GMU recovery. In all other scenarios, the GMU firmware is responsible for handling its disable sequence, and OS must not interfere. During the resume_noirq() phase of system resume, the GenPD framework enables all power domains and later disables them in the complete() phase if there are no active votes from OS. This behavior can incorrectly disable the GX GDSC while the GMU firmware is still using it. To prevent this, implement a custom disable callback for GX GDSC that relies on GenPD’s synced_poweroff flag. The GMU driver sets this flag only during recovery, allowing OS to explicitly disable GX GDSC in hardware in that case. In all other situations, the disable callback will avoid touching GX GDSC hardware. Signed-off-by: Jagadeesh Kona Signed-off-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-1-797e54b3d464@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: badf361c00c8 ("clk: qcom: gxclkctl: Use custom disable callback for gx_gdsc") Signed-off-by: Sasha Levin commit 78d9daf5e13ad1448b7dfebac949936710ec7565 Author: Waiman Long Date: Thu Jul 2 17:47:47 2026 -0400 cgroup/cpuset: Make nr_deadline_tasks an atomic_t [ Upstream commit 95220e1f18f6321008f021abc7d6f581f64bcb82 ] The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com Fixes: 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets") Reviewed-by: Ridong Chen Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 195d7cca6433e7a0bc71dfa901a1a19bf0ef37f1 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 46b5a0f22bfd43c9a2bdbd3b2b0eca0a342f883d 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 d553a9dc1c45666e76d8d2ac9a4f8ff0cbf53a50 Author: Shin'ichiro Kawasaki Date: Mon Jun 29 14:15:28 2026 +0900 nvmet-rdma: fix response resource leak on queue teardown [ Upstream commit 0114dd303b373522dea06053aabae34bdd33a7c4 ] When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm "kworker/3:1H", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses. Fixes: 8f000cac6e7a ("nvmet-rdma: add a NVMe over Fabrics RDMA target driver") Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e24951cab8aa6a39cf276722b64af1e0e3a72f01 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 840ab22ffa4d859ca40a31e96fc3554688e7a035 Author: Gui-Dong Han Date: Thu Jun 18 10:15:43 2026 +0800 nvme-apple: Use acquire/release for queue enabled state [ Upstream commit f61c934aa084b7440fec681be3f4b481eb5a8609 ] apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Signed-off-by: Gui-Dong Han Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0550a269c04b8c56f1affc4fbc37f8c705e765f3 Author: Miklos Szeredi Date: Mon Jul 6 15:44:58 2026 +0200 fuse: move "epoch" from dentry.d_time to fuse_dentry.epoch [ Upstream commit 6648f54f3459c5d069b7ce294170d721ce9bac2f ] ...in hope of removing d_time one day. Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 02d4ee65dc2e883f554169155937742e6014c243 Author: Pengpeng Hou Date: Thu Jun 25 08:36:14 2026 +0800 RDMA/bng_re: return a timeout when firmware responses stall [ Upstream commit 5f9576c6734abca88a02db72c466e09d2eddf160 ] __wait_for_resp() documents that it returns a non-zero error when a firmware command does not complete, and bng_re_rcfw_send_message() already marks the firmware as stalled when the helper returns -ENODEV. However, the helper ignores wait_event_timeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever. Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer. Fixes: 53c6ee7d7f68 ("RDMA/bng_re: Enable Firmware channel and query device attributes") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260625003614.27515-1-pengpeng@iscas.ac.cn Reviewed-by: Siva Reddy Kallam Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ec790449ad2259679ec0f6322bcf8750774c8495 Author: Krzysztof Kozlowski Date: Thu May 28 14:03:43 2026 +0200 arm64: dts: qcom: talos: Fix GMU unit address [ Upstream commit 34a4ec6910e68ce06eb7201fa36778ca59a1e510 ] Correct unit address of GMU node to match 'reg' property and fix dtc W=1 warnings like: talos.dtsi:2020.20-2055.5: Warning (simple_bus_reg): /soc@0/gmu@506a000: simple-bus unit address format error, expected "506d000" Fixes: 8de397a5618a ("arm64: dts: qcom: talos: Add gpu and rgmu nodes") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260528120342.46343-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 59d485a6289cbcfe35742f62a109baf392225cd8 Author: Kuldeep Singh Date: Wed Apr 29 15:05:40 2026 +0530 arm64: dts: qcom: sm8750: wire UFS to ice instance [ Upstream commit ac456227d22952b656ad291ebd2d3d3e498e3d95 ] The Inline Crypto Engine (ICE) exists as a standalone DT node, but the UFS node lacks the required qcom,ice phandle reference. Add the qcom,ice property to explicitly associate the UFS controller with its ICE instance. Fixes: d288abc3a70e ("arm64: dts: qcom: sm8750: Add UFS nodes for SM8750 SoC") Signed-off-by: Kuldeep Singh Tested-by: Wenjia Zhang # on sm8750-mtp Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260429-sm8750_ice_dt_fix-v1-1-2540dc337082@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a6c0e693a7c881bfa43ac74cbcad1f8e10f1382b Author: Jacob Moroni Date: Thu Jun 18 20:14:58 2026 +0000 RDMA/irdma: Add refcounting to user ring MRs [ Upstream commit f67d8a08f60c9217df6d40da56422d2049f5e334 ] Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-5-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ff994bedc6690bcf235fa10d643faf3b7050060d Author: Jacob Moroni Date: Thu Jun 18 20:14:57 2026 +0000 RDMA/irdma: Add irdma_cq fields to track pbl allocations [ Upstream commit 971e99623ed7a0d75a719021cf4fd64e5f9e44e5 ] These fields will be used in a subsequent commit which adds refcounting to user CQ MRs. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-4-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit e4df2e98e43933b8edca33e0c8ce36143a7bdb57 Author: Jacob Moroni Date: Thu Jun 18 20:14:56 2026 +0000 RDMA/irdma: Add a refcount to track user ring MR associations [ Upstream commit a7d0a6b58256a77566e9088a99e1594bf35821ec ] User QP/CQ/SRQ rings are registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. In order to prevent userspace from deregistering these special MRs while the child object still exists, a refcount will be used. This commit adds the refcount and logic to reject a dereg_mr with active references. Subsequent commits will add logic to bump this refcount when the user QP/CQ/SRQ objects are created. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-3-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit dc043b8d976df9a7e15dce6493f77bd3394080bf Author: Jacob Moroni Date: Thu Jun 18 20:14:55 2026 +0000 RDMA/irdma: Deduplicate the irdma_del_memlist logic [ Upstream commit 097f50384e1877b7cf3ace12ff0d1beed19f2088 ] Simplify/dedup the irdma_del_memlist logic in preparation for the QP/CQ/SRQ ring MR refcounting change that will follow in a subsequent commit. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-2-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit a3217fe7998622728a53dff405615e0971949eaf Author: Myeonghun Pak Date: Wed Jun 24 16:15:49 2026 +0900 crypto: keembay - Fix AEAD unregister count in error path [ Upstream commit e264401ce4776a288524e5b87593d4d864147115 ] register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0a261177ad3245af393548d0632226d99c643191 Author: Pengpeng Hou Date: Tue Jun 23 21:55:28 2026 +0800 crypto: rk3288 - fail ahash requests on HASH idle timeout [ Upstream commit ae150db7826f21e8d19e54fb6243169628809c4d ] rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers. Fixes: 37bc22159c45 ("crypto: rockchip - use read_poll_timeout") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9486a6bcc90de8f8df03af8570d34c84425ae14b Author: Myeonghun Pak Date: Tue Jun 23 17:42:23 2026 +0900 hwrng: omap - Fix probe error path cleanup [ Upstream commit f8c24e6899e263073fbbeb07fadc1af85ec492f5 ] omap_rng_probe() enables runtime PM before acquiring and enabling the functional clocks. Several later error paths returned or unwound without undoing all state acquired so far. If pm_runtime_resume_and_get() failed, the driver returned through the generic ioremap error label and left runtime PM enabled. If either clock lookup returned -EPROBE_DEFER, the function returned directly and skipped the runtime PM cleanup; the register clock defer path could also leave the already enabled functional clock prepared. Route these failures through the existing unwind labels so each path only undoes resources that were acquired successfully. Keep the resume failure path limited to pm_runtime_disable(), and use the later labels only after the runtime PM usage count or clocks have been acquired. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed") Fixes: 43ec540e6f9b ("hwrng: omap - move clock related code to omap_rng_probe()") Fixes: b166be004491 ("hwrng: omap - Fix clock resource by adding a register clock") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bdc3b37a935f28c3e9eb2f6e889b4644d859fb08 Author: Pengpeng Hou Date: Tue Jun 23 14:07:27 2026 +0800 hwrng: xilinx-trng - propagate timeout before any data is read [ Upstream commit ba088974419326daf46c5dc03e2cf6ab6ab701f7 ] xtrng_readblock32() polls for 16-byte chunks but returns the number of bytes read even when the first poll times out. Its caller then treats a zero return as a short successful read, and partial reads for full 32-byte blocks can make the tail copy use a fixed block offset rather than the amount already produced. Return the poll error when no data has been read, preserve partial positive returns after some data is available, stop the generator on all collection exits, and append tail bytes at the current output count. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b68b35ed97d3e18edb9dea500d88420a95006742 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 94abda77b57a35b82bba0365bad072d94d67ffe9 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 add28e9988902d29ea93f4869280b4a16a049ea5 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 92e4979e1a770860b26aa3d90cce0c4c6a53833c Author: Giovanni Cabiddu Date: Mon Jun 8 16:04:20 2026 +0100 crypto: qat - clear AES key schedule from stack [ Upstream commit d41a9fcfb7f9ee36e4a4aaf5e7996bca6be1e7a9 ] qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy. Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1a106c6e17525827ee6d8091bb8c06fafbc21fed Author: Giovanni Cabiddu Date: Mon Jun 8 15:59:40 2026 +0100 crypto: qat - cancel work on re-enable SR-IOV timeout [ Upstream commit 455b0f3ac9e254edab9f5a873d337abe5e6e3604 ] The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds. Fixes: 4469f9b23468 ("crypto: qat - re-enable sriov after pf reset") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bee8d1fcdc8f389b595b0a4cf6fe8440f499458a Author: Manos Pitsidianakis Date: Fri Jun 5 14:23:51 2026 +0300 hwrng: core - fix rng list on registration error [ Upstream commit 3a5834db2b1ce25649f330e78efe1ccde78967fd ] hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step. Fixes: 2bbb6983887f ("hwrng: use rng source with best quality") Signed-off-by: Manos Pitsidianakis Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 15732636ac1233a1f1d35a96f6381a10385a19fe Author: Sandipan Das Date: Tue Jun 23 10:58:32 2026 +0530 perf vendor events amd: Update Zen 6 core events [ Upstream commit 6744430f106b0e46d6318d44a99cb27b0ee937ae ] Update definitions for the following events. * PMCx00A - Fix descriptions * PMCx00C - Add missing unit masks * PMCx00D - Add missing unit masks and fix descriptions * PMCx013 - Fix incorrect unit masks Fixes: 2f42fb0661d9 ("perf vendor events amd: Add Zen 6 core events") Signed-off-by: Sandipan Das Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e9d249a2318456904541285e3248acd210468b1e Author: Sandipan Das Date: Tue Jun 23 10:58:31 2026 +0530 perf vendor events amd: Update Zen 5 core events [ Upstream commit 047979af3bf6a118066c81099162d518de63abb1 ] Update definitions for the following events. * PMCx00A - Add missing unit masks * PMCx00B - Add missing unit masks and fix descriptions * PMCx00C - Add missing unit masks * PMCx00D - Add missing unit masks * PMCx025 - Add missing unit masks and fix descriptions Fixes: 45c072f2537a ("perf vendor events amd: Add Zen 5 core events") Signed-off-by: Sandipan Das Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6959e254f522c2f3feffb76a7bff3d6175caae44 Author: Ondrej Mosnáček Date: Wed Jul 1 08:23:21 2026 +0200 perf test amd ibs: avoid using executable heap [ Upstream commit e34006e7435fdd2c8d15e89d2137a4bf22c16401 ] Making [parts of] the heap executable is dangerous and is blocked by SELinux on Fedora/RHEL even for an unconfined user. Replace the malloc() + mprotect() combo with just mmap(), creating a private anonymous rwx mapping, which only requires the more commonly allowed "execmem" permission under SELinux (things like JIT or regex compilation need it as well). mmap() with MAP_ANONYMOUS will give us a zeroed mapping that begins on a page boundary, so the result is equivalent to the original code even without a memset() or the page-alignment dance. Verified that the test still passes on a machine with an AMD CPU that has the "ibs" CPU flag. Fixes: 35db59fa8ea2 ("perf test amd ibs: Add sample period unit test") Signed-off-by: Ondrej Mosnacek Reviewed-by: Ravi Bangoria Acked-by: Peter Zijlstra (Intel) Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1b3d6fef10e6983388ec16f21bf6bc3326cff9bc Author: Sandipan Das Date: Wed Jul 1 11:12:00 2026 +0530 perf/x86/amd/uncore: Add group validation [ Upstream commit edda9051e267b7390c7ce24b1b71434414ad156e ] The amd_uncore driver currently does not validate event groups and allows creation of groups with more events than the number of available hardware counters. Because of this, pmu->event_init() succeeds but counter assignment fails later in pmu->add() which returns -EBUSY once all counters are exhausted. Address this by introducing group validation in the pmu->event_init() path. Since the uncore PMUs have no per-event constraints and all counters of a PMU are interchangeable, validation is reduced to just counting the group members that target a PMU and ensuring that they fit within the available set of counters. Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/750877d66e208603c3047f13eed6399625d43969.1782884387.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit 945e335da3402d5c03fd467c1d3a38c0ee52bbe6 Author: Jiri Olsa Date: Fri Jul 3 13:49:11 2026 +0200 libbpf: Detect uprobe syscall with new error [ Upstream commit 8cae54c586084c81ab80f6ab020192eb2ce7aa0b ] In the previous optimized uprobe fix we changed the syscall error used for its detection from ENXIO to EPROTO. Changing related probe_uprobe_syscall detection check. Fixes: 05738da0efa1 ("libbpf: Add uprobe syscall feature detection") Fixes: 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Acked-by: Andrii Nakryiko Link: https://patch.msgid.link/20260703114917.238144-8-jolsa@kernel.org Signed-off-by: Sasha Levin commit 7273ac5e72408f6ae82cc5ac1282a3ace7722d8d Author: Jiri Olsa Date: Fri Jul 3 13:49:10 2026 +0200 libbpf: Change has_nop_combo to work on top of nop10 [ Upstream commit ee2862439e5c8763cee84e910706fdc5b97bc879 ] We now expect nop combo with 10 bytes nop instead of 5 bytes nop, fixing has_nop_combo to reflect that. Fixes: 41a5c7df4466 ("libbpf: Add support to detect nop,nop5 instructions combo for usdt probe") Fixes: 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Jakub Sitnicki Acked-by: Andrii Nakryiko Link: https://patch.msgid.link/20260703114917.238144-7-jolsa@kernel.org Signed-off-by: Sasha Levin commit 16776fb9c55de3748260ad02b4054e9df7ce5895 Author: Leo Yan Date: Thu Jul 2 20:51:37 2026 +0100 perf cs-etm: Filter synthesized branch samples [ Upstream commit a9e99b860fb6dfdc9a17d7c63b84fd5647f1f44c ] The itrace 'c' and 'r' options request synthesized branch events for calls and returns only. For perf script the default itrace options are "--itrace=ce", so CS ETM should emit call branches and error events by default. CS ETM currently synthesizes a branch sample for every decoded taken branch whenever branch synthesis is enabled. This produces redundant jump and conditional branch samples. Add a branch filter derived from the itrace calls and returns options. When neither option is set, keep the existing behavior and synthesize all branch samples. When calls or returns are requested, emit only branch samples whose flags match the selected branch type, while preserving trace begin/end markers. Also update test_arm_coresight_disasm.sh and arm-cs-trace-disasm.py to use the --itrace=b option for generating branch samples. Before: perf script -F,+flags callchain_test 6114 [005] 331519.825214: 1 branches: tr strt jmp 0 [unknown] ([unknown]) => ffff8000803a3a68 perf_report_aux_output_id+0x50 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000803a3a74 perf_report_aux_output_id+0x5c ([kernel.kallsyms]) => ffff8000817f4d88 memset+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jmp ffff8000817f4d8c memset+0x4 ([kernel.kallsyms]) => ffff8000817f4c00 __pi_memset_generic+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4c1c __pi_memset_generic+0x1c ([kernel.kallsyms]) => ffff8000817f4c44 __pi_memset_generic+0x44 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4c4c __pi_memset_generic+0x4c ([kernel.kallsyms]) => ffff8000817f4c5c __pi_memset_generic+0x5c ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4c5c __pi_memset_generic+0x5c ([kernel.kallsyms]) => ffff8000817f4cf0 __pi_memset_generic+0xf0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4d30 __pi_memset_generic+0x130 ([kernel.kallsyms]) => ffff8000817f4d68 __pi_memset_generic+0x168 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4d78 __pi_memset_generic+0x178 ([kernel.kallsyms]) => ffff8000817f4d6c __pi_memset_generic+0x16c ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4d78 __pi_memset_generic+0x178 ([kernel.kallsyms]) => ffff8000817f4d6c __pi_memset_generic+0x16c ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000817f4d78 __pi_memset_generic+0x178 ([kernel.kallsyms]) => ffff8000817f4d6c __pi_memset_generic+0x16c ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: return ffff8000817f4d84 __pi_memset_generic+0x184 ([kernel.kallsyms]) => ffff8000803a3a78 perf_report_aux_output_id+0x60 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: jcc ffff8000803a3a98 perf_report_aux_output_id+0x80 ([kernel.kallsyms]) => ffff8000803a3b04 perf_report_aux_output_id+0xec ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000803a3b1c perf_report_aux_output_id+0x104 ([kernel.kallsyms]) => ffff8000803a38f8 __perf_event_header__init_id+0x0 ([kernel.kallsyms]) After: callchain_test 6114 [005] 331519.825214: 1 branches: tr strt jmp 0 [unknown] ([unknown]) => ffff8000803a3a68 perf_report_aux_output_id+0x50 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000803a3a74 perf_report_aux_output_id+0x5c ([kernel.kallsyms]) => ffff8000817f4d88 memset+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000803a3b1c perf_report_aux_output_id+0x104 ([kernel.kallsyms]) => ffff8000803a38f8 __perf_event_header__init_id+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000803a39c0 __perf_event_header__init_id+0xc8 ([kernel.kallsyms]) => ffff800080105258 __task_pid_nr_ns+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff80008010528c __task_pid_nr_ns+0x34 ([kernel.kallsyms]) => ffff8000801d5610 __rcu_read_lock+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000801052b0 __task_pid_nr_ns+0x58 ([kernel.kallsyms]) => ffff800080192078 lock_acquire+0x0 ([kernel.kallsyms]) callchain_test 6114 [005] 331519.825214: 1 branches: call ffff8000801923f4 lock_acquire+0x37c ([kernel.kallsyms]) => ffff8000801d6da0 rcu_is_watching+0x0 ([kernel.kallsyms]) Fixes: b12235b113cf ("perf tools: Add mechanic to synthesise CoreSight trace packets") Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 54080d72abb3cde6a25b4c1614ff9f65e3900a20 Author: Leo Yan Date: Thu Jul 2 20:51:36 2026 +0100 perf cs-etm: Fix thread leaks on trace queue init failure [ Upstream commit 50cd0d54f1f6dd9b3de7c0ad101bd41d06206ace ] cs_etm__init_traceid_queue() allocates the frontend and decode threads, if a later allocation fails, the error path does not drop thread reference that was already acquired. Release both thread pointers with thread__zput() on the error path, so does not leak thread references or leave stale pointers behind. Fixes: 951ccccdc715 ("perf cs-etm: Only track threads instead of PID and TIDs") Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 56e2ff5c9be15ae0b144819ee1527cc7f3d1642a Author: Thomas Weißschuh Date: Fri Jul 3 19:30:16 2026 +0200 tools/nolibc: mark arg1 operand in __nolibc_syscall0() as write-only [ Upstream commit a3b2181459a2c74c03ddbad585f884eefc8ff8ff ] __nolibc_syscall0() does not set the arg1 variable before passing it to the asm block. This uninitialized variable read is undefined behavior. Clang can miscompile this. Mark the asm operand as write-only to fix this. Fixes: 8e1930296f92 ("tools/nolibc: Add support for SPARC") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260703-nolibc-sparc-asm-v1-1-c7fe73e2e777@weissschuh.net Signed-off-by: Sasha Levin commit 08af0f96120a2acfba90752787de6b6999e83fdd Author: Xuanqiang Luo Date: Fri Jul 3 11:13:45 2026 +0800 fanotify: initialize permission event watchdog state [ Upstream commit a3aa899823dda059ab88a58254f9a605e03ec275 ] fanotify permission events are allocated with kmem_cache_alloc(), but fanotify_alloc_perm_event() does not initialize watchdog_cnt. The watchdog reads watchdog_cnt after the event is moved to access_list. A stale value can make it warn too early or skip the warning. Initialize watchdog_cnt when allocating a permission event. Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events") Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260703031345.9354-1-xuanqiang.luo@linux.dev Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 1b3fecd09910040668b752f3377d7218ca5c59ac Author: Jiri Olsa Date: Fri Jul 3 13:49:09 2026 +0200 uprobes/x86: Move optimized uprobe from nop5 to nop10 [ Upstream commit 554ba38456dad8053a1a80afe6ae6da9eff745cc ] Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not executable entry points while byte 0 is trapped. 3) Publish the first LEA byte: [48] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this is: lea -0x80(%rsp), %rsp call Unoptimize path (int3_update_unoptimize): 1) Initial optimized state: 48 8d 64 24 80 e8 d0 d1 d2 d3 Same as 3) above. 2) Trap new entries before restoring the NOP bytes: [cc] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this traps. A thread that had already executed the LEA can still reach the intact CALL at offset 5. 3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped and byte 5 as CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3 From offset 0 this still traps. Offset 5 is still the CALL for any thread that was already past the first LEA byte. 4) Publish the first byte of the original NOP: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3 From offset 0 this is the restored 10-byte NOP; the CALL opcode and displacement are now only NOP operands. Offset 5 still decodes as CALL for a thread that was already there. Tthere is only a single target uprobe-trampoline for the given nop10 instruction address, so the CALL instruction will not be changed across unoptimization/optimization cycles. Therefore, any task that is preempted at the CALL instruction is guaranteed to observe that CALL and not anything else. Note as explained in [2] we need to use following nop10: PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1) which means we need to allow 0x2e prefix which maps to INAT_PFX_CS attribute in is_prefix_bad function. Also changing the uprobe syscall error when called out of uprobe trampoline to -EPROTO, so we are able to detect the fixed kernel. The optimized uprobe performance stays the same: uprobe-nop : 3.129 ± 0.013M/s uprobe-push : 3.045 ± 0.006M/s uprobe-ret : 1.095 ± 0.004M/s --> uprobe-nop10 : 7.170 ± 0.020M/s uretprobe-nop : 2.143 ± 0.021M/s uretprobe-push : 2.090 ± 0.000M/s uretprobe-ret : 0.942 ± 0.000M/s --> uretprobe-nop10: 3.381 ± 0.003M/s usdt-nop : 3.245 ± 0.004M/s --> usdt-nop10 : 7.256 ± 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t Closes: https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") Reported-by: Andrii Nakryiko Assisted-by: Codex:GPT-5.5 Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Link: https://patch.msgid.link/20260703114917.238144-6-jolsa@kernel.org Signed-off-by: Sasha Levin commit 310a504467a1812cc0a13837db826f5dc774f938 Author: Jiri Olsa Date: Fri Jul 3 13:49:08 2026 +0200 uprobes/x86: Allow to copy uprobe trampolines on fork [ Upstream commit d9a48e77f6fe0c11d3cdfcbbcbf4a98ec402e55a ] When we do fork or clone without CLONE_VM the new process won't have uprobe trampoline vma objects and at the same time it will have optimized code calling that trampoline and crash. Fixing this by allowing vma uprobe trampoline objects to be copied on fork to the new process. Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Link: https://patch.msgid.link/20260703114917.238144-5-jolsa@kernel.org Signed-off-by: Sasha Levin commit 88a3464c421f1a52e619687f94ce05be4c805498 Author: Jiri Olsa Date: Fri Jul 3 13:49:07 2026 +0200 uprobes/x86: Do not leak trampoline vma mapping on optimization failure [ Upstream commit 07c308eb2bcfe4727ba669e1ba6f5b0ba7d2696e ] In case the optimization fails, we leak new-ly created trampoline vma mapping (in case we just created it), let's unmap it. Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Link: https://patch.msgid.link/20260703114917.238144-4-jolsa@kernel.org Signed-off-by: Sasha Levin commit 1ca1ca70e90a9badfb9e1c9da2177c4914eb85d0 Author: Jiri Olsa Date: Fri Jul 3 13:49:06 2026 +0200 uprobes/x86: Remove struct uprobe_trampoline object [ Upstream commit 38af0dd6a266057002eacb170c08298ea912fb0a ] Removing struct uprobe_trampoline object and it's tracking code, because it's not needed. We can do same thing directly on top of struct vm_area_struct objects. This makes the code simpler and allows easy propagation of the trampoline vma object into child process in following change. Note the original code called destroy_uprobe_trampoline if the optimiation failed, but it only freed the struct uprobe_trampoline object, not the vma. The new vma leak is fixed in following change. Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Acked-by: Andrii Nakryiko Link: https://patch.msgid.link/20260703114917.238144-3-jolsa@kernel.org Stable-dep-of: 07c308eb2bcf ("uprobes/x86: Do not leak trampoline vma mapping on optimization failure") Signed-off-by: Sasha Levin commit f132fc01b359a0f7d81fe13d769ea4e7c4baa66e Author: Pengpeng Hou Date: Tue Jun 30 15:28:27 2026 +0800 wifi: rtw89: fix HE extended capability length check [ Upstream commit 2aba608a86e9b099c9af2ea70b620552dee2b628 ] rtw89_mac_check_he_obss_narrow_bw_ru_iter() reads extended capability byte 10, but rejects only datalen values below 10. Byte 10 requires at least 11 bytes. Require datalen >= 11 before reading data[10]. Fixes: 8d540f9d2916 ("wifi: rtw89: disable 26-tone RU HE TB PPDU transmissions") Signed-off-by: Pengpeng Hou Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/2026063009025530.2-ccfa108-0024-wifi-rtw89-fix-HE-extended--pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit 942becee7e788afb2f555984fbdd473258031066 Author: Dmitry Morgun Date: Mon Jun 29 09:44:52 2026 +0000 wifi: rtw89: check return values in rtw89_ops_start_ap() [ Upstream commit a8cddb62c573f28eef5f887a8f3156e8ee22776a ] Several functions called in rtw89_ops_start_ap() may fail to allocate skb or fail to send H2C command to firmware, returning -ENOMEM or an error code. Their return values are ignored, so subsequent commands are executed with incorrect state. Check the return values and propagate errors. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a52e4f2ce0f5 ("rtw89: implement ieee80211_ops::start_ap and stop_ap") Signed-off-by: Dmitry Morgun Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260629094452.8709-1-d.morgun@ispras.ru Signed-off-by: Sasha Levin commit 80ea28c94cf18563ca230ecee8cf6fad3c5c1a2a Author: Zong-Zhe Yang Date: Thu Jun 25 14:15:42 2026 +0800 wifi: rtw89: fw: fix link ID filling for LPS MLO common info [ Upstream commit c1eabaaa088ddbb1b937cd339adfa4c18e93c93d ] The link ID field in H2C command of LPS MLO common info is incorrectly filled with the PHY index. Fix it with the target link ID. Fixes: 20380a039ddd ("wifi: rtw89: phy: add H2C command to send detail RX gain and link parameters for PS mode") Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260625061545.44808-8-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6268f46d83875d294d75b68b97a5b79953744598 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 582b5e5362455b57abc8a241955f8745f71639f3 Author: Wentao Guan Date: Thu Jun 11 16:20:21 2026 +0800 wifi: rtw89: fw: correct preload field of w2 in rtw89_fw_h2c_default_cmac_tbl_be() [ Upstream commit e13cd023a4cdbbb9e58ab91e857b5e45ea753f19 ] BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1. These will cause h2c->w1 wrong overlap by w2 and w2 not initialized. Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D") Signed-off-by: Wentao Guan Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260611082021.46650-1-guanwentao@uniontech.com Signed-off-by: Sasha Levin commit 876b110114da39cfcf07cd35e2e6213ef6982e4b Author: Dan Carpenter Date: Mon Jun 8 15:34:46 2026 +0300 wifi: rtw89: debug: fix off by on in rtw89_ppdu_str() [ Upstream commit 1908534deb53a018580309be84a4f7dcc9cb1af3 ] This > comparison should be >= to avoid an out of bounds access. Fixes: 419ed7f4a053 ("wifi: rtw89: debug: extend bb_info with TX status and PER") Signed-off-by: Dan Carpenter Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/aia25i0ds3B6QF6c@stanley.mountain Signed-off-by: Sasha Levin commit e984c63bd3359b1186fb6ee664dbeeb40512dffc 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 343aa5275484d627c921a42e8e115cae366be5de 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 feb0901bbcaf9b2f71c6adbb3e8b3aaf9212c055 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 c1900758c3a8bbff6ebb3fbbb630cdaf1a127c09 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 8b5654d317277e6e505c23f8fa7e415237fefc7f Author: Alex Bereza Date: Thu Apr 2 09:46:22 2026 +0200 dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout [ Upstream commit aa99c4d1d63bbc26a5fc4c667d89b2595743c19d ] Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value. Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's") Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") Reviewed-by: Suraj Gupta Reviewed-by: Frank Li Signed-off-by: Alex Bereza Link: https://patch.msgid.link/20260402-fix-atomic-poll-timeout-regression-v4-1-f30d6a6c13cb@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 54c9b3315adacc9fbca7284f6a133dca585c6ea4 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 aec7cf9a5bd89047c58d5648bfce0b1bd19ba7d5 Author: Golla Nagendra Date: Tue Jun 30 12:18:43 2026 +0530 dmaengine: zynqmp_dma: fix race between runtime PM and device removal [ Upstream commit 516ba2d8b7aac4238f9fcbd58579c43c71b9b695 ] In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions. Fixes: 72dd8b2914b5 ("dmaengine: zynqmp_dma: Add shutdown operation support") Co-developed-by: Prasanna Kumar T S M Signed-off-by: Prasanna Kumar T S M Signed-off-by: Golla Nagendra Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260630064844.705173-2-nagendra.golla@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c3e943490ced0b9ad475844eda7661f6a9bcfb4a 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 8896852b6fcd3483b08dcd67646f3e051b5f7154 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 7d83720d0741d85786a8464634787b038d8078db Author: Christophe JAILLET Date: Sat Jun 20 17:53:22 2026 +0200 leds: lp5860-spi: Fix an error handling path [ Upstream commit f647a2266289a35eaa4865f629f2ab7046900d9b ] If lp5860_device_init() fails, a missing mutex_destroy() should be called. Use devm_mutex_init() instead of mutex_init() to fix it. This also simplifies the remove function. Fixes: f0a66563aa2d ("leds: Add support for TI LP5860 LED driver chip") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/311792e767ab803d4744bc26155e6dac253d9b45.1781970783.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 989f3d01fc1961d0850b343e0b4e3973c082d82e Author: Christophe JAILLET Date: Sat Jun 20 17:51:53 2026 +0200 leds: lp5860: Fix a potential double-unlock [ Upstream commit 10a5a70c02277a1c12999b669a1bd1922558338a ] In lp5860_device_init(), if lp5860_init_dt() fails, an already unlocked mutex is unlocked another time. Slightly rework how the lock is taken/released to avoid this potential double unlock. Fixes: f0a66563aa2d ("leds: Add support for TI LP5860 LED driver chip") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/0f4d556e0532bfa881d7d83c1e244572117a89e3.1781970674.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1017fe1c7f48e511c5a680e3057005daaff2f3a2 Author: Gregory Price Date: Wed Jul 1 18:16:13 2026 -0400 mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug [ Upstream commit 2ebce860bdd7ae5e13002811bc9bbbf33fcfc221 ] We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price Acked-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260701221613.2818148-1-gourry@gourry.net Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 915c2d9d69fc6c5f9f41d12bf4a9c51293aaee62 Author: Sechang Lim Date: Wed Jul 1 08:07:51 2026 +0000 bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks [ Upstream commit 2ce3f548cfc6a1fe4c53479cf8a21931cdfd51d8 ] __bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there. Fixes: 1b67772e4e3f ("bpf,lsm: Refactor bpf_prog_alloc/bpf_prog_free LSM hooks") Signed-off-by: Sechang Lim Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260701080757.1394144-1-rhkrqnwk98@gmail.com Signed-off-by: Sasha Levin commit 1d39861b9c41a157ea7f96a07afd1f8b50bf9fe9 Author: Guillaume Maudoux Date: Tue Jun 30 11:57:23 2026 +0200 selftests/bpf: Mask socket type flags in mptcpify prog [ Upstream commit b4b8b334f6b535a86ab83f18d3d241fe01270bc3 ] The mptcpify BPF prog upgrades eligible TCP sockets to MPTCP, but only when the socket type is exactly SOCK_STREAM. Its update_socket_protocol() hook runs on the raw type from userspace, before the socket core masks it with SOCK_TYPE_MASK, so the type may still carry SOCK_CLOEXEC or SOCK_NONBLOCK in its upper bits and the equality check fails. As a result, a socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) -- what common libraries do by default -- is silently left as plain TCP. This was hit in practice with curl. Since mptcpify.c is referenced as example code for enabling MPTCP transparently, the same mistake is likely to be copied into real deployments where it fails the same way and is hard to diagnose. Mask the type before comparing, mirroring the socket core. Extend the test to also create the server with SOCK_CLOEXEC set; the same masking is applied to start_server_addr() so a flagged type still listens. Fixes: ddba122428a7 ("selftests/bpf: Add mptcpify test") Signed-off-by: Guillaume Maudoux Signed-off-by: Andrii Nakryiko Reviewed-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/bpf/20260630095723.564392-1-layus.on@gmail.com Signed-off-by: Sasha Levin commit ff3f22ed8d2f350b4c24ee26e33daea5f08d58ef Author: Leon Hwang Date: Wed Jun 24 23:51:14 2026 +0800 bpf: Copy per-CPU map value padding in copy_map_value_long() [ Upstream commit 7cf9cd98cf6f0df3befc167ca6b54c07014d71de ] In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path. Fixes: 448325199f57 ("bpf: Add copy_map_value_long to copy to remote percpu memory") Signed-off-by: Leon Hwang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260624155115.85196-2-leon.hwang@linux.dev Signed-off-by: Sasha Levin commit 03b44839ce81d8f2ca54e426ecab88e84b3c8e75 Author: Yichong Chen Date: Wed Jun 24 10:50:55 2026 +0800 tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commands [ Upstream commit f7f540e19751face50c68bb9ce58460fcb46c293 ] struct_ops frees the global btf_vmlinux object. In batch mode, a later struct_ops command can reuse stale state. Reset the BTF pointer and cached map info state. Fixes: 65c93628599d ("bpftool: Add struct_ops support") Signed-off-by: Yichong Chen Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/9F9017160ABE125F+20260624025055.1574875-3-chenyichong@uniontech.com Signed-off-by: Sasha Levin commit f6fd865651ccfbfeae6d604680b48e52fea61aef Author: Yichong Chen Date: Wed Jun 24 10:50:54 2026 +0800 tools/bpf/bpftool: Reset vmlinux BTF after map commands [ Upstream commit 66d7e39e49b0dd57610c9b63afc65b4d5690983b ] get_map_kv_btf() caches the vmlinux BTF object when a map uses btf_vmlinux_value_type_id. map dump released that object when the command completed, but left the global pointer stale. The same cached object can also be returned to print_key_value(), which freed it directly. That leaves btf_vmlinux dangling before the command cleanup path runs. Use free_map_kv_btf() for per-entry cleanup, and reset the cached btf_vmlinux pointer when the map command releases the object. This keeps batch mode from reusing a freed BTF object. Fixes: 4e1ea33292ff ("bpftool: Support dumping a map with btf_vmlinux_value_type_id") Signed-off-by: Yichong Chen Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/9072F43B3F74DF91+20260624025055.1574875-2-chenyichong@uniontech.com Signed-off-by: Sasha Levin commit 8d52adf7c923b331316addc5d53be152a469dccd Author: Andrii Nakryiko Date: Tue Jun 30 13:54:18 2026 -0700 bpftool: Strip all -Wformat* flags from bootstrap libbpf build [ Upstream commit a954c9e3168cdf0c3cad07b43dfc8ca2945d773a ] Commit 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") started building the bootstrap libbpf with HOST_CFLAGS, stripping the warning options that are unsuitable for that build by filtering out -W -Wall -Wextra -Wformat -Wformat-signedness. HOST_CFLAGS inherits EXTRA_WARNINGS, which includes -Wformat-security and -Wformat-y2k. The filter drops -Wall and -Wformat (the latter being what actually enables -Wformat), but leaves those two -Wformat-* children in LIBBPF_BOOTSTRAP_CFLAGS. Building the bootstrap libbpf with it then warns: cc1: warning: '-Wformat-y2k' ignored without '-Wformat' cc1: warning: '-Wformat-security' ignored without '-Wformat' The warning is easy to miss in an in-tree build: tools/lib/bpf/Makefile re-adds -Wall via "override CFLAGS += -Wall", which re-enables -Wformat for the libbpf objects, so only libbpf's feature-detection probe (which uses the passed CFLAGS verbatim) leaks the two warnings. The standalone libbpf Makefile (github.com/libbpf/libbpf, used by the bpftool mirror) instead uses "CFLAGS ?= ... -Wall", which the passed-in CFLAGS overrides, so -Wall is never re-added and every bootstrap object warns. Use a -Wformat% wildcard in the filter-out so the orphaned children are removed together with the parent. Fixes: 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260630205418.3483969-1-andrii@kernel.org Signed-off-by: Sasha Levin commit 32bd68edbc6cbcfac0e4033b64f0bcadbf0efef5 Author: Evgenii Burenchev Date: Mon Jun 29 15:58:56 2026 -0500 drm/amd/display: Fix dangling pointer in CRTC reset function [ Upstream commit 0aeed866cb938943908c3ba46422128e49d2d080 ] amdgpu_dm_crtc_reset_state() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state") Signed-off-by: Evgenii Burenchev Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260629090435.9729-4-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 80c0f51aced43d6eaf72f95a2833b0a77cf7880d Author: Evgenii Burenchev Date: Mon Jun 29 15:58:50 2026 -0500 drm/amd/display: Fix dangling pointer in plane reset function [ Upstream commit 98cad4bd1443975d972f4c7f705980da03722a22 ] amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes") Signed-off-by: Evgenii Burenchev Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260629090435.9729-3-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4bd683d1a7d33d27274e561c989bf125d728e6a8 Author: bui duc phuc Date: Wed Jul 1 11:13:10 2026 +0700 ASoC: ti: j721e-evm: Avoid mixing goto with guard() [ Upstream commit 47a0dde9a3bdd01359ce3a5f0b59a9de33b73dce ] The previous guard(mutex) conversion mixed cleanup helpers with goto-based error handling, which is discouraged by the cleanup.h guidelines. Restore mutex_lock()/mutex_unlock() instead. Fixes: 6f4cf77320ae ("ASoC: ti: j721e-evm: Use guard() for mutex locks") Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260701041310.230725-3-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit daaac025b15882e75cf665a9767af9957e68e27c Author: bui duc phuc Date: Wed Jul 1 11:13:09 2026 +0700 ASoC: samsung: i2s: Avoid mixing goto with guard() [ Upstream commit 02fd694e60a7e2c581c7836f6781c01b9b419c8a ] cleanup.h recommends not mixing goto-based error handling with cleanup helpers in the same function. Remove the goto path and rely on guard(pm_runtime) for automatic cleanup instead. Fixes: 3d08517b5c67 ("ASoC: samsung: i2s: Use guard() for spin locks") Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260701041310.230725-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 06aef6dcc1d52da5112cbcde39c062e493247ab5 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 1664327ce797e09e387dc10cbbaa5b8d76558d2c 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 83c680de6d41d627c077dedb24f89d9e5be0e2a2 Author: Asad Kamal Date: Tue Jun 23 00:25:04 2026 +0800 drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read [ Upstream commit 5d3cc8e388464f485d0944b87b8f9426e637d082 ] Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table. Fixes: c82baa281843 ("drm/amd/powerplay: add Tonga dpm support (v3)") Fixes: 0d2c7569e196 ("drm/amdgpu: add new atomfirmware based helpers for powerplay") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fceac25487b21d6db940d2aed368e465d89cd1f4 Author: Uday Khare Date: Thu Jun 18 18:53:27 2026 +0530 regulator: tps6594: Fix device node reference leaks in multiphase loop [ Upstream commit 7fd28093b3effc4f92566466df364622830ec608 ] In tps6594_regulator_probe(), the multi-phase configuration loop calls of_find_node_by_name() to find buck nodes by name, and of_get_parent() twice to navigate to the PMIC parent node. None of the acquired node references (np, intermediate parent, np_pmic_parent) are ever released via of_node_put(), causing a reference leak on every loop iteration. Additionally, of_find_node_by_name() can return NULL, but the result was immediately passed to of_node_full_name() and of_get_parent() without a NULL check, which could lead to a NULL pointer dereference. Fix this by: - Adding a NULL check for np after of_find_node_by_name() - Storing the intermediate parent node in a local variable np_parent - Calling of_node_put() on np, np_parent and np_pmic_parent at the end of each loop iteration Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260618132327.11529-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f88c65473f525454f642d7b638c736f2dc6abbee Author: Arnd Bergmann Date: Thu Jun 18 16:36:08 2026 +0200 PCI: imx6: Fix building against PCI_PWRCTRL_GENERIC [ Upstream commit 7f4d9901eb1fdd3d2e56b514dcc325b33185b8e1 ] When endpoint mode is built-in, but pwrctrl support is in a loadable module, the imx driver fails to build because the unused host support still tries to link against pwrctrl: ld.lld: error: undefined symbol: pci_pwrctrl_power_off_devices >>> referenced by pci-imx6.c:1988 (drivers/pci/controller/dwc/pci-imx6.c:1988) >>> drivers/pci/controller/dwc/pci-imx6.o:(imx_pcie_shutdown) in archive vmlinux.a Add one more select for this. Fixes: 85c1fcfa740d ("PCI: imx6: Integrate new pwrctrl API") Signed-off-by: Arnd Bergmann Signed-off-by: Manivannan Sadhasivam Reviewed-by: Sherry Sun Link: https://patch.msgid.link/20260618143629.2035247-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 6d0343961cebea56beafcd6b8ecf2cbfdadc0090 Author: Arnd Bergmann Date: Tue Jun 16 18:39:59 2026 +0200 PCI: imx6: Fix building against PCI_HOST_COMMON [ Upstream commit d4e0984f12ea958e0f2def90ddb1e193a896932b ] When CONFIG_PCI_HOST_COMMON is set to =m, the i.MX6 PCIe driver fails to link. This can happen when only i.MX endpoint mode is enabled but not host mode, which would indirectly enable the host-common driver itself. ld.lld: error: undefined symbol: pci_host_common_parse_ports >>> referenced by pci-imx6.c >>> drivers/pci/controller/dwc/pci-imx6.o:(imx_pcie_host_init) in archive vmlinux.a ld.lld: error: undefined symbol: pci_host_common_delete_ports >>> referenced by pci-imx6.c >>> drivers/pci/controller/dwc/pci-imx6.o:(imx_pcie_host_init) in archive vmlinux.a >>> referenced by pci-imx6.c >>> drivers/pci/controller/dwc/pci-imx6.o:(imx_pcie_host_init) in archive vmlinux.a Select the common module from the endpoint support directly. Fixes: 250eea5c06f5 ("PCI: imx6: Parse 'reset-gpios' in Root Port nodes") Signed-off-by: Arnd Bergmann Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20260616164049.3656435-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 385f7a0f62b2e66b1bf2e47c1e0a0ea6c4d625d3 Author: Ian Rogers Date: Mon Jun 22 18:27:54 2026 -0700 perf tests: Fix flakiness in branch stack sampling tests [ Upstream commit 344d3aec164dba83a5520f23a0d46e13e904a205 ] The branch stack sampling test (test 130) runs short iteration-based workloads to verify syscall, kernel, and trap branch stack sampling. Specifically, `test_syscall()` and `test_kernel_branches()` run `perf bench syscall basic` with loop counts of 8000 and 1000, and `test_trap_eret_branches()` runs `traploop` with 1000 iterations. Because these loop limits are extremely small, the total benchmark runtimes last only a few milliseconds (or less). Under high load, virtualization, or coarse sampling conditions, PMU cycle sampling fails to capture enough samples inside the brief benchmark loops. This leads to false negatives where the script output lacks the expected syscall, kernel, or trap branch entries (e.g. "ERROR: Branches missing getppid[^ ]*/SYSCALL/"). Fix this by increasing the workload loop counts to 100,000 across all three test sections. Running 100,000 loops still finishes virtually instantaneously (less than 0.1 seconds), but generates enough iterations to guarantee robust branch stack capture. Fixes: b55878c90ab9 ("perf test: Add test for branch stack sampling") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8c0a67e54ec32f809592ccb1a5a3fe49d7462a6e Author: Ian Rogers Date: Mon Jun 22 18:27:53 2026 -0700 perf tests: Fix flakiness in BPF counters test on hybrid systems [ Upstream commit b02027776ac5bf737f1b76f3759f405e376097e5 ] The `perf stat --bpf-counters test` fails intermittently on hybrid architectures or systems with dynamic frequency scaling (DVFS). This happens because the test workload (`sqrtloop`) runs for a fixed 1-second duration, and the CPU frequency can scale dynamically between idle and maximum frequency. As the first run runs on a cold CPU and the second run runs on a warmed-up CPU (or vice versa), the number of instructions executed in 1 second differs by up to 2.2x, violating the comparison tolerance. Also, when running as root, BPF tracepoints and scheduling programs trigger frequently. Since standard `perf stat -e instructions` measures both user and kernel space instructions, it counts BPF helper and program execution overheads, whereas the BPF counters themselves do not self- measure. This introduces a large kernel-space instruction count discrepancy between standard and BPF counters. Fix these issues by: 1. Switching the workload to a strictly deterministic, iteration-based workload: `awk 'BEGIN { for (i=0; i<10000000; i++) sum+=i }'`. We pin the workload to a single random allowed CPU using `taskset -c $CPU` via a bash array. 2. Restricting the counted event to user-space only (`instructions:u` or `/u`). 3. Tightening the comparison tolerance from 20% to 15%. These modifications isolate the measurements to user-space instructions of the deterministic loop, which executes a virtually identical number of instructions on both runs (with less than 0.001% variation), eliminating Dynamic Frequency Scaling (DVFS), kernel scheduling noise, and BPF helper self-measurement overheads. Fixes: 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat --bpf-counters' new option") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 16d72de0201e8a5dd58c37346ae91cfa201454e3 Author: Ian Rogers Date: Mon Jun 22 18:27:52 2026 -0700 perf tests: Fix flakiness in trace record and replay test [ Upstream commit 509a2b9a6e142697dd5f34cdd802e5b86eababa1 ] The `perf trace record and replay` test fails intermittently on slow or virtualized hosts because the default recording workload (`sleep 1`) occasionally completes without scheduling the target `nanosleep` or `clock_nanosleep` system calls inside the recorded sample window, resulting in the error: `Failed: cannot find *nanosleep syscall`. Generalize the `perf_record_with_retry` helper in `tests/shell/lib/perf_record.sh` to support a custom record command prefix via the `PERF_RECORD_CMD` environment variable (defaulting to "perf record"). Update `trace_record_replay.sh` to use this robust retry loop running with `PERF_RECORD_CMD="perf trace record"` and a base workload of `sleep`. The test will automatically retry with scaled sleep durations (from 0.01s up to 2.0s) until the required `nanosleep` event is successfully captured. Fixes: 15bcfb96d0dd ("perf test: Add trace record and replay test") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit cf79e50a1d30d221037e51bbef11abc2e2d2dc69 Author: Ian Rogers Date: Mon Jun 22 18:27:49 2026 -0700 perf tests: Add robust record retry helper and use subsecond workloads [ Upstream commit 74dba58222f0d34cf8bd3eba1a6926e9654d4b6b ] Introduce `perf_record_with_retry` and `perf_record_cleanup` in a shared library `tests/shell/lib/perf_record.sh` to prevent record test failures caused by transient recording or workload delays. Update `record.sh`, `record_lbr.sh`, `pipe_test.sh`, `kvm.sh`, and `stat_all_pfm.sh` to use this robust record retry logic. These tests now start with very short durations (e.g. 0.01 seconds) and scale up if the initial recording failed to capture samples, significantly improving test execution speed on success while remaining resilient to slow systems. Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: 509a2b9a6e14 ("perf tests: Fix flakiness in trace record and replay test") Signed-off-by: Sasha Levin commit a69133af55da2a0cbdc0d48ab64d992c14bf67e1 Author: Ian Rogers Date: Mon Jun 22 18:27:51 2026 -0700 perf tests: Fix Python JIT dump profiling test failure [ Upstream commit 07eac17339dab6b143e12cadf19acd61f03011f8 ] The `python profiling with jitdump` test failed due to: 1. Target PID extraction resolving to duplicate space-separated values, which broke the buildid-cache loops. 2. The default workload duration being too short to capture JIT stack trampoline samples, resulting in 0 matching JIT symbols. Fix the PID parsing by sorting and retrieving a unique single-line value. Implement a robust retry loop starting at 1M python loop iterations and scaling up to 100M iterations until JIT symbols are successfully captured and verified. Fixes: c9cd0c7e529e ("perf test: Add python JIT dump test") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5aa6eb9129c469904c3e05826df216687a190ca4 Author: Ian Rogers Date: Mon Jun 22 18:27:50 2026 -0700 perf tests: Skip metrics validation if system-wide recording lacks permission [ Upstream commit 8953bfd8820b6525032023fda3a420098c1823ae ] The metrics value validation test requires system-wide recording (`-a`), which can fail on systems without root permissions or where paranoid levels restrict tracing. Add a check to skip the test if `-a` is not supported. Also fix false negatives during validation by updating parse error string patterns and resolving issues in metric list generation. Fixes: 3ad7092f5145 ("perf test: Add metric value validation test") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 63aa9756ce0b69ba3929106c3fe2dadc2e615a81 Author: Ian Rogers Date: Mon Jun 22 18:27:47 2026 -0700 perf test: Truncate test description to fit terminal width [ Upstream commit 32e6312f7e397bf0b731b43a6504966398af0788 ] The parallel test harness uses the carriage return delete escape sequence `PERF_COLOR_DELETE_LINE` ("\033[A\33[2K\r") to erase and update the "Running (X active)" progress lines. However, if a test description is longer than the terminal width, the line wraps around. When this happens, the cursor up escape sequence `\033[A` only moves the cursor to the last wrapped row, leaving the top half of the description printed on the previous line. This leads to name duplication and output corruption spilling over multiple rows on consoles narrower than the maximum description length (e.g., 101 columns wide). Fix this by dynamically querying the terminal width using `get_term_dimensions` and truncating the printed test descriptions using the `%-*.*s` printf format. We reserve 35 characters for prefix, status, and spacing metrics to guarantee the progress line never wraps. Fixes: 0e036dcad4e6 ("perf test: Display number of active running tests") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b0f59d0a779ebbaf4d74cad3b0d857fe4cd41062 Author: Ian Rogers Date: Mon Jun 22 18:27:46 2026 -0700 perf parse-events: Restrict core PMU bypass to --cputype option [ Upstream commit e6ad1fb3458f9e77f63bcd555baf7a08008ecc2e ] Commit b1c5efbfd92e ("perf parse-events: Remove hard coded legacy hardware and cache parsing") introduced a bypass to PMU filtering to prevent uncore PMUs from being filtered out during event parsing, which was required for resolving `duration_time` and `uncore_freq` when running with `--cputype`. However, this bypass was active whenever `pmu_filter` was set, which also incorrectly bypassed filtering for the `--pmu-filter` option. Introduce a `cputype_filter` boolean flag in `parse_events_state` and `parse_events_option_args` to distinguish filtering initiated by `--cputype` from that initiated by `--pmu-filter`. Restrict the core-only check in `parse_events__filter_pmu()` to when `cputype_filter` is true. Fixes: b1c5efbfd92e ("perf parse-events: Remove hard coded legacy hardware and cache parsing") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2097ae16533d3f80497cbb479093b3cd731018a2 Author: Ian Rogers Date: Mon Jun 15 18:15:29 2026 -0700 perf evlist: Add reference count checking [ Upstream commit ab24487aaa42e7ca18580f6b4336615156d49452 ] Now the evlist is reference counted, add reference count checking so that gets and puts are paired and easy to debug. Reference count checking is documented here: https://perfwiki.github.io/main/reference-count-checking/ This large patch is adding accessors to evlist functions and switching to their use. There was some minor renaming as evlist__mmap is now an accessor to the mmap variable, and the original evlist__mmap is renamed to evlist__do_mmap. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: e6ad1fb3458f ("perf parse-events: Restrict core PMU bypass to --cputype option") Signed-off-by: Sasha Levin commit fa437210fcbd64487f182bb2bf8b431c93857b82 Author: Ian Rogers Date: Mon Jun 15 18:15:28 2026 -0700 perf evsel: Add reference count [ Upstream commit 3b6a78b0a4420e5d161e1bb6e8394fc5b3c62d04 ] As with evlist this a no-op for most of the perf tool. The reference count is set to 1 at allocation, the put will see the 1, decrement it and perform the delete. The purpose for adding the reference count is for the python code. Prior to this change the python code would clone evsels, but this has issues if events are opened, etc. leading to assertion failures. With a reference count the same evsel can be used and the reference count incremented for the python usage. To not change the python evsel API getset functions are added for the evsel members, no set function is provided for size as it doesn't make sense to alter this. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: e6ad1fb3458f ("perf parse-events: Restrict core PMU bypass to --cputype option") Signed-off-by: Sasha Levin commit 744f25f0cbab4602e341b34103d898569b5e4862 Author: Ian Rogers Date: Mon Jun 15 18:15:27 2026 -0700 perf evlist: Add reference count [ Upstream commit 3c45ce5ae3703d41a87d1dee6735b82c29014f98 ] This a no-op for most of the perf tool. The reference count is set to 1 at allocation, the put will see the 1, decrement it and perform the delete. The purpose for adding the reference count is for the python code. Prior to this change the python code would clone evlists, but this has issues if events are opened, etc. This change adds a reference count for the evlists and a later change will add it to evsels. The combination is needed for the python code to operate correctly (not hit asserts in the evsel clone), but the changes are broken apart for the sake of smaller patches. Assisted-by: Gemini:gemini-3.1-pro-preview Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: e6ad1fb3458f ("perf parse-events: Restrict core PMU bypass to --cputype option") Signed-off-by: Sasha Levin commit a1a3ba14f4430ee2cc7aa3431171189206e7cf08 Author: Ian Rogers Date: Mon Jun 15 18:15:23 2026 -0700 perf util: Sort includes and add missed explicit dependencies [ Upstream commit faa0abae75f7116d461415ab268f70cacb736741 ] Fix missing includes found while cleaning the evsel/evlist header files. Sort the remaining header files for consistency with the rest of the code. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: e6ad1fb3458f ("perf parse-events: Restrict core PMU bypass to --cputype option") Signed-off-by: Sasha Levin commit 5678f866a499cc845f06617112d848e7ded522a6 Author: Ian Rogers Date: Thu Jun 11 18:24:13 2026 -0700 perf pmu: Recognize default_core as a core PMU in more places [ Upstream commit dfab3e4b0bf7f772889e8ebc2fd691fc95b596c9 ] The python metrics code used in places like ilist.py passes a pmu-filter of "default_core" on non-hybrid x86/ARM/.. systems. As a PMU like "cpu" isn't a literal name match then no PMU matches "default_core" and the events fail to parse for the metric. Fix the name matching and PMU lookup for "default_core" and check that it fixes ilist.py. Fixes: 74e2dbe7be50 ("perf tools: Add --pmu-filter option for filtering PMUs") Signed-off-by: Ian Rogers Reviewed‑by: Qinxin Xia Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e482f9ee977625fbc2a5e27c38748f12d4ee7d86 Author: Aaradhana Sahu Date: Tue Jun 16 11:53:42 2026 +0530 wifi: ath12k: correct monitor destination ring size [ Upstream commit 913998f903fb1432c0046c33003db38a9e8bedb1 ] The default memory profile configures rxdma_monitor_dst_ring_size as 8092, which is a typo. The intended value is 8192, consistent with all other ring sizes in the table being powers of two. Correct the monitor destination ring size to 8192. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: defae535dd63 ("wifi: ath12k: Add a table of parameters entries impacting memory consumption") Signed-off-by: Aaradhana Sahu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260616062342.4079796-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit de3e5561378047b12e6a32ce41f56cdeac26d433 Author: Miaoqing Pan Date: Sat May 9 10:58:15 2026 +0800 wifi: ath12k: fix TLV32 length mask [ Upstream commit d762bbc08ca70a1985c9f9420c4bf67e0ba0e9be ] HAL_TLV_HDR_LEN was using the wrong bitmask; fix it to cover bits [21:10]. Also drop HAL_SRNG_TLV_HDR_{TAG,LEN} and use the generic TLV header bit definitions for TLV32/TLV64 encode/decode to avoid redundant macros. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Miaoqing Pan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260509025819.1641630-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 82396ecb8f5183ff3b336621a12f2dd769af1af5 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 4661b90eb66fb5124986108f5dfe141e1eac13e8 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 b7f54ac6a1313539f57902bdc16b9becaf6e2eab Author: Dave Jiang Date: Mon Jun 29 15:11:02 2026 -0700 cxl/test: Propagate -ENOMEM on platform_device_alloc() failures [ Upstream commit 98ba41c3236b9a3bad206dbd9cf18c98ced75726 ] Set rc = -ENOMEM at every platform_device_alloc() failure site in cxl_rch_topo_init(), cxl_single_topo_init() and cxl_test_init() so the failure is propagated and the module load aborts cleanly. The cxl_acpi allocation site originates in the commit below, while the host-bridge/root-port/uport/dport allocation sites fixed here were added later in the single-host and RCH topology configs. Fixes: 67dcdd4d3b83 ("tools/testing/cxl: Introduce a mocked-up CXL port hierarchy") Fixes: e41c8452b9b2 ("tools/testing/cxl: Add a single-port host-bridge regression config") Fixes: c9435dbee119 ("tools/testing/cxl: Add an RCH topology") Assisted-by: Claude:claude-opus-4-8 Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260629221104.3891733-6-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 348a95be3238982fc1bb86f1ab6879b6b55bb36f Author: Dave Jiang Date: Mon Jun 29 15:11:01 2026 -0700 cxl/test: Add hierarchy enumeration support for type2 device [ Upstream commit 6b2e585142e68b4af821a1eca4d1e8d54bd49bb8 ] Add enumeration of type2 device hierarchy in cxl-test. The type2 device is setup to be directly attached to a root port instead of rp -> switch -> device that type3 hierarchy is setup.. Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260629221104.3891733-5-dave.jiang@intel.com Signed-off-by: Dave Jiang Stable-dep-of: 98ba41c3236b ("cxl/test: Propagate -ENOMEM on platform_device_alloc() failures") Signed-off-by: Sasha Levin commit 3e0285b77f515db9ac9a50d47a8ae7bda96d60ca Author: Dave Jiang Date: Mon Jun 29 15:11:00 2026 -0700 cxl/test: Refactor platform device enumerations [ Upstream commit a6d37152d284a49249a545861d1094cb678b5d32 ] Split all the host bridges, rootports, upstream and downstream ports enumerations to separate helper functions. This should make adding type2 hierarchy easier later on. Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260629221104.3891733-4-dave.jiang@intel.com Signed-off-by: Dave Jiang Stable-dep-of: 98ba41c3236b ("cxl/test: Propagate -ENOMEM on platform_device_alloc() failures") Signed-off-by: Sasha Levin commit 3f6fba439a2d35eada9ba81d3b9f6fee2225a1d3 Author: Dave Jiang Date: Mon Jun 29 15:10:58 2026 -0700 cxl/test: Add test for module parameters [ Upstream commit afae0fa7c6b163339a5d357942b89956a0820e45 ] Add a test for module paraters during module init to make sure that only one is activated. [dj: Dropped counting fail_autoassemble modparm. (Alison) ] Suggested-by: Alison Schofield Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260629221104.3891733-2-dave.jiang@intel.com Signed-off-by: Dave Jiang Stable-dep-of: 98ba41c3236b ("cxl/test: Propagate -ENOMEM on platform_device_alloc() failures") Signed-off-by: Sasha Levin commit 66aa3763cf3fe3bb113d3c62c4e2b6730a64d868 Author: Thomas Richter Date: Mon Jun 29 13:05:59 2026 +0200 perf test: Skip failing 'perf test aslr' test case [ Upstream commit 5786fa53dc7a4ae027ee2dbf321ed2286c4c20b5 ] The test case 'perf test aslr' fails on s390. The root cause of the failure is subtest test_callchain_aslr. This test invokes command # ./perf record -g -e task-clock:u -o /tmp/perf-test-aslr \ -- perf test -w noploop 3 to generate a call stack using event task-clock:u. On s390 this defaults to '--call-graph dwarf' whereas on x86_64 this defaults to framepointer (fp) format. The command # ./perf inject --aslr -i /tmp/perf-test-aslr now scans all SAMPLE entries recorded in the perf.data file to convert possible addresses. This is done in aslr_tool__process_sample() looking at sample_type bits PERF_SAMPLE_IP, PERF_SAMPLE_TID, PERF_SAMPLE_TIME, PERF_SAMPLE_PERIOD, PERF_SAMPLE_CALLCHAIN, PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER. On s390 the samples do not contain FP entries of type PERF_SAMPLE_CALLCHAIN (the bit is set in sample_type, but the number of FP entries is 0). The processing enters the PERF_SAMPLE_STACK_USER portion where the data is copied to the newly constructed sample and then aborted with this warning: /* TODO: can this be less conservative? */ pr_debug("Dropping stack user sample as possible ASLR leak\n"); With command line option '--call-graph dwarf' the new output file does not contain any samples at all. This leads to a missing $new_addr value in the shell script and a failure. Fix this and skip this subtest. Emit a hint that this subtest is currently unsupported on all platform when option --call-graph dwarf is selected. Since one subtest is skipped, the complete test is reported as skipped. Fixes: 190c45463844 ("perf test: Add inject ASLR test") Signed-off-by: Thomas Richter Reviewed-by: Ian Rogers Suggested-by: Sumanth Korikkar Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 15a6207d39b16e7969125c9750ec27592de3c908 Author: Breno Leitao Date: Tue Jun 30 09:15:20 2026 -0700 workqueue: only show running workers in stall diagnostics [ Upstream commit 7ddfa24d3f12ab9f3ac0e0b4e8e573ff45574d86 ] show_cpu_pool_busy_workers() dumps every in-flight worker in the pool's busy_hash, including workers that are not currently running on the CPU. Restore the task_is_running() filter so only running workers are dumped. When no running worker is found the pool may be stuck, unable to wake an idle worker to process pending work, and the watchdog would otherwise give no feedback. Add show_pool_no_running_worker() to report the pool id, CPU, idle state, and worker counts in that case. The pool info message is printed inside pool->lock using printk_deferred_enter/exit, the same pattern used by the existing busy-worker loop, to avoid deadlocks with console drivers that queue work while holding locks also taken in their write paths. This has been running on the Meta fleet for a while and caught some real issues, for instance EFI stalls stalling the workqueue [1]. Link: https://lore.kernel.org/all/20260616-efi_timeout-v3-0-76dd1d26657b@debian.org/ [1] Suggested-by: Petr Mladek Fixes: 8823eaef45da7 ("workqueue: Show all busy workers in stall diagnostics") Reviewed-by: Petr Mladek Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 0d98c5669d01c4ce202532c477de39396f5d0b4b Author: Jinjie Ruan Date: Mon Jun 29 17:47:37 2026 +0800 riscv: kexec_file: Fix crashk_low_res not exclude bug [ Upstream commit 5fc6e7d45373571d03cd04fd4c6069c0a97fa75a ] As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X") and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for crashkres_low.") for arm64, while implementing crashkernel=X,[high,low], riscv should have excluded the "crashk_low_res" reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, and the exclusion would need an extra crash_mem range. Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned in [2]. And the second kernel can be started normally. # dmesg | grep crash [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) [ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB) [1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 [2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Cc: Guo Ren Cc: Baoquan He Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]") Reviewed-by: Guo Ren Signed-off-by: Jinjie Ruan Link: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 Link: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Link: https://patch.msgid.link/20260629094746.191843-2-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 23d41b2e68765ad7095b1424f70c21c281f8a600 Author: Akash Goel Date: Tue Jun 23 14:01:19 2026 +0100 drm/panthor: Fix NPD issue on partial unmap of an evicted BO [ Upstream commit 5fb40edc7439b99d001988da63485ca51dbd3550 ] This commit fixes the NULL pointer dereference issue that would have happened on the split of GPU mapping due to partial unmap of an evicted BO. There is a logic to handle the partial unmap of huge pages when the GPU mapping is split. That logic was not being completely skipped for the VMA of an evicted BO and that resulted in a NPD possibility for the 'bo->backing.pages' pointer, which is set to NULL when pages of a BO are released on eviction. Following dump was seen when a partial unmap was exercised for an evicted BO. Unable to handle kernel paging request at virtual address 0000000000002000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008842e8000 [0000000000002000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : iova_mapped_as_huge_page+0x20/0x68 [panthor] lr : panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor] sp : ffff800086193920 x29: ffff800086193920 x28: ffff800086193a18 x27: ffff800086193b80 x26: 0000000000400000 x25: 0000000000810000 x24: 0000000000400000 x23: ffff000808af1800 x22: 0000000000a00000 x21: ffff800086193a00 x20: ffff000806fd3f00 x19: 0000000000410000 x18: 00000000ffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff800083ce2d83 x14: 0000000000000000 x13: 3120646574636976 x12: 6520303030303138 x11: 2d30303030313420 x10: ffff8000836e6c80 x9 : ffff80007bfc889c x8 : 3fffffffffffefff x7 : ffff8000836e6c80 x6 : 0000000000000000 x5 : ffff00097ef19088 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000010000 x1 : 0000000000000400 x0 : 0000000000000000 Call trace: iova_mapped_as_huge_page+0x20/0x68 [panthor] (P) op_remap_cb.isra.0+0x70/0xb0 __drm_gpuvm_sm_unmap+0xf8/0x1c0 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa0/0x168 [panthor] panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor] panthor_ioctl_vm_bind+0xbc/0x170 [panthor] drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xb4/0x118 invoke_syscall+0x5c/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x38/0x128 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 Code: 8b030021 cb020021 f940b800 d34cfc21 (f8617801) ---[ end trace 0000000000000000 ]--- v2: Fix indentation Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Signed-off-by: Akash Goel Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260623130119.2737003-1-akash.goel@arm.com Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit f01cb11729447ab373b81c184f57d06eed73e847 Author: Adrián Larumbe Date: Fri May 22 19:51:59 2026 +0100 drm/panthor: Support sparse mappings [ Upstream commit 12cf826bf1dd9275773cbef02c81ec1c67def7c3 ] Allow UM to bind sparsely populated memory regions by cyclically mapping virtual ranges over a kernel-allocated dummy BO. This alternative is preferable to the old method of handling sparseness in the UMD, because it relied on the creation of a buffer object to the same end, despite the fact Vulkan sparse resources don't need to be backed by a driver BO. The choice of backing sparsely-bound regions with a Panthor BO was made so as to profit from the existing shrinker reclaim code. That way no special treatment must be given to the dummy sparse BOs when reclaiming memory, as would be the case if we had chosen a raw kernel page implementation. A new dummy BO is allocated per open file context, because even though the Vulkan spec mandates that writes into sparsely bound regions must be discarded, our implementation is still a workaround over the fact Mali CSF GPUs cannot support this behaviour on the hardware level, so writes still make it into the backing BO. If we had a global one, then it could be a venue for information leaks between file contexts, which should never happen in DRM. As a side note, care was put to adjust dummy BO offsets for sparse mappings so that all addresses in the new VA are mapped aligned against it. Signed-off-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/20260522185206.2798288-6-adrian.larumbe@collabora.com Signed-off-by: Steven Price Stable-dep-of: 5fb40edc7439 ("drm/panthor: Fix NPD issue on partial unmap of an evicted BO") Signed-off-by: Sasha Levin commit e215d705f5a076edfd4745c0bd7e9596b9186185 Author: Adrián Larumbe Date: Fri May 22 19:51:56 2026 +0100 drm/panthor: Pass vm_bind_op to vm_prepare_map_op_ctx [ Upstream commit 3ed4e3988525d0f2af836f581956b1f594f9d47c ] Instead of passing its constituent elements, pass the whole struct to simplify the function prototype. Reviewed-by: Steven Price Reviewed-by: Boris Brezillon Signed-off-by: Adrián Larumbe Link: https://patch.msgid.link/20260522185206.2798288-3-adrian.larumbe@collabora.com Signed-off-by: Steven Price Stable-dep-of: 5fb40edc7439 ("drm/panthor: Fix NPD issue on partial unmap of an evicted BO") Signed-off-by: Sasha Levin commit 727f043d699ab0d5d87122c2177f2b45fbe58d35 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 76777e5d5139f69c95d358ca844ab3e256b58925 Author: Dapeng Mi Date: Tue Jun 16 12:46:48 2026 +0800 perf/x86/intel: Keep cap_user_rdpmc in sync with RDPMC user-disable state [ Upstream commit 3c4ec9b2a5db56b60127bfaf933ecdeea7a1f10a ] After introducing the RDPMC user disable feature, user-space RDPMC may return 0 instead of the actual event count. This creates an inconsistency with cap_user_rdpmc, where cap_user_rdpmc is set, but user-space RDPMC only returns 0. To accurately represent the user-space RDPMC capability, update cap_user_rdpmc (depending on PERF_EVENT_FLAG_USER_READ_CNT) according to the RDPMC user disable state. If RDPMC user disable is enabled, cap_user_rdpmc is updated to false eventually, allowing user-space programs to fall back to the read() syscall to obtain the real event count. Because PERF_EVENT_FLAG_USER_READ_CNT is evaluated in x86_pmu_event_init(), move intel_pmu_update_rdpmc_user_disable() earlier into intel_pmu_hw_config(). This ensures that the user-disable state is updated before updating PERF_EVENT_FLAG_USER_READ_CNT. Note that since event->ctx is not yet assigned at this stage, use the PERF_ATTACH_TASK flag to detect whether the event is task-attached. While at it, fix the indentation of x86_pmu_has_rdpmc_user_disable() to adhere to the kernel coding style. Fixes: 59af95e028d4 ("perf/x86/intel: Add support for rdpmc user disable feature") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260616044654.3468742-3-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 1a6a214f732d917262605ebdf0f686f64d00357d Author: Felix Gu Date: Sat May 23 18:27:05 2026 +0800 pinctrl: imx1: fix device_node leak in dt_is_flat_functions() [ Upstream commit 7b1272d02e65d2d4aeffb0d85b290a8753d24c12 ] for_each_child_of_node() holds a reference on the iterator node that must be released on early return. imx1_pinctrl_dt_is_flat_functions() has two early return paths inside the loop that skip this cleanup. Replace both loops with the scoped variant so that the reference is automatically dropped when the iterator goes out of scope. Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes") Signed-off-by: Felix Gu Reviewed-by: Frank Li Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 64aa1bb4017d598828c6d8cd718f43daf2a83375 Author: Zide Chen Date: Thu Jun 11 09:00:32 2026 -0700 perf/x86/intel/uncore: Fix uncore_box ref/unref ordering [ Upstream commit 174f0582e38abe03b88e15f04bfe58490f88cb19 ] In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering. Fixes: c74443d92f68 ("perf/x86/uncore: Support per PMU cpumask") 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-8-zide.chen@intel.com Signed-off-by: Sasha Levin commit 9c8967bcbb77e9970410b7fef1a036fa8b27ad9d Author: Zide Chen Date: Thu Jun 11 09:00:31 2026 -0700 perf/x86/intel/uncore: Introduce PMU flags and broken state [ Upstream commit 30c0a1095652275768a5de67188ff888d1f5d190 ] Replace the boolean 'registered' field in intel_uncore_pmu with an unsigned long 'flags' field, and add a PMU_BROKEN flag to track box setup failures. The broken flag is sticky, meaning it is cleared only by a module reload or system reboot. Broken PMUs are skipped in the CPU hotplug and box allocation paths. When any box fails to initialize, the PMU is marked broken. Broken PMUs reject new event assignments and skip future box setup attempts. If the PMU was already registered, it remains so to avoid disrupting in-flight events on other boxes. Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260611160033.66760-7-zide.chen@intel.com Stable-dep-of: 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") Signed-off-by: Sasha Levin commit 23fcbd6df3fd377feb4af7034e10d1db476a4fa2 Author: Zide Chen Date: Thu Jun 11 09:00:30 2026 -0700 perf/x86/intel/uncore: Factor out box setup code [ Upstream commit ae7ca8796ddac708db592c5a68555414c451afcc ] The PCI uncore PMU path already implements a lazy registration model: the PMU is registered when the first active box appears and unregistered when the last active box is removed. Factor this registration management into a shared helper, so the same code can be reused by the MSR and MMIO paths in later changes. No functional change intended. 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-6-zide.chen@intel.com Stable-dep-of: 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") Signed-off-by: Sasha Levin commit 18f4d93162155e9fdc9255a4d36300cb5650705b Author: Zide Chen Date: Thu Jun 11 09:00:28 2026 -0700 perf/x86/intel/uncore: Let init_box() callback report failures [ Upstream commit cbbc25209ce34f1baeec615553b93904a7a5d8cd ] The init_box() callback currently returns void, so initialization failures are silently ignored and the box is still marked initialized. Change the callback to return int so platform code can report errors back to the common uncore layer. Update uncore_box_init() to set the initialized flag only when init_box() succeeds. Because box->refcnt guarantees that at most one CPU calls uncore_box_init() for a given box at a time, plain __set_bit() is safe for the initialized flag without atomic overhead. Convert all init_box() implementations to return 0 on success or a negative error code on failure. This is a prerequisite for propagating initialization errors to the caller so they can be handled properly. 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-4-zide.chen@intel.com Stable-dep-of: 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") Signed-off-by: Sasha Levin commit c27d15aac37a65e397333bf8f3f4bfff74eee36a Author: Zide Chen Date: Thu Jun 11 09:00:27 2026 -0700 perf/x86/intel/uncore: Fix refcnt and other cleanups [ Upstream commit 7d3a9ff98898b3521eb5d7a3daf703b383f7935a ] Fix typo UNCORE_BOX_FLAG_INITIATED to UNCORE_BOX_FLAG_INITIALIZED. Rename the 'id' parameter in uncore_box_{ref,unref}() to 'die' to reflect its actual meaning and be consistent with other functions. box->refcnt is incremented in the PCI PMU register path but has never been checked or decremented. Although for PCI PMUs box->refcnt effectively tracks only a single user, add atomic_dec_return() in the PCI PMU unregister path to make the reference counting complete and consistent. Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260611160033.66760-3-zide.chen@intel.com Stable-dep-of: 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") Signed-off-by: Sasha Levin commit 5026e40cf9268940714cf8380f3a9517f6f4b421 Author: Zide Chen Date: Thu Jun 11 09:00:26 2026 -0700 perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure [ Upstream commit 003267cb94e21d762eb72d6977d84f44f1705bb7 ] When uncore_pci_pmu_register() fails, pmu->boxes[die] is set to NULL before returning. In the uncore_pci_remove() path, this causes uncore_pci_pmu_unregister() to be skipped entirely, leaking pmu->activeboxes. In the uncore_bus_notify() path, uncore_pci_pmu_unregister() may still be called and must exit early when pmu->boxes[die] is NULL to avoid a NULL pointer dereference, and to ensure activeboxes is only decremented for a previously active box. Additionally, since pci_get_drvdata() returns NULL on registration failure, uncore_pci_remove() can no longer treat NULL drvdata as an indicator of an auxiliary PCI device. Remove the associated WARN_ON_ONCE(). Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://sashiko.dev/#/patchset/20260512233048.9577-1-zide.chen@intel.com?part=1 Link: https://patch.msgid.link/20260611160033.66760-2-zide.chen@intel.com Stable-dep-of: 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") Signed-off-by: Sasha Levin commit a48296454b4867f58083c03ef464ee60a5a1bee6 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 f94e62d21faad5e244d0874598a4d0ebbc0ea405 Author: Chen, Yu C Date: Sat Jun 20 11:54:22 2026 +0800 sched/fair: Fix overflow in update_tg_cfs_runnable() [ Upstream commit 4f166adb5cb0525d9e32d45729fd8f28c80acbee ] A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix) Fixes: 95246d1ec80b ("sched/pelt: Relax the sync of runnable_sum with runnable_avg") Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Chen Yu Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/a22eea2b-4c4a-4623-9a44-d7b18c0c91c8@intel.com Signed-off-by: Sasha Levin commit 089e307fda2eaa731190183c7ecab432419a0b18 Author: Peter Zijlstra Date: Fri Jun 26 09:36:52 2026 +0200 sched/core: Fix inter-class wakeup_preempt() [ Upstream commit fa02b2868420d9f33d64ddcb15ef0f96880b2a6d ] The way wakeup_preempt() works since commit 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()") is that it will call rq->next_class->wakeup_preempt(rq, p) when p is of an equal or higher class, and raise ->next_class when higher. This means that: running idle task wakeup fair-A (next_class == idle) if (sched_class_above(fair, idle)) { wakeup_preempt_idle(fair-A); resched_curr(rq); next_class = fair; } wakeup fair-B (next_class == fair) if (fair == fair) wakeup_preempt_fair(fair-B); (but current is idle) All wakeup_preempt_$class() methods, except for wakeup_preempt_scx() (for whoem this was build) ignore cross-class wakeups by testing if @p is of the right class, but per the above case, it also should check current. This is mostly harmless in the current form, but will lead to trouble with later patches. Fixes: 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()") Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260626074605.GB2568396%40noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit d452a11898eb21e2ef290b2de6dd0eb7dfefb5c0 Author: Wei Yang Date: Mon Jun 22 02:24:03 2026 +0000 mm/mm_init: fix incorrect node_spanned_pages [ Upstream commit 7783dcd79ae9c4aa48bc47bd4275772445dc4b2a ] Current node_spanned_pages is got as a summation of all zone's spanned page in calculate_node_totalpages(). Generally this is good, but if we use kernelcore=mirror, it is would be wrong. Without kernelcore=mirror: The test machine has below memory layout: memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0 memory[0x1] [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x0 memory[0x2] [0x0000000100000000-0x00000001bfffffff], 0x00000000c0000000 bytes on node 0 flags: 0x0 And the Zone range is: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x00000001bfffffff] Then we see, with spanned_pages printed: On node 0 spanned_pages: 1835007 totalpages: 1572733 With kernelcore=mirror: The test machine has below memory layout: memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x2 memory[0x1] [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x2 memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x2 memory[0x3] [0x0000000140000000-0x00000001bfffffff], 0x0000000080000000 bytes on node 0 flags: 0x0 And the Zone range is: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x00000001bfffffff] Device empty Movable zone start for each node Node 0: 0x0000000140000000 Then we see, with spanned_pages printed: On node 0 spanned_pages: 2359295 totalpages: 1572733 The total range of memory on node 0 doesn't change, but the spanned_pages becomes much larger. The reason is when kernelcore=mirror is specified, the range of Zone Normal and Zone Movable would overlap. So the overlapped range would be calculated twice. A wrong node_spanned_pages would effect defer_init(), since each zone_end_pfn is less than pgdat_end_pfn(). As we already passed in node_start_pfn and node_end_pfn, fix this by get it from (node_start_pfn - node_end_pfn) directly. Fixes: 342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") Signed-off-by: Wei Yang Cc: Yuan Liu Link: https://patch.msgid.link/20260622022403.16375-1-richard.weiyang@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit e0773ad25a34a49aece176721c466cf214e02222 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 666700062f1cea561aaa8ad0eec9d28e5d3a8bcf 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 99a07a8976704415abb71d964833ed5ae9f6f25a Author: Shengjiu Wang Date: Thu Jun 25 13:47:09 2026 +0800 arm64: dts: imx8mp-ab2: Enable MU2 for DSP communication [ Upstream commit b1b6c1c4d3c63d8097c933009bdb618d1be18305 ] Enable the MU2 (Message Unit 2) node on the i.MX8MP Audio Board v2. MU2 is required for inter-processor communication between the application CPU and the HiFi4 DSP, allowing DSP firmware to exchange control and status messages with the Linux host. Without this change, the DSP driver cannot establish the message channel and DSP audio processing is non-functional. Fixes: bf68c18150efc ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)") Signed-off-by: Shengjiu Wang Reviewed-by: Daniel Baluta Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 11047c7ed5cc3cd44e01fb3a3e79119c406da6dc Author: Francesco Dolcini Date: Mon Jun 22 11:35:06 2026 +0200 arm64: dts: freescale: imx95-toradex-smarc: add alias for lpuart5 [ Upstream commit 3385e2f77182469940c136b9eeedf01f27b7441f ] Add alias for lpuart5 so the UART gets a stable line number. Without this alias, the lpuart driver fails: fsl-lpuart 42590000.serial: failed to get alias id, errno -19 This prevents the Bluetooth controller connected to this UART from working. Fixes: 104a391bb6ff ("arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5") Signed-off-by: Francesco Dolcini Acked-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4e29df25bbe67e820889b5a622b6084e2f0e5152 Author: Frieder Schrempf Date: Tue Jun 16 12:43:09 2026 +0200 arm64: dts: imx93-kontron: set memory node to 0x80000000/1GiB [ Upstream commit 9c269fe7eae8cb60d8d6c326dd8955818722fae9 ] The start address of the DRAM area is 0x80000000. The minimal size of the DDR on the SoM is 1 GiB. Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit db414a1cb1d46c7f4a2aa486324bf8cd62eb2da2 Author: Li Jun Date: Wed Jun 10 08:38:14 2026 +0800 firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show [ Upstream commit 4cf26bc2e7e099c86127d63ed7272753da45737e ] Add a proper NULL check for the kmalloc() return value in syslog_show(). If memory allocation fails, syslog would be NULL and passing it to misc_syslog() could lead to a NULL pointer dereference. Fixes: 80a4062e8821 ("firmware: imx: sm-misc: Dump syslog info") Signed-off-by: Li Jun Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit bea093a6e388b32af30df20f94da03dc74711496 Author: Yuho Choi Date: Mon May 4 12:47:11 2026 -0400 ARM: OMAP2+: Fix OF node reference leaks in omap_hwmod [ Upstream commit 76103814279724e5c98b1c16a730f56ebede9f74 ] The OF helpers that return device nodes acquire references that must be released by the caller. _init() leaks the "ocp" bus node returned by of_find_node_by_name() on all paths after lookup, and also leaks the child returned by of_get_next_child() when parsing module flags. Route the post-lookup returns through a common cleanup path and release the child after use. omap_hwmod_setup_earlycon_flags() leaks the /chosen node and the UART node resolved from stdout-path. Track them separately and drop both references after use. Fixes: 1aa8f0cb19e5 ("ARM: OMAP2+: Remove unused legacy code for interconnects") Fixes: 4f2122473363 ("ARM: OMAP2+: Check also the first dts child for hwmod flags") Fixes: 8dd6666f4937 ("ARM: OMAP2+: omap_hwmod: Add support for earlycon") Signed-off-by: Yuho Choi Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260504164711.2854116-1-dbgh9129@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit 67c9db97fa0873098eeb48db0d4dcda836b48811 Author: Weigang He Date: Wed Jun 10 15:06:25 2026 +1000 ARM: imx: fix device_node refcount leaks in imx7_src_init() [ Upstream commit 3de939b2ac843d56d88e2ab1e1b1f667cba9e1d4 ] imx7_src_init() obtains two device_node references via of_find_compatible_node() - one for "fsl,imx7d-src" and one for "fsl,imx7d-gpc" - reusing the same np variable, but never calls of_node_put() on either. On every i.MX7D boot up to two device_node refcounts are leaked: - The "fsl,imx7d-src" node is leaked both when of_iomap() fails (the early return after the mapping) and when it succeeds, because np is then overwritten by the second of_find_compatible_node() call without releasing the prior reference. - The "fsl,imx7d-gpc" node is leaked on every path leaving the function after it is acquired. Release each reference immediately after of_iomap() consumes the node. of_iomap() maps the node's registers but does not retain a reference to the device_node, so it is safe to put the node once mapped; this also drops the first reference before np is reused for the second lookup. Found by static analysis tool CodeQL. Fixes: e34645f45805 ("ARM: imx: add smp support for imx7d") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6b60c84e7846951e35b44ce9cc82c27a1d9cdcc0 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 48852aed107009910d75603bf6244525a5353b74 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 eebc053abef683e32d23a3e78156020b2bfaadcb Author: Philipp Zabel Date: Thu Jun 11 10:18:59 2026 +0200 arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl [ Upstream commit c33b03ac7ff7ca0267ae7a4284a2b9258483614d ] Configure HDMI DDC SCL/SDA pins to support reading EDID. Signed-off-by: Philipp Zabel Fixes: 95d7d7d2ad27 ("arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support") Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 22c944e440bc9b16c4ee409943d69bb8ef575c9e Author: Shengjiu Wang Date: Thu Jun 18 10:38:18 2026 +0800 ASoC: fsl_audmix: rework runtime PM handling in probe [ Upstream commit 3359ba93d01a23b2e4249e9e44ccfe48eb9c5d71 ] After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration. Fixes: be1df61cf06ef ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260618023818.31618-1-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a47f087877bb2bc57c3ccb714fc49abf45d28e12 Author: Runyu Xiao Date: Fri Jun 19 20:23:25 2026 +0800 ASoC: rt700-sdw: always drain jack work on remove [ Upstream commit 612ccf42acd14bb2685fa60c3495ca13e63e8989 ] rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems. Fixes: 737ee8bdf682 ("ASoC: rt700-sdw: use cancel_work_sync() in .remove as well as .suspend") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260619122325.2504287-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d9f555852975139baee549232ecc40930da471c Author: Rosen Penev Date: Tue May 19 15:26:39 2026 -0700 clk: stm32: add missing bitfield.h header [ Upstream commit 0bf68e8dcb843f094ed73c2c54e9fe58a7a4f774 ] It seems some ARM header includes this and the build passes there, but nowhere else. Note that the driver has COMPILE_TEST in depends. Fixes: 37ae8501cdb0 ("clk: stm32: introduce clocks for STM32MP21 platfor") Signed-off-by: Rosen Penev Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit a0a546a9625d3d38d5df4ef740a7a7231647df3e Author: Joey Lu Date: Thu May 21 09:42:20 2026 +0800 clk: nuvoton: ma35d1: fix ma35d1_clk_pll_determine_rate logic [ Upstream commit e1311954cb600d5f95cd9e2fe9a7376edc2ac3c5 ] ma35d1_clk_pll_determine_rate() called ma35d1_pll_find_closest() unconditionally before the switch statement, and then every case branch overwrote pll_freq by reading the current hardware registers. For CAPLL and DDRPLL this means find_closest() ran unnecessarily (and incorrectly, since those PLLs are read-only) and its result was silently discarded. Fix by moving the find_closest() call inside the APLL/EPLL/VPLL branch where it belongs. Group CAPLL and DDRPLL together as read-only PLLs that simply report their current rate; handle them with an explicit if/else to keep the CAPLL (SMIC design) and DDRPLL (standard design) paths distinct. Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Signed-off-by: Joey Lu Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit ff955d3d1c45e84c8b28970a14590b78afe0110f Author: Joey Lu Date: Thu May 21 09:42:19 2026 +0800 clk: nuvoton: ma35d1: fix PLL_CTL1_FRAC bit field width and fractional calc [ Upstream commit 26de5aed72d80bd8aec2583134aca3597c64fda9 ] PLL_CTL1_FRAC was defined as GENMASK(31, 24), covering only 8 bits. The hardware fractional field occupies bits [31:8] (24 bits), so the mask must be GENMASK(31, 8). The previous fractional-mode calculation used FIELD_MAX(PLL_CTL1_FRAC) as the denominator to obtain 2 decimal places. With the corrected 24-bit mask the old divisor is wrong; replace the arithmetic with a proper 24-bit fixed-point rounding to 3 decimal places using the kernel's DIV_ROUND_CLOSEST_ULL helper: n_frac = n * 1000 + DIV_ROUND_CLOSEST_ULL(x * 1000, 1 << 24) Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Signed-off-by: Joey Lu Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 0a6901e715baedf2d8493fbae739b433dd62c8e1 Author: Joey Lu Date: Thu May 21 09:42:18 2026 +0800 clk: nuvoton: ma35d1: fix ignored div_u64 return values in PLL freq calculation [ Upstream commit b3a2223a7805c7e6759a32a5d6ca574ad07e2710 ] div_u64() does not modify its argument in place; the return value must be assigned. Both ma35d1_calc_smic_pll_freq() and ma35d1_calc_pll_freq() called div_u64() and discarded the result, leaving pll_freq holding the undivided product and thus returning a frequency orders of magnitude too high. Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Reviewed-by: Brian Masney Signed-off-by: Joey Lu Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 36d5c243d2db61a9daf6199b576b8cb8ad70f774 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 69815429f8bc7c5e7304a4841b61d7a81d7b5192 Author: Xuyang Dong Date: Fri Jun 5 17:21:18 2026 +0800 clk: eswin: Add CLK_IGNORE_UNUSED to NoC clock [ Upstream commit 22109b7329f9b3bf2fee73087c73ce46e9bf3751 ] The gate_noc_nsp_clk provides the essential clock source for NPU, DSP, and PCIe subsystems. During kernel init, the clock framework attempts to disable unused clocks when clk_ignore_unused kernel parameter is not set. However, gate_noc_nsp_clk is required to remain enabled for these critical subsystems to function properly, causing PCIe boot failures when auto-disabled. Add CLK_IGNORE_UNUSED flag to gate_noc_nsp_clk to ensure it stays enabled even when clk_ignore_unused is not specified in kernel command line. Fixes: cd44f127c1d4 ("clk: eswin: Add eic7700 clock driver") Signed-off-by: Xuyang Dong Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit c37fa5d8b2a6988a26baf102715d8d2532d98de6 Author: David Carlier Date: Thu Jun 18 05:50:30 2026 +0100 clk: canaan: Clear rate fields before reprogramming dividers [ Upstream commit 804bac4a2654ac69e328d68e1961eb984fb18a01 ] The rate set_rate helpers perform a read-modify-write on the divider and multiplier registers but only ever OR the new value in, without first masking off the existing field. The first write after reset lands on a zeroed field and looks correct, but any later reprogramming leaves the old bits set: the field becomes the bitwise OR of the previous and new encodings, corrupting the divider or multiplier. Mask off each field before writing the new value so reprogramming a clock to a different rate produces the intended register contents. Fixes: a7b7c7c6c016 ("clk: canaan: Add clock driver for Canaan K230") Signed-off-by: David Carlier Reviewed-by: Brian Masney Acked-by: Xukai Wang Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 7b38ddc1c1fb0f03f4c28ac449f7cf7c46050857 Author: Myeonghun Pak Date: Tue Jun 23 18:40:18 2026 +0900 clk: versaclock7: Fix APLL clock leak on probe failure [ Upstream commit e25d8d35e8cbc1a4c04a8b86eed6aa7229f6449e ] vc7_probe() registers the APLL with clk_register_fixed_rate(), which is not devm-managed and must be explicitly unregistered on probe failure. Most later errors already unwind through err_clk, but a failure from vc7_get_bank_clk() in the output registration loop returned directly. That skipped clk_unregister_fixed_rate() and leaked the APLL clock. Route that error through the existing err_clk label so the fixed-rate clock is released consistently with the other probe failure paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 48c5e98fedd9 ("clk: Renesas versaclock7 ccf device driver") 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 9c2b1efef2537d632feca2dfc426aa095a6a71aa Author: Yuho Choi Date: Mon Jun 15 13:45:35 2026 -0400 ARM: imx: avic: Fix OF node reference leaks [ Upstream commit b24c12e1bad863d27141e4e9c19d25eebd68c4a6 ] of_find_compatible_node() returns a device node with its reference count incremented. mxc_init_irq() looks up the i.MX25 CCM node for of_iomap() and the AVIC node for irq_domain_create_legacy(), but does not release either temporary reference. of_iomap() does not consume the node reference, and irq_domain_create_legacy() takes its own fwnode reference for the domain. Drop the temporary OF node references after each use. Fixes: 9b454d16e57d ("ARM: imx: avic: set low-power interrupt mask for imx25") Fixes: 544496ab5cbd ("ARM: imx: move irq_domain_add_legacy call into avic driver") Signed-off-by: Yuho Choi Reviewed-by: Martin Kaiser Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit f0c12add5439d51ddfe74b0463d41c78550d664a Author: Wei Hou Date: Sun Jun 28 23:58:57 2026 +0800 cxl/pci: Remove incorrect mbox.valid check in cxl_pci_type3_init_mailbox() [ Upstream commit d79b81893d0cc93737e811a465b9ef9a00156fd5 ] The driver's design intent is that missing or malformed component registers should not prevent mailbox initialization. cxl_pci_probe() already reflects this: the CXL_REGLOC_RBI_COMPONENT setup path only emits a dev_warn() and continues when component registers are absent, rather than returning an error. The check 'if (!cxlds->reg_map.device_map.mbox.valid)' violates this intent and is also technically incorrect for two reasons: 1. Wrong struct: the MEMDEV register block is enumerated into a local variable 'map', not into 'cxlds->reg_map'. The device_map.mbox.valid field inside cxlds->reg_map is never written by the MEMDEV probe and will always read as zero regardless of actual hardware capability. 2. Already validated: cxl_pci_setup_regs(CXL_REGLOC_RBI_MEMDEV) calls cxl_probe_regs() which explicitly checks mbox.valid and returns -ENXIO if the mailbox is absent. If that check passes, the mailbox is guaranteed to be present by the time cxl_pci_type3_init_mailbox() is called. The value that the check actually reads is component_map.ras.valid, which aliases device_map.mbox.valid in the union. This is populated by the COMPONENT probe, not the MEMDEV probe. On devices where the component register BAR does not implement a CXL Component Capability Array (e.g. certain DCD devices), cxl_probe_component_regs() returns early leaving ras.valid=false. Through the union, this makes mbox.valid read as false, causing cxl_pci_type3_init_mailbox() to return -ENODEV (-19) even though the mailbox hardware is fully functional. Remove the check. Mailbox presence has already been validated by cxl_pci_setup_regs(CXL_REGLOC_RBI_MEMDEV). The presence or absence of component registers is irrelevant to mailbox initialization. Fixes: 8d8081cecfb9 ("cxl: Move mailbox related bits to the same context") Reviewed-by: Richard Cheng Signed-off-by: Wei Hou Reviewed-by: Li Ming Link: https://patch.msgid.link/20260628155857.239866-1-wei.hou@scaleflux.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 723808b2c117c4063c22dad57dcb9cbebadab2b2 Author: Richard Zhu Date: Thu Jun 4 10:38:21 2026 +0800 arm64: dts: imx943: Correct PCIe outbound address space configuration [ Upstream commit 6de3a7d7a4f653be4901d07425719c4e55805167 ] Fix the PCIe outbound memory ranges for both pcie1 controllers on i.MX943. The memory window size was incorrectly set to 256MB during initial bring-up, but the hardware supports up to 4GB of outbound address space per controller. Additionally, the ECAM region cannot be mapped as I/O space. Use a memory-mapped region for I/O space instead, and relocate the 1MB I/O region to immediately follow the memory region at offset 0xf0000000 within each window. Update the outbound address space layout per controller as follows: - 3.5GB 64-bit prefetchable memory - 256MB 32-bit non-prefetchable memory - 1MB I/O Fixes: fa6067fd8ea7 ("arm64: dts: imx943: Add pcie1 and pcie1-ep supports") Signed-off-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 0c6897bdadffb750d478cccc7805f520c671537a Author: Richard Zhu Date: Thu Jun 4 10:38:20 2026 +0800 arm64: dts: imx94: Correct PCIe outbound address space configuration [ Upstream commit ffccbd6804e885f0fc23f0005f6bee7789a7a887 ] Fix the PCIe outbound memory ranges for both pcie0 controllers on i.MX94. The memory window size was incorrectly set to 256MB during initial bring-up, but the hardware supports up to 4GB of outbound address space per controller. Additionally, the ECAM region cannot be mapped as I/O space. Use a memory-mapped region for I/O space instead, and relocate the 1MB I/O region to immediately follow the memory region at offset 0xf0000000 within each window. Update the outbound address space layout per controller as follows: - 3.5GB 64-bit prefetchable memory - 256MB 32-bit non-prefetchable memory - 1MB I/O Fixes: 8cd439f17758 ("arm64: dts: imx94: Add pcie0 and pcie0-ep supports") Signed-off-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b4e11c731d6bee3b87315e055a1ca417c92dc1fc Author: Richard Cheng Date: Wed Jun 24 22:41:47 2026 +0800 cxl/mbox: Clamp mailbox output allocation to the payload size [ Upstream commit 8a13db9f899d149c3aab24abcb668121cfda5a4f ] CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path. Fixes: 583fa5e71cae ("cxl/mem: Add basic IOCTL interface") Reviewed-by: Kai-Heng Feng Reviewed-by: Koba Ko Reviewed-by: Dave Jiang Reviewed-by: Davidlohr Bueso Signed-off-by: Richard Cheng Link: https://patch.msgid.link/20260624144147.53997-1-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 4992cdc4eb97981d6ea66002c5b764a6115edb0c Author: Mert Seftali Date: Sun Jun 14 14:40:19 2026 +0200 ASoC: SOF: ipc4-topology: Return error for invalid number of formats [ Upstream commit 11e828cd6b0f283ebe9dc6b4cffd38e3321e7725 ] When the number of input or output formats is zero, sof_ipc4_widget_setup_comp_src() and sof_ipc4_widget_setup_comp_asrc() print an error and jump to the cleanup label. At that point 'ret' is still 0, because the earlier sof_ipc4_get_audio_fmt() call succeeded, so the function returns success and the caller never finds out that the widget setup actually failed. Set ret to -EINVAL before the goto so the error gets reported. Fixes: 21a5adffad46 ("ASoC: SOF: ipc4-topology: Validate the number of in/out formats for src/asrc") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202606111431.Uky3T0tF-lkp@intel.com/ Signed-off-by: Mert Seftali Link: https://patch.msgid.link/20260614124019.19259-1-mertsftl@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a81768b43b59293077cece76329129a847dda1d8 Author: Miquel Raynal (DAVE) Date: Fri May 29 18:29:58 2026 +0200 mtd: rawnand: pl353: Fix debug prints [ Upstream commit 2b7baaddf1bc3e39206a0354449fdc349945b86b ] They are partially incorrect since "software" engine does not mean hamming, the "none" cae is also falling into this print, and on-die means there is some kind of hardware support; we prefer to use the wording on-host vs. on-die. Fix all those prints. Fixes: 1e06dbfdfb85 ("mtd: rawnand: pl353: Add message about ECC mode") Signed-off-by: Miquel Raynal (DAVE) Acked-by: Michal Simek Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 6559174fcb15136af85ffc8a563f914e78d6a5ad 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 394dec22a5d598f94544195efcd05bcb7e34dfc5 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 99330b12376c3373ab555c24bc797630f03b81a2 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 12c889727ddc0b2000dd689560cd62eb91972678 Author: Christos Maragkos Date: Wed Jun 3 18:21:34 2026 +0300 HID: nintendo: Fix imu_timestamp_us double increment per report [ Upstream commit 1f9b25d3fb65b9384dec16d9db13a3e71abd9145 ] Previously, the imu_timestamp_us variable was incremented twice per report, causing it to advance by two times the desired amount. This resulted in incorrect jumps in IMU timestamps reported using MSC_TIMESTAMP, so userspace applications saw corrupted timing on functions such as gyroscope-based aim and motion controls. This is fixed by removing the redundant increment at the start of the report handling so the remaining can account for the full report interval. Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support") Signed-off-by: Christos Maragkos Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0fecd89f979a8653b9a5b0816570329b7a94a081 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 b1af4cccae71703adfbab9a30d59860f213131d4 Author: Amin Vakil Date: Thu Jun 18 18:44:44 2026 +0330 selftests: proc: include fcntl.h in proc-pidns [ Upstream commit 879b3353d04d043a9e01525c520d9b81339421b2 ] proc-pidns.c uses open() and O_* flags, but does not include . This breaks the proc selftests build with errors such as: error: implicit declaration of function 'open' error: 'O_WRONLY' undeclared error: 'O_CREAT' undeclared error: 'O_RDONLY' undeclared Include to provide the declaration and flag definitions. Fixes: 5554d820f71c ("selftests/proc: add tests for new pidns APIs") Tested with: make -C tools/testing/selftests TARGETS=proc Signed-off-by: Amin Vakil Link: https://patch.msgid.link/20260618151444.124739-1-info@aminvakil.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 54d6b0ee9b8ba434089b11843effc111dc2e6ead Author: Maoyi Xie Date: Thu Jun 25 21:00:56 2026 +0800 platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count [ Upstream commit a0a8cd9fc9c48b95095bcec4b146f7a99486f58e ] cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. memcpy(caps_desc.pdo, resp->source_cap_pdos, sizeof(u32) * resp->source_cap_count); ... memcpy(caps_desc.pdo, resp->sink_cap_pdos, sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared. Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs") Suggested-by: Andrei Kuchynski Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Benson Leung Reviewed-by: Andrei Kuchynski Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit aeb3e0083a07d9827711d93cfa4bf42b40fb60c6 Author: Jens Remus Date: Thu Jun 11 17:57:15 2026 +0200 x86/cfi: Use symmetric SYM_START and SYM_END in __CFI_TYPE() [ Upstream commit 0cfdf974f133e0ff17ed80e7895adbe7889d9522 ] Commit ccace936eec7 ("x86: Add types to indirectly called assembly functions") introduced a x86-specific implementation of __CFI_TYPE() using an asymmetric combination of SYM_START() and SYM_FUNC_END() to add a symbol to the KCFI type identifier that precedes a function. This asymmetric combination is an issue if SYM_FUNC_END() ever gets extended in a way that requires it to be used symmetrically with SYM_FUNC_START*(). For instance to emit DWARF CFI directives that denote the start/end of a function. [1] Use SYM_END() with SYM_T_FUNC instead. No functional change, as the generic implementation of SYM_FUNC_END(name) expands into SYM_END(name, SYM_T_FUNC). Fixes: ccace936eec7 ("x86: Add types to indirectly called assembly functions") Closes: https://sashiko.dev/#/patchset/20260522110427.2816637-1-jremus@linux.ibm.com?part=3 [1] Reported-by: Sashiko Signed-off-by: Jens Remus Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Acked-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260611155716.830563-1-jremus@linux.ibm.com Signed-off-by: Sasha Levin commit 6a052a154106ec8c0cfbc36a01d62c41c12e04ae Author: Damon Ding Date: Wed Jun 17 16:07:55 2026 +0800 drm/bridge: of-display-mode-bridge: Fix missing static const for the bridge funcs [ Upstream commit 6648301c5bb2ef23f0fb15bcb01d21ff66f36799 ] Add static qualifier for of_display_mode_bridge_funcs to resolve the sparse warning: drivers/gpu/drm/bridge/of-display-mode-bridge.c:54:25: sparse: sparse: symbol 'of_display_mode_bridge_funcs' was not declared. Should it be static? Also mark the structure const as required by devm_drm_bridge_alloc() parameter type constraints. Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606170744.FUStcWaB-lkp@intel.com/ Signed-off-by: Damon Ding Reviewed-by: Luca Ceresoli Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260617080755.186368-1-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 26cb44b0afff9e70786ec6be3a7e04bc439206c6 Author: Wanwu Li Date: Mon Jun 8 15:24:57 2026 +0800 sched_ext/scx_flatcg: Fix cvtime_delta race and add hweight scaling to bypass charging [ Upstream commit a5cc43414b38decd50bdd447e558358a6fbd5864 ] 1. cgrp_cap_budget() used __sync_fetch_and_sub(&cgc->cvtime_delta, cgc->cvtime_delta) to atomically read and clear cvtime_delta. However, this is not a true atomic read-clear operation: the second argument (cgc->cvtime_delta) is evaluated as a normal read before the atomic fetch_and_sub executes. If a concurrent __sync_fetch_and_add() happens between the read and the sub, the added value gets included in the returned delta AND remains in cvtime_delta, causing double charging. Example: CPU 0 runs cgrp_cap_budget(), CPU 1 runs fcg_stopping(). Assume cvtime_delta = 100 initially. T1 CPU 0: sub_val = cvtime_delta = 100 cvtime_delta = 100 T2 CPU 1: __sync_fetch_and_add(&cvtime_delta, 10) cvtime_delta = 110 T3 CPU 0: __sync_fetch_and_sub(&cvtime_delta, sub_val) cvtime_delta = 10 returns old=110 delta = 110 (includes the 10 from CPU 1), but cvtime_delta = 10 (the 10 also remains). The 10 is charged twice: once in delta (applied to cgv_node->cvtime) and once in the residual cvtime_delta (fetched again next time). Fix by using __sync_fetch_and_and(&cgc->cvtime_delta, 0). Disassembly comparison: (1) delta = __sync_fetch_and_sub(&cgc->cvtime_delta, cgc->cvtime_delta); 228: (79) r7 = *(u64 *)(r9 +40) 229: (87) r7 = -r7 230: (db) r7 = atomic64_fetch_add((u64 *)(r9 +40), r7) //r9 may be changed (2) delta = __sync_fetch_and_and(&cgc->cvtime_delta, 0); 228: (b7) r8 = 0 229: (db) r8 = atomic64_xchg((u64 *)(r9 +40), r8) 2. The bypass charging path in fcg_stopping() charges raw execution time to cvtime_delta without scaling by the inverse of the cgroup hweight. Since cvtime_delta is eventually applied to cgv_node->cvtime which is in vtime space (weight-scaled), the bypass path should also scale by FCG_HWEIGHT_ONE / hweight to match the units used by the dispatch path. Fixes: a4103eacc2ab ("sched_ext: Add a cgroup scheduler which uses flattened hierarchy") Signed-off-by: Wanwu Li Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit c776670f4ec9df6e84c87e8d4d2796ba7e486b2f Author: Waiman Long Date: Tue Jun 23 19:04:12 2026 -0400 cgroup/cpuset: Avoid unnecessary cpus & mems update in cpuset_hotplug_update_tasks() [ Upstream commit 866f587e9c70566a0391bf402123555605a82f81 ] As reported by sashiko [1], cpuset_hotplug_update_tasks() may perform unnecessary task iteration and updating of tasks' CPU and node masks when mems_allowed and/or cpus_allowed are not set in cpuset v2. It is due to the fact that the temporary new_cpus and new_mems masks do not inherit parent's effective_cpus/mems when they are empty which is the expected behavior for cpuset v2 since commit 4ec22e9c5a90 ("cpuset: Enable cpuset controller in default hierarchy"). Fix that and avoid unnecessary work by enhancing compute_effective_cpumask() to add the empty cpumask check and inheriting the parent's versions if empty when in v2. A new compute_effective_nodemask() helper is also added to perform a similar function for new effective_mems. Add new test_cpuset_prs.sh test cases to confirm that effective_cpus will inherit the parent's version if cpuset.cpus is empty. [1] https://sashiko.dev/#/patchset/20260621032816.1806773-1-longman%40redhat.com Suggested-by: Ridong Chen Fixes: 4ec22e9c5a90 ("cpuset: Enable cpuset controller in default hierarchy") Signed-off-by: Waiman Long Reviewed-by: Ridong Chen Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f2df709905ab6b95daf50b96180a5fadb0f5df5a 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 4d27a8221010329c3738dda738aae9c32e121d8f 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 c62a818897189fceb145a897ab7539394750103f 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 d02c55e3ea82e41ea2c2026e08201e5daa4d0cfe 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 66f8255d1dd0f2bd3268a971066feac1fa0de972 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 4a2355385486cff7b0b617ee5ac008a5accd0dc5 Author: Maxime Ripard Date: Fri Jun 19 14:24:06 2026 +0200 drm/bridge: cdns-dsi: Return an error pointer on allocation failure [ Upstream commit 79ac5c68f1a49a9fdec596ee47577d5a1d52738f ] 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_dsi_bridge_atomic_reset() callback returns NULL when the allocation of its state fails, violating this contract. Return ERR_PTR(-ENOMEM) instead. Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()") Reviewed-by: Luca Ceresoli Reviewed-by: Thomas Zimmermann Tested-by: Luca Ceresoli # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-1-ff399263111b@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit b49e7a24cf5bdcd9dd9dc4d067f8b2623973b26d Author: Deborah Brouwer Date: Wed Jun 10 17:01:26 2026 -0700 rust: drm: gpuvm: update DriverGpuVm for DeviceContext [ Upstream commit 20003c1a1fd80ae1b1742ff54297b67f7f21b77f ] Since the introduction of DeviceContext, there is no longer a single driver object type to equate with the GPUVM object type. Instead of threading DeviceContext through GPUVM, remove the strict identity between DriverGpuVm::Object and drm::Driver::Object and instead tighten the requirement that the DriverGpuVm::Object be an allocatable GEM object associated with the same DRM driver. Also, make GpuVm::new() generic over DeviceContext so it can accept a drm::Device. Fixes: 0023a1e8d01a ("rust/drm/gem: Use DeviceContext with GEM objects") Signed-off-by: Deborah Brouwer Reviewed-by: Alice Ryhl Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20260610-gpuvm_device_context_v1-v1-1-01a890b17448@collabora.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit c69e63065f35b65ffb15cacfbf507d9b35155d2f Author: Nicolas Frattaroli Date: Tue Jun 9 14:44:00 2026 +0200 drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format [ Upstream commit c1bfe8dac0a79d47eed313b9bcaa2658898684ec ] The Rockchip VOP2 video output driver has a "is_yuv_output" function, which returns true when a given bus format is a YUV format, and false otherwise. This switch statement is lacking the bus format used for YUV422 10-bit. Add the two component orderings of the YUV422 10-bit bus formats to the switch statement. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Cristian Ciocaltea Reviewed-by: Daniel Stone Signed-off-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260609-color-format-v17-13-35739b5782cc@collabora.com Signed-off-by: Daniel Stone Signed-off-by: Sasha Levin commit a53cc0561dd18ecd50b6c739941027b3d5b6881a Author: Nicolas Frattaroli Date: Tue Jun 9 14:43:59 2026 +0200 drm/rockchip: vop2: Add RK3576 to the RG swap special case [ Upstream commit ae4a4e69389d576941522c3c2e01a2254fd00d10 ] Much like RK3588, RK3576 requires an RG swap to be performed for YUV444 8-bit and YUV444 10-bit bus formats. Add its version to the already existing check for RK3588, so that YUV444 output is correct on this platform. Fixes: 944757a4cba6 ("drm/rockchip: vop2: Add support for rk3576") Reviewed-by: Andy Yan Reviewed-by: Daniel Stone Signed-off-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260609-color-format-v17-12-35739b5782cc@collabora.com Signed-off-by: Daniel Stone Signed-off-by: Sasha Levin commit 0d33645973227eea3f0137dd2797730316e9ef89 Author: Nicolas Frattaroli Date: Tue Jun 9 14:43:56 2026 +0200 drm/display: hdmi-state-helper: Try subsampling in mode_valid [ Upstream commit f532dc0ea55a25dd24a79442fd0348da09b04b72 ] drm_hdmi_connector_mode_valid assumes modes are only valid if they work with RGB. The reality is more complex however: YCbCr 4:2:0 chroma-subsampled modes only require half the pixel clock that the same mode would require in RGB. This leads to drm_hdmi_connector_mode_valid rejecting perfectly valid 420-only or 420-also modes. Fix this by checking whether the mode is 420-capable first. If so, then proceed by checking it with DRM_OUTPUT_COLOR_FORMAT_YCBCR420 so long as the connector has legalized 420, otherwise error out. If the mode is not 420-capable, check with RGB as was previously always the case. Fixes: 47368ab437fd ("drm/display: hdmi: add generic mode_valid helper") Reviewed-by: Maxime Ripard Reviewed-by: Dmitry Baryshkov Reviewed-by: Daniel Stone Signed-off-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260609-color-format-v17-9-35739b5782cc@collabora.com Signed-off-by: Daniel Stone Signed-off-by: Sasha Levin commit 0b9878aba5cf93bc2b55ba9eb807757ce3239bec Author: Maíra Canal Date: Thu Jun 4 17:32:15 2026 -0300 drm/v3d: Clear queue->active_job when v3d_fence_create() fails [ Upstream commit 25a1669907512e927fab9ad4d4fb74ff57f63cd9 ] The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free. Fixes: a783a09ee76d ("drm/v3d: Refactor job management.") Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-2-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 3b259831b738873230400719cfe2833bf8752566 Author: Alexandre Courbot Date: Sun May 31 21:37:27 2026 +0900 gpu: nova-core: gsp: tu102: keep unloading if FWSEC-SB fails [ Upstream commit 9eaff547805f8556992a9474465001c3e128b7bd ] On Turing and Ampere, resetting the GSP involves running two firmware images: FWSEC-SB and Booter Unloader. They are independent from one another, and we should do whatever is possible to restore the GSP's unloaded state even if a failure occurs along the way. Thus, keep going and run Booter Unloader even if the execution of FWSEC-SB failed. Fixes: adb99ce3cc78 ("gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260529-nova-unload-v7-0-678f39209e00%40nvidia.com?part=3 Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260531-nova-unload-fix-v1-1-c8dcdc769b53@nvidia.com [acourbot: log Booter Unloader errors.] Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 23c02299e7d1351d56d88232a29e10500505e8be Author: Dmitry Baryshkov Date: Thu May 28 10:10:50 2026 +0300 drm/bridge: display-connector: trigger initial HPD event for DP [ Upstream commit 60dc0946bbad3eef8bc66a5a8b09b98dbc6e09c0 ] If the DisplayPort drivers use display-connector for the HPD detection, the internal HPD state machine might be not active and thus the hardware might be not able to handle cable detection correctly. Instead it will depend on the external HPD notifications to set the cable state, bypassing the internal HPD state machine (for example this is the case for the msm DP driver). However if the cable has been plugged before the HPD IRQ has been enabled, there will be no HPD event coming. The drivers might fail detection in such a case. Trigger the HPD notification after enabling the HPD IRQ, propagating the cable insertion state. Note, this issue only affects drivers which set OP_HPD but not OP_DETECT (like dp-connector). Here DP differs from HDMI. For HDMI there is no additional state or extra "bridge with no sinks plugged" cases. The HPD pin state is equal to the display plugged state. Nor do we have an AUX bus with timeouts, etc. Fixes: 2e2bf3a5584d ("drm/bridge: display-connector: add DP support") Reported-by: Yongxing Mou Reviewed-by: Sebastian Reichel Link: https://patch.msgid.link/20260528-dp-connector-hpd-v3-3-d656eb1079b7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit a1303a44165ddf913f6756c84ada84a48156830f Author: Dmitry Baryshkov Date: Thu May 28 10:10:49 2026 +0300 drm/bridge: display-connector: don't autoenable HPD IRQ [ Upstream commit 8e9c475060bff87077cfa3bd42011edcb7fb3b0d ] If HPD IRQ is enabled in the display_connector's probe, it can be triggered too early, before the DRM connector is completely setup. Use the enable_hpd / disable_hpd callbacks to control enablement of the HPD IRQ. Fixes: 0c275c30176b ("drm/bridge: Add bridge driver for display connectors") Reviewed-by: Sebastian Reichel Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260528-dp-connector-hpd-v3-2-d656eb1079b7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 887315e5d2eb87c3d6d0da9f7610bc5b3113ae30 Author: Damon Ding Date: Mon Jun 1 14:50:55 2026 +0800 drm/rockchip: analogix_dp: Fix OF node reference leak via auto cleanup [ Upstream commit 87e060521371257ddbb77964b66e60d80afcc7b2 ] Sashiko reported a reference leak in rockchip_dp_drm_encoder_enable(), the of_get_child_by_name() function does not call of_node_put() in a symmetrical way [1]. Fix the device node reference leak by using __free(device_node) to automatically manage of_node_put() for all device nodes. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Link: https://sashiko.dev/#/patchset/20260527024336.191433-1-damon.ding@rock-chips.com?part=5 #1 Signed-off-by: Damon Ding Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601065100.1103873-7-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit 4cd23a6e5c9d6e58c982543d8d85439b70a425f3 Author: Damon Ding Date: Mon Jun 1 14:50:54 2026 +0800 drm/rockchip: analogix_dp: Enable hclk for RK3588 [ Upstream commit 104f20616d72825fdcf56cfdc5f89f4e96fd8dbe ] Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588 eDP controller to guarantee register and datapath access. The clock was previously enabled implicitly via rockchip,vo-grf phandle reference, which relies on side effect and is fragile. Fetch optional "hclk" clock in driver to align with updated device tree binding and keep consistent with hardware clock dependency. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Signed-off-by: Damon Ding Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601065100.1103873-6-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit 69173c1ebedec63a75514eb7ca78c8859f82f4a9 Author: Cristian Ciocaltea Date: Mon May 4 21:24:00 2026 +0300 drm/rockchip: vop2: Wait for layer cfg done before switching LAYERSEL_REGDONE_SEL [ Upstream commit d1ad644e572c0647ad8428439eafea0aacfccf9e ] LAYERSEL_REGDONE_SEL mask of RK3568_OVL_CTRL register controls which Video Port (VP) vsync latches the shared RK3568_OVL_{LAYER|PORT}_SEL shadow registers into the active configuration. rk3568_vop2_setup_layer_mixer() overwrites LAYERSEL_REGDONE_SEL to the current VP ID before waiting for the previous VP layer configuration to take effect. As a consequence, the previous VP vsync can no longer trigger the latch, so the wait polls a value that might never appear. Move the layer cfg done wait before the RK3568_OVL_CTRL write so the previous VP vsync can still commit the pending configuration. Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Signed-off-by: Cristian Ciocaltea Reviewed-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260504-vop2-layer-cfg-tmout-v1-2-730226a7331e@collabora.com Signed-off-by: Sasha Levin commit e83dbc07404a056b4692a3cc7ea10e70b9d3c9e6 Author: Cristian Ciocaltea Date: Mon May 4 21:23:59 2026 +0300 drm/rockchip: vop2: Fix wrong wait target in layer cfg done check [ Upstream commit 9f5670802df085ad343146561e69bac43e9905d2 ] rk3568_vop2_setup_layer_mixer() waits for the previous Video Port (VP) layer configuration to take effect before writing a new one to the shared RK3568_OVL_LAYER_SEL shadow register. However, it passes vop2->old_layer_sel to rk3568_vop2_wait_for_layer_cfg_done() as the expected value, which at that point already contains the new VP layer. This causes the wait to poll for a value that has not been written to the shadow register yet, resulting in spurious timeouts when two non-blocking atomic commits race: rockchip-drm display-subsystem: [drm] *ERROR* wait layer cfg done timeout [...] Pass the local old_layer_sel instead, which still holds the value captured from vop2->old_layer_sel before it was overwritten, i.e. the previous VP target that the hardware is expected to latch. Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Signed-off-by: Cristian Ciocaltea Reviewed-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260504-vop2-layer-cfg-tmout-v1-1-730226a7331e@collabora.com Signed-off-by: Sasha Levin commit 11f07929f454ecc2c5d0da3a4727fd205be43e49 Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:46 2026 +0300 drm/rockchip: dw_dp: Release core resources [ Upstream commit cc6d7aca2f37a1525a94ef97eb3ce361732c876c ] Core resources such as the DisplayPort AUX channel get initialized and registered during dw_dp_bind(), but are never unregistered, which may lead to memory leaks and/or use-after-free: [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 [ 224.662612] [ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT [ 224.662759] Hardware name: Radxa ROCK 5B (DT) [ 224.662762] Call trace: [ 224.662764] show_stack+0x20/0x38 (C) [ 224.662772] dump_stack_lvl+0x6c/0x98 [ 224.662777] print_report+0x160/0x4b8 [ 224.662783] kasan_report+0xb4/0xe0 [ 224.662790] __asan_report_load8_noabort+0x20/0x30 [ 224.662796] device_is_dependent+0xe0/0x2b0 [ 224.662802] device_is_dependent+0x108/0x2b0 [ 224.662808] device_link_add+0x1f8/0x10b0 [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] [ 224.662864] component_bind_all+0x3a8/0x720 [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 [ 224.662904] component_master_add_with_match+0x1f4/0x230 [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] [ 224.662939] platform_probe+0xe8/0x168 [ 224.662945] really_probe+0x340/0x828 [ 224.662950] __driver_probe_device+0x2e0/0x350 [ 224.662954] driver_probe_device+0x80/0x140 [ 224.662959] __driver_attach+0x398/0x460 [ 224.662964] bus_for_each_dev+0xe0/0x198 [ 224.662968] driver_attach+0x50/0x68 [ 224.662972] bus_add_driver+0x2a0/0x4c0 [ 224.662977] driver_register+0x294/0x360 [ 224.662982] __platform_driver_register+0x7c/0x98 [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] Since a previous commit exported dw_dp_unbind() function in DW DP core library to take care of the necessary cleanup, use this in the component's unbind() callback, as well as in its bind() error path. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-3-c3f3f123e1da@collabora.com Signed-off-by: Sasha Levin commit b66710d95db2f4556fca435887aa6ef27ad01235 Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:45 2026 +0300 drm/rockchip: dw_dp: Add missing newline in dev_err_probe() message [ Upstream commit 0a01412178047bf3ff351c7e75d373e411072a87 ] Add the missing trailing newline to dev_err_probe() call in dw_dp_rockchip_bind(). Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Fixes: 26cb3e26efa7 ("drm/rockchip: dw_dp: Simplify error handling") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-2-c3f3f123e1da@collabora.com Signed-off-by: Sasha Levin commit 48aaa495e24ce5aec3dc56706473b0bd4305a306 Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:44 2026 +0300 drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel [ Upstream commit ed04e8e2307f35b3d8d49a554faf5e72d3d224e6 ] The DisplayPort AUX channel gets initialized and registered during dw_dp_bind(), but it is never unregistered, which may lead to resource leaks and/or use-after-free. Add the missing dw_dp_unbind() function to allow the users of the library to handle the required cleanup, i.e. unregister the AUX adapter. Fixes: 86eecc3a9c2e ("drm/bridge: synopsys: Add DW DPTX Controller support library") Reviewed-by: Andy Yan Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-1-c3f3f123e1da@collabora.com Signed-off-by: Sasha Levin commit 317dc1ead82e27d55fa1a4e053b3c9443b15b28b Author: Paul Kocialkowski Date: Thu Apr 2 20:33:51 2026 +0200 drm: lcdif: Wait for vblank before disabling DMA [ Upstream commit 351af554edd994898db12217c3be39979e168d35 ] It is necessary to wait for the full frame to finish streaming through the DMA engine before we can safely disable it by removing the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the hardware confused and unable to resume streaming for the next frame. This causes the FIFO underrun and empty status bits to be set and a single solid color to be shown on the display, coming from one of the pixels of the previous frame. The issue occurs sporadically when a new mode is set, which triggers the crtc disable and enable paths. Setting the shadow load bit and waiting for it to be cleared by the DMA engine allows waiting for completion. The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep. Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by: Paul Kocialkowski Co-developed-by: Lucas Stach Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Acked-by: Liu Ying Link: https://patch.msgid.link/20260402183351.3281123-3-paulk@sys-base.io Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit ef28f1970de4bd506448146f97870ca1f0148f0d Author: Svyatoslav Ryhel Date: Mon May 11 10:45:37 2026 +0300 drm/tegra: dsi: Re-add clear enable register if DSI was powered by bootloader [ Upstream commit 27a58cc1a9c7bbe92a43fb5045bd17e148c8a022 ] Original commit b22fd0b9639e ("drm/tegra: dsi: Clear enable register if powered by bootloader") was added to address the issue of DSI being in an unknown state after the bootloader, ensuring correct panel configuration. This worked fairly well under the assumption that the bootloader had set up DSI; however, in cases where it did not, the device would hang because a DSI read was called before the DSI hardware was ready. Removing this workaround results in the issue described in the original fix: the panel initialization sequence fails and the panel gets stuck in an undefined state. This is especially noticeable with command mode panels In order to properly address this issue, the original workaround is restored and placed after the DSI hardware is prepared for R/W operations. This fixes behavior for both cases: where DSI is set by the bootloader and where DSI is untouched. I have tested this change on Tegra20 (Motorola Atrix 4G), Tegra114 (NVIDIA Tegra Note 7 and ASUS Transformer Pad TF701T), and Tegra124 (Xiaomi Mi Pad) with U-Boot, using both bootloader-initialized DSI and untouched DSI. Fixes: b22fd0b9639e ("drm/tegra: dsi: Clear enable register if powered by bootloader") Fixes: 660b299bed2a ("Revert "drm/tegra: dsi: Clear enable register if powered by bootloader"") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260511074538.24563-3-clamor95@gmail.com Signed-off-by: Sasha Levin commit 873fab4fa057b06b317a598a146b373679838752 Author: Maxime Ripard Date: Tue May 26 18:46:15 2026 +0200 drm/atomic: Drop drm_private_obj.state assignment from create_state [ Upstream commit dcf0292f4828341474428d016661b6c292d7211c ] The initial intent of the atomic_create_state hook was to simply allocate a proper drm_private_state and return it, without any side effect. However, __drm_atomic_helper_private_obj_create_state(), which most atomic_create_state implementations call, introduces a side effect by setting drm_private_obj.state to the newly allocated state. This assignment defeats the purpose, but is also redundant since drm_atomic_private_obj_init(), the only call site for the atomic_create_state hook, will also set this pointer to the newly allocated state. Drop the assignment in __drm_atomic_helper_private_obj_create_state(). Fixes: e7be39ed1716 ("drm/atomic-helper: Add private_obj atomic_create_state helper") Reviewed-by: Laurent Pinchart Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260526-drm-mode-config-init-v6-3-852346394200@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 20a30536d60e36710e34318a8a6b827ee4f57b39 Author: Yicong Hui Date: Thu Apr 9 16:48:26 2026 +0100 drm: Remove unused header in drm_dumb_buffers.c [ Upstream commit 38b4ce17ef3421fb0e5e6dbdab1974282bde1165 ] Remove the header #include "drm_internal.h" from drm_dumb_buffers.c, which is included but not used. Header was introduced in commit 47f10854ca89 ("drm: Don't export the drm_gem_dumb_destroy() function") when moving functions, but was not removed in commit 96a7b60f6ddb ("drm: remove dumb_destroy callback") when the drm_gem_dumb_destroy function was removed. Compiles successfully with DRM enabled, pass kunit tests and IGT-tests in a vng virtual machine. Fixes: 96a7b60f6ddb ("drm: remove dumb_destroy callback") Signed-off-by: Yicong Hui Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260409154826.8955-1-yiconghui@gmail.com Signed-off-by: Sasha Levin commit b34b41c5bda73b9d9aaf1feff18498f623fdd9d0 Author: Casey Schaufler Date: Sun Mar 22 11:04:06 2026 -0700 Smack: Fix error in capability bypass [ Upstream commit b2faddc13112489f8f11eb40b9456db8c1b58362 ] A bug in smack_inode_xattr_skipcap() was introduced in the inode capability handling. The strncmp guard at the top of the function is coded backwards, resulting in consistently incorrect results. Correct the check, and the code functions as it should. The error manifests as requiring CAP_SYS_ADMIN as well as CAP_MAC_ADMIN to change an inode's MAC attributes. Fixes: 61df7b828204 ("lsm: fixup the inode xattr capability handling") Reported-by: Bumjin Im Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit dfc4ee8954d3e828e3d210c831ce24836ffe07c5 Author: Yosry Ahmed Date: Thu Sep 10 22:31:05 2026 -0400 KVM: x86: Check EFER validity on KVM_SET_SREGS* [ Upstream commit 184bd464bdb66daa9173670904f24c29c7b7f7d4 ] When handling userspace SREGS writes, check the validity of EFER (i.e. allowed bits) before writing the new value of EFER through the per-vendor set_efer callbacks. This prevents userspace from writing bogus values (e.g. EFER.SVME=1 with nested=0). Note: on KVM_SET_MSRS, KVM only checks EFER validity in terms of KVM caps, not guest caps, so it is possible to set EFER bits that are supported by KVM but not by the guest CPUID. Potentially allowing userspace to set msrs before CPUID. However, for KVM_SET_SREGS*, check the validity of the set bits against both KVM and guest caps. This is consistent with other validity checks (e.g. for CR4) that check validity against guest caps, which already imposes the need to set CPUID before SREGS. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713180153.2728382-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fb2065261ec6b6397848ccb671dc58d5ef44bdd Author: Sean Christopherson Date: Thu Sep 10 22:31:04 2026 -0400 KVM: x86: Move the bulk of register specific code from x86.c to regs.c [ Upstream commit 2f5bb3fe583510cf20f9d64aa73089577be3dc36 ] Introduce regs.c, and move the vast majority of register specific code out of x86.c and into regs.c. Deliberately leave behind MSR code, as KVM's MSR support is complex enough to warrant its own compilation unit, and doesn't have much in common with the other register code. Note, "struct kvm_sregs" has fields for EFER and MSR_IA32_APICBASE, and so the {G,S}ET_REGS flows technically contain a tiny amount of MSR code. MSR_IA32_APICBASE is already managed by lapic.c, and so doesn't require a "placement decision". As for EFER, leave all other EFER handling in x86.c (later to be moved to msrs.c). The primary interface to EFER, set_efer(), is very much MSR specific, even though EFER is arguably more of a Control Register than an MSR. No functional change intended. Reviewed-by: Kai Huang Signed-off-by: Sean Christopherson Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 562f2b0c8824aa141d563aef67d9c0140b81184e Author: Sean Christopherson Date: Thu Sep 10 22:31:03 2026 -0400 KVM: x86: Rename __{g,s}et_sregs2() => kvm_vcpu_ioctl_x86_{g,s}et_sregs2() [ Upstream commit bd130c8d72a1c7dde5523b3f3fae9867eafaa1dc ] Rename the KVM_{G,S}ET_SREGS2 helpers in anticipation of moving them out of x86.c (while leaving the ioctl dispatch behind). Having globally visible APIs named __{g,s}et_sregs2() would be "fine", but ugly, given that __{g,s}et_sregs() will NOT be globally visible. As a bonus, this makes it a bit more obvious that the helpers implement newer versions of kvm_arch_vcpu_ioctl_set_sregs(). No functional change intended. Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Message-ID: <20260613000329.732085-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 515dead3bb6402823e837a298171aa2b7d22f055 Author: Sean Christopherson Date: Thu Sep 10 22:31:02 2026 -0400 KVM: x86: Move get_segment_base() to regs.h, as kvm_get_segment_base() [ Upstream commit 0217de73439caf56db74da95b3bbad8c1cb066c4 ] Move get_segment_base() to regs.h, as kvm_get_segment_base(), so that the bulk of the register code can be moved from x86.c to a new regs.c, without simultaneously needing to rename "public" helpers to explicitly scope them to KVM. No functional change intended. Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e92b03627ad894e003fe629f9fb6dd00474711af Author: Sean Christopherson Date: Thu Sep 10 22:31:01 2026 -0400 KVM: x86: Extract REGS and SREGS runtime sync code to helpers [ Upstream commit 6a8a98aa9c147eb63f5a360f157f207bf46c05ee ] Extract the REGS and SREGS portions of {store,sync}_regs() into separate helpers in anticipation of moving the register specific code out of x86.c and into regs.c. No functional change intended. Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34c1d674cef84222d8045cfbbde7da3a54acb5d8 Author: Imran Shaik Date: Thu Sep 10 21:29:25 2026 -0400 clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLs [ Upstream commit 830ead322c39c99bf972425b3c35323ec56c29de ] CLK_ALPHA_PLL_TYPE_DEFAULT_EVO type PLLs do not have the PLL_TEST_CTL_U1 register, so clk_alpha_pll_configure() does not program test_ctl_hi1_val for this PLL type. The GCC PLL configurations for QCM2290, Shikra and SM6115 wrongly use test_ctl_hi1_val instead of test_ctl_hi_val, deviating from the hardware recommended settings. Fix them to use test_ctl_hi_val. Fixes: 496d1a13d405 ("clk: qcom: Add Global Clock Controller driver for QCM2290") Fixes: 01cf3e27824d ("clk: qcom: Add Global clock controller support on Qualcomm Shikra SoC") Fixes: e88c533d8a2a ("clk: qcom: gcc-sm6115: Add missing PLL config properties") Cc: stable@vger.kernel.org Signed-off-by: Imran Shaik Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260729-pll-test-ctrl-fixup-v1-1-246d79589380@oss.qualcomm.com Signed-off-by: Bjorn Andersson [ Omitted gcc-shikra.c changes because the driver is absent from the target branch. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a78b7697a88e8d83be19de44d192adbcd577225 Author: Lorenzo Stoakes (ARM) Date: Thu Sep 10 21:17:46 2026 -0400 mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP [ Upstream commit 35b0fb391b0df57383bc15985bb769f4555c97ba ] Uniquely an mremap() invocation using the MREMAP_DONTUNMAP flag can reset a faulted VMA into an unfaulted one. It does so after the page tables have been moved to the copied VMA with MREMAP_DONTUNMAP leaving the old VMA in place which is naturally unfaulted as the page tables it had are no longer present. However, in doing so, it violates the invariant that the anonymous page offset of an unfaulted VMA is vma->vm_start >> PAGE_SHIFT. This is because a VMA may have been faulted in, mremap()'d (causing a delta between its page offset and vma->vm_start >> PAGE_SHIFT), and then mremap()'d again with MREMAP_DONTUNMAP resulting in the unfaulting. This condition is a violation of a fundamental assumption in mm, but now also triggers an assert in assert_sane_pgoff() which explicitly checks for this condition. Correct it by resetting the VMA's page offset at the point of completing the MREMAP_DONTUNMAP operation. Link: https://lore.kernel.org/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org Fixes: 1583aa278f5f ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a87853b.ae6ddae5.3da009.0023.GAE@google.com/ Tested-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Kunwu Chan Reviewed-by: Pedro Falcato Cc: Jann Horn Cc: Liam R. Howlett Cc: Li Xinhai Cc: Signed-off-by: Andrew Morton [ adapted VMA page-offset helpers to use the branch’s single vm_pgoff field. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1e740b9156621afd4c4aa66257f4dde8df1febe Author: Li Chen Date: Thu Sep 10 20:29:28 2026 -0400 nvdimm: virtio_pmem: refcount requests for token lifetime [ Upstream commit e57140944b5a47a7fd5a142faab29a02af040bc8 ] KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning. Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Cc: stable@vger.kernel.org Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-9-me@linux.beauty> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4a140f0a30f2ce73bfd4f6a192c0825ae83aeef Author: Li Chen Date: Thu Sep 10 20:29:27 2026 -0400 nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags [ Upstream commit 08e72a5ba1ab9dc0adf993ff0f4d606a1e3445a8 ] Use READ_ONCE()/WRITE_ONCE() for the wait_event() flags (done and wq_buf_avail). They are observed by waiters without pmem_lock, so make the accesses explicit single loads/stores and avoid compiler reordering/caching across the wait/wake paths. Acked-by: Pankaj Gupta Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-8-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc25f9a9db8eea05ff7eeef9a47478e6e05e0c97 Author: Li Chen Date: Thu Sep 10 20:29:26 2026 -0400 nvdimm: virtio_pmem: always wake -ENOSPC waiters [ Upstream commit 811808761e19fdea1c25b7c76734b8945f758f27 ] virtio_pmem_host_ack() reclaims virtqueue descriptors with virtqueue_get_buf(). The -ENOSPC waiter wakeup is tied to completing the returned token. If token completion is skipped for any reason, reclaimed descriptors may not wake a waiter and the submitter may sleep forever waiting for a free slot. Always wake one -ENOSPC waiter for each virtqueue completion before touching the returned token. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-7-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c9cd77db17a98d4994560de2cd8714967d635af1 Author: Li Chen Date: Thu Sep 10 20:29:25 2026 -0400 nvdimm: virtio_pmem: stop allocating child flush bio [ Upstream commit 40f356e610df95728074b1fc2e2ccb54ca1b5659 ] pmem_submit_bio() passes the parent bio to nvdimm_flush() for REQ_FUA. For virtio-pmem this makes async_pmem_flush() allocate and submit a child PREFLUSH bio chained to the parent. That child allocation is in the block submit path. Making it blocking with GFP_NOIO can consume the same global bio mempool that submit_bio() uses, while making it GFP_ATOMIC can fail under pressure. A forced failure of the child allocation produced: virtio_pmem: forcing child bio allocation failure for test Buffer I/O error on dev pmem0, logical block 0, lost sync page write EXT4-fs (pmem0): I/O error while writing superblock EXT4-fs (pmem0): mount failed Avoid the child bio without turning REQ_FUA into a synchronous submit-path wait. Let provider flush callbacks return NVDIMM_FLUSH_ASYNC after taking ownership of parent bio completion. pmem_submit_bio() returns in that case, and virtio-pmem queues an ordered WQ_MEM_RECLAIM work item that runs the existing host flush path and completes the parent bio. This keeps the asynchronous completion model of the child-bio path while removing the child bio allocation from the submit path. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-5-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72561ca1ab96f0f0f32737a6171641e05a318538 Author: Li Chen Date: Thu Sep 10 20:29:24 2026 -0400 nvdimm: pmem: keep PREFLUSH before data writes [ Upstream commit c644a2f8fef5618fcf453c591177700fd07dd024 ] pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier. Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-3-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9414030257b4f84649f773bf08920b91e367ea4 Author: Li Chen Date: Thu Sep 10 20:29:23 2026 -0400 nvdimm: preserve flush callback -ENOMEM [ Upstream commit 6b7108712a4b1c37cac69815aede1dde202b3187 ] nvdimm_flush() maps provider flush failures to -EIO. Keep that default because provider callbacks can report host-side or backend failures that should remain generic I/O errors to the guest. Guest-side allocation failures should not be reported as I/O errors. In the virtio-pmem path, the flush request allocation can fail with -ENOMEM before any request is submitted to the host. Mapping that to -EIO makes resource pressure look like media failure. Preserve -ENOMEM from provider callbacks and continue to map other non-zero provider failures to -EIO. The generic flush path still returns 0, and pmem_submit_bio() already converts errno values to block status for bio completion. Suggested-by: Pankaj Gupta Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-2-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 007bc1842317bb99f5f6205afede940f951674c2 Author: Shakeel Butt Date: Thu Sep 10 11:47:41 2026 -0400 memcg: move LRU size accounting on reparenting instead of copying it [ Upstream commit 0e0ac326c511d514817cc7b6d7741afd59098ce2 ] When a memory cgroup is offlined its LRU folios are reparented to the parent. lruvec_reparent_lru() splices the child's lists into the parent's and credits the parent with the child's per-zone lru_zone_size[], but never clears the child's copy, so the size is copied rather than moved. lru_gen_reparent_memcg() does the same for MGLRU. The parent is left correct, credited with exactly the folios it took over. The stale value sits on the child and nothing will correct it: folio->memcg_data now resolves to the parent, so every later update_lru_size() for those folios goes there. Dying cgroups are not freed immediately and mem_cgroup_iter() still walks them, so shrink_lruvec() keeps being called on them. get_scan_count() reads the phantom counter through lruvec_lru_size() and the scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against an empty list, for as long as the dead cgroup lives. Under MGLRU the MGLRU scanner runs instead, but count_shadow_nodes() sums all of NR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node limit just the same. On one 251 GiB host a sweep of every mz->lru_zone_size[] found 380 counters describing folios on no list at all: 124777314 pages, 476 GiB, 1.89x the machine's RAM, across 57 cgroups. All were on memcgs with CSS_DYING set and CSS_ONLINE clear, and parent/child pairs reported byte-identical sizes. LRU_UNEVICTABLE needs its size moved too. Its list is deliberately not spliced because lruvec_init() poisons the head - the unevictable LRU is imaginary and folios are never threaded on it - but the size is kept by lruvec_add_folio()/lruvec_del_folio() and those folios account to the parent from here on. This depends on commit bf4ade7dbd76 ("memcg: keep folio's objcg same as its node") and must not be backported ahead of it. Without that invariant a folio's objcg can belong to another node, so a folio already spliced onto the parent's list can still resolve to the child's lruvec until the objcg's node is reparented in a later iteration of memcg_reparent_objcgs(); clearing the child's counter early then lets lruvec_del_folio() underflow it and trip the WARN_ONCE()/VM_BUG_ON() in mem_cgroup_update_lru_size(). Link: https://lore.kernel.org/20260822024707.77192-1-shakeel.butt@linux.dev Fixes: 07a6e9a2c199 ("mm: vmscan: prepare for reparenting traditional LRU folios") Fixes: f304652609ea ("mm: vmscan: prepare for reparenting MGLRU folios") Signed-off-by: Shakeel Butt Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Roman Gushchin Cc: Muchun Song Cc: # After: bf4ade7dbd76: memcg: keep folio's objcg same as its node Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e30fbd26e84efa2e5cbec4eb11e126ac0c79313 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Sep 10 11:27:54 2026 -0400 ksmbd: fix tree connection use-after-free in smb2_tree_connect() [ Upstream commit b5ec6c462aab1062cf5d1e667ba7c6442f737055 ] ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it. BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90 smb2_tree_connect (fs/smb/server/smb2pdu.c:2872) handle_ksmbd_work process_one_work worker_thread kthread After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler. Keep the references balanced in every path: - On normal exit or an error after publication, smb2_tree_connect() drops its creator reference. Error cleanup also calls ksmbd_tree_conn_disconnect(), which drops the xarray reference only if it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same helper to remove the entry and drop its xarray reference. The request's existing lookup reference remains owned by the request and is released by the existing cleanup. - Session LOGOFF removes each entry and drops its xarray reference. If it wins the race, later cleanup sees that the entry is gone and does not drop that reference again. To enforce this ownership, claim the disconnected state and erase the exact entry atomically under tree_conns_lock. This guarantees one drop for the xarray reference and one drop by each in-flight user, regardless of which teardown path wins. If logoff removes the entry before initialization completes, fail the connect instead of marking the detached object TREE_CONNECTED. Fixes: 33b235a6e6eb ("ksmbd: fix race condition between tree conn lookup and disconnect") Reported-by: Xiang Mei (Microsoft) Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Signed-off-by: Namjae Jeon [ added braces around the successful-connect if branch to accommodate the new tree_conn assignment ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a6c88e5e3a75f1e4a98ad4bc4037465ccd7925bc Author: Ze Tan Date: Thu Sep 10 11:27:53 2026 -0400 smb/server: fix tree connection leak in smb2_tree_connect() [ Upstream commit 39f2032096715daae5f6fd0f587ca7a474b019df ] See the procedure below: smb2_tree_connect ksmbd_tree_conn_connect xa_store(&sess->tree_conns, tree_conn->id, tree_conn) ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS) ksmbd_share_tree_conn_inc(sc) ksmbd_iov_pin_rsp // fail status.ret = KSMBD_TREE_CONN_STATUS_NOMEM // do not disconnect tree_conn Disconnect the new tree connection if ksmbd_iov_pin_rsp() fails. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Stable-dep-of: b5ec6c462aab ("ksmbd: fix tree connection use-after-free in smb2_tree_connect()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35d5c59fe6b1d9fe43fb14eb384f69ee1a120f9c Author: Namjae Jeon Date: Thu Sep 10 11:27:52 2026 -0400 ksmbd: fix maximum allowed access checks [ Upstream commit cc2f133e80eb2c4a04bfa77a2f207749fe2f516a ] The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group. As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone. The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask. When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant. For regular files, include FILE_EXECUTE in maximal access when the client requested GENERIC_EXECUTE and the DACL grants the complete file-read set. Keep a direct FILE_EXECUTE request subject to the explicit DACL bit. This matches the POSIX file ACL mapping without broadening specific execute requests. Do not replace rights from an applicable NT ACE with a POSIX ACL entry. The POSIX ACL is only a fallback when no user, Everyone, or Authenticated Users ACE applies; otherwise it can incorrectly broaden the stored DACL. This fixes smb2.maximum_allowed.maximum_allowed. Signed-off-by: Namjae Jeon Stable-dep-of: b5ec6c462aab ("ksmbd: fix tree connection use-after-free in smb2_tree_connect()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fa251df1110e5b32872131c87b4a0f25804655f Author: Leo Martins Date: Thu Sep 10 10:54:24 2026 -0400 btrfs: abort transaction before releasing tree_log_mutex on commit failure [ Upstream commit 529c01c3dc0d322c103611c35b01d71ea04562b2 ] When transaction metadata writeout fails in btrfs_commit_transaction(), the current code only logs the error, drops tree_log_mutex and then goes through cleanup_transaction(), which aborts the transaction and records the fs error. That is too late for the tree log side. A log sync can already be waiting on tree_log_mutex, because the committing transaction is moved to TRANS_STATE_UNBLOCKED while that mutex is held, which lets fsyncs join the next transaction and queue up in btrfs_sync_log(). Once the failed commit drops tree_log_mutex, such a log sync acquires it, sees BTRFS_FS_ERROR() still clear, and writes super_for_commit. That superblock holds the roots prepared for the transaction that has just failed to write out its metadata, so it can point at tree blocks that never reached the disk, and the next mount fails with a parent transid mismatch. Commit 165ea85f1483 ("btrfs: do not write supers if we have an fs error") fixed this class of problem by making btrfs_sync_log() check for an fs error right after taking tree_log_mutex. That check only works if the commit path publishes the fs error before it releases the same mutex, and commit 68d4ece9c30e ("btrfs: don't call btrfs_handle_fs_error() in btrfs_commit_transaction()") removed the only thing that did so. Restore the ordering by aborting the transaction while tree_log_mutex is still held. We have a transaction handle here, so this does not need to bring back the btrfs_handle_fs_error() call: __btrfs_abort_transaction() records the fs error itself, which is all btrfs_sync_log() looks at, and the error message put in its place is kept. This is what commit 3810ab40afa5 ("btrfs: abort transaction on error in write_all_supers()") already does for the next call in this function. This is reproducible on an unmodified kernel by failing the first couple of bios of a transaction commit with fail_make_request while a concurrent fsync workload keeps log syncs queued on tree_log_mutex. Fixes: 68d4ece9c30e ("btrfs: don't call btrfs_handle_fs_error() in btrfs_commit_transaction()") CC: stable@vger.kernel.org # 7.0+ Reviewed-by: Boris Burkov Reviewed-by: jlayton@meta.com Signed-off-by: Leo Martins Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Signed-off-by: David Sterba [ adjusted error-message context to retain `%d` with `ret` instead of `%pe` with `ERR_PTR(ret)`. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9cf8c4c60020bc32214a3b0720fc6ec57ba092f3 Author: Masami Hiramatsu (Google) Date: Thu Sep 10 07:47:01 2026 -0400 tracing/probes: Fix BTF kflag check for anonymous struct member access [ Upstream commit 47e93045a2db80d24f5fef65adecc6b2b32efa23 ] btf_find_struct_member() traverses into nested anonymous structures and unions to find a struct member. However, get_bitoffset_of_field() in trace_probe.c checked btf_type_kflag(type) using the outer parent type instead of the actual anonymous structure/union that directly contains the found member. If the parent structure and anonymous structure have mismatched kflags (e.g., the parent has kflag=0 while the anonymous structure has kflag=1 because it contains bitfields), the bitfield size encoded in the upper 8 bits of member->offset is erroneously treated as part of the byte/bit offset, corrupting the resolved offset and failing to set last_bitsize. Similarly, btf_find_struct_member() pushed anonymous member offsets onto anon_stack without masking BTF_MEMBER_BIT_OFFSET() when kflag is set. To fix this problem, update btf_find_struct_member() to return actual containing structure/union type via member_type, use appropriate __btf_member_bit_offset() to get bit offset, and use member_type for btf_type_kflag() in get_bitoffset_of_field(). Link: https://lore.kernel.org/all/178827250904.123716.17452648791331881284.stgit@devnote2/ Fixes: c440adfbe302 ("tracing/probes: Support BTF based data structure field access") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260822095110.0772E1F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt [ applied changes to parse_btf_field() because get_bitoffset_of_field() is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8f5e4ab11e095d5101a9a0fe450900c48c9ebb5 Author: Martin Kaiser Date: Thu Sep 10 07:47:00 2026 -0400 tracing/probes: ignore id update from btf_type_skip_modifiers [ Upstream commit 823b37855829bc328d46102a56e4d0b2f7a3d0d1 ] We can pass NULL as id pointer to btf_type_skip_modifiers if we do not need the id of the returned btf_type. Link: https://lore.kernel.org/all/20260623132937.3494895-1-martin@kaiser.cx/ Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 47e93045a2db ("tracing/probes: Fix BTF kflag check for anonymous struct member access") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 15f78eea8c4bec58cabda383d8725c7d50b20a77 Author: Muhammad Bilal Date: Wed Sep 9 22:29:32 2026 -0400 staging: sm750fb: fix mono image source stride mismatch in lynxfb_ops_imageblit() [ Upstream commit cc7cd2a9228175c975f62ad56ed7c767701cb4fa ] sm750_hw_imageblit() advances its monochrome source pointer by src_delta per scanline, and computes the correct rounded-up stride internally as: bytes_per_scan = (width + start_bit + 7) / 8; Its only caller, lynxfb_ops_imageblit(), instead passed src_delta as image->width >> 3. For widths not a multiple of 8 this under-counted the stride, so the source pointer fell further behind the real per-scanline layout on every line, corrupting the rendered image. Rather than just fixing the caller's calculation, remove src_delta as a parameter entirely and have sm750_hw_imageblit() advance by the bytes_per_scan it already computes for itself. There has only ever been one caller, and that caller was passing an out-of-sync derivative of the same width/start_bit values sm750_hw_imageblit() already has, so keeping stride as a separate parameter served no purpose beyond letting the two calculations drift apart, which is exactly what happened here. Rounding up, rather than down, is the direction consistent with the rest of the fbdev core: struct fb_image mono bitmap data (the same image->data this driver receives) is walked elsewhere with byte strides derived from a ceiling division of width by 8. The generic mono bit iterator in drivers/video/fbdev/core/fb_imageblit.h advances scanlines with "iter->data += BITS_TO_BYTES(iter->width)", and BITS_TO_BYTES() (include/linux/bitops.h) is a ceiling division. sm750_hw_imageblit()'s own "(width + start_bit + 7) / 8" is that same ceiling division with an added start_bit offset, so the caller's ">> 3" (floor) was the one calculation out of step with how this data layout is handled everywhere else. Found by code review of sm750_hw_imageblit()'s internal stride calculation against what its only caller was passing in, and confirmed with a clean -Werror build. I do not have this hardware, so this has not been exercised at runtime on real sm750 silicon. Fixes: 81dee67e215b2 ("staging: sm750fb: add sm750 to staging") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260901113031.161610-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman [ adjusted sm750_accel.h context to accommodate the branch’s older CamelCase parameter names. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit daed571f85fe3e2b3668b29feb80712a255302ea Author: Jan Kara Date: Wed Sep 9 21:17:15 2026 -0400 udf: Fix data loss when converting inline inodes to out of line [ Upstream commit 62333e480d12ab186f89fe2725b372d12f72d5eb ] When udf_expand_file_adinicb() converts file from inline format to out of line, we use filemap_fdatawrite() to writeout the data to the new blocks. However since 36580ed08776 ("udf: Do not allocate blocks on page writeback") the writeback actually doesn't allocate the new block and the folio dirty bit is just silently cleared. Thus unless the file is written to after the conversion (as it can easily happen in case of truncate up), the data is just lost. Fix the problem by explicitely allocating the block underlying the data before starting writeback. Fixes: 36580ed08776 ("udf: Do not allocate blocks on page writeback") CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260730104232.4086759-4-jack@suse.cz Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d347c971aaddc65b1601e1bdeba127c383146eee Author: Jan Kara Date: Wed Sep 9 21:17:14 2026 -0400 udf: Move udf_map_block() up [ Upstream commit 97e9d759a4193eabe4d8b6ecac093aac664c16e3 ] Move udf_map_block() in the file to avoid forward declarations. Link: https://patch.msgid.link/20260730104232.4086759-3-jack@suse.cz Signed-off-by: Jan Kara Stable-dep-of: 62333e480d12 ("udf: Fix data loss when converting inline inodes to out of line") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4822a030929e0e77aa380722dc42e3e4c9edd346 Author: Bryam Vargas Date: Wed Sep 9 20:18:23 2026 -0400 dm-pcache: validate the persisted dirty_tail chain at load [ Upstream commit 58d620ee9e01d4bdbceaf2ae1450d307a2a9d58b ] The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka [ replaced the unavailable cache_seg_id_valid() helper with an equivalent bounds check against cache->cache_info.n_segs ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 150e71808d3715a0deefbb189c780d03fdbdc735 Author: Adrian Hunter Date: Wed Sep 9 20:18:16 2026 -0400 i3c: master: Do not treat master device as a duplicate target [ Upstream commit 4dc1b3eeba7991905a5b5b8129ebea51be7d87b7 ] i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Acked-by: Mukesh Savaliya Link: https://patch.msgid.link/20260807145638.168865-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni [ adjusted the duplicate-device comparison to match the older branch’s PID handling without nonzero-PID checks. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 50034d8d0f797c3a7a599f750a7d3e792e80dea5 Author: Adrian Hunter Date: Wed Sep 9 20:18:02 2026 -0400 i3c: master: Fix use-after-free of master->this [ Upstream commit feb0ed76601f3c2f91f08688c5a7d8b9d382f720 ] sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device. 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/20260807145638.168865-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni [ retained of_node_put(dev->of_node) instead of upstream’s fwnode_handle_put(dev->fwnode). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4bf8af5e7d7db4c5e179e15017da55857761ac4 Author: Bryam Vargas Date: Wed Sep 9 16:50:51 2026 -0400 dm-pcache: validate seg_id fields from persistent memory [ Upstream commit 90c990a68460d7b5720e5634cf650eccdf0f4098 ] cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka [ adjusted cache_replay() context to preserve the existing hop-limit check before segment-ID validation ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9dc73c51ed3ee965c3ddb0ac31cf5c3eea68fa0c Author: Adrian Hunter Date: Wed Sep 9 16:46:01 2026 -0400 i3c: master: Fix recursive locking during device registration [ Upstream commit 456f832e5fc26fbfd3b8200fd4553eee520cc377 ] i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device. 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/20260807145638.168865-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ecf17bf5fe8da51a6e3fc9e03a76898fcc5c6cf Author: Adrian Hunter Date: Wed Sep 9 16:46:00 2026 -0400 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 Stable-dep-of: 456f832e5fc2 ("i3c: master: Fix recursive locking during device registration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 96b066831f6e03555f7f8de4c9bf3cbc491830de Author: SJ Park Date: Wed Sep 9 17:52:12 2026 -0700 mm/damon/core: skip aging from repeated aggressive merging [ Upstream commit 0250dbe08c730d003ef9f484da56ae09a1ea0c4c ] The number of DAMON regions could temporarily exceed the user-defined maximum number of regions limit for corner cases. For example, users could lower the limit via runtime parameters update. For such a case, kdamond_merge_regions() repeats merging regions in the case doubling the merge threshold. The repeated merge operation could update the age of regions multiple times. This corrupts the monitoring results. Fix the issue by asking the merge operation to skip aging for the corner case. The user impact is degradation of the monitoring quality. The impact should be mild, since the degradation is only temporal, and it is not common to happen in realistic setups. The issue was discovered [1,2] by Sashiko. Link: https://lore.kernel.org/20260712165432.87609-1-sj@kernel.org Link: https://lore.kernel.org/20260621203548.10718-1-sj@kernel.org [1] Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [2] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10 Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e54602d9e38db8573f2097d60c7ea8be0a5af1fa Author: Sven Eckelmann Date: Wed Sep 9 20:23:02 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 f68038c77a2f38c09c7e2e4f7fa1f4e246fdf2c9 Author: Sven Eckelmann Date: Wed Sep 9 20:20:01 2026 +0200 batman-adv: dat: atomically update mac addresses commit e6de568d3eda3e3c01c868fabd7a9535d5ee4a73 upstream. When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 2f1dfbe18507 ("batman-adv: Distributed ARP Table - implement local storage") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit fe3772ea9d269890e06d6102e67a83c9b29fb936 Author: Akhmed Zhitaev Date: Wed Sep 9 20:25:20 2026 +0500 drm/amd/display: Scale custom brightness curve from full range [ Upstream commit 6fd83a1c2cdea48c396f600795217fbdfb8124f6 ] Custom brightness curves use an 8-bit input signal. After exporting the full PWM range to userspace, the curve normalizer still divides requests by the physical PWM span. On panels with a nonzero minimum PWM level, this can produce a curve input greater than 255 and send an invalid backlight level to DC. Scale the userspace [0..max] range to the curve's [0..255] range instead. This retains the full advertised range and keeps the reverse readback conversion unchanged. Fixes: 8dbd72cb7900 ("drm/amd/display: Export full brightness range to userspace") Cc: stable@vger.kernel.org Signed-off-by: Akhmed Zhitaev Reviewed-by: Mario Limonciello (AMD) (Move to amdgpu_dm_backlight.c) Link: https://patch.msgid.link/20260813170959.22073-1-zhitaevakh@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin