Author: Christian Brauner <[email protected]> Date: Fri Oct 9 23:51:52 2026 +0200 afs: free the super info after a grace period commit 59e483739f2fd14327ece3f60c4995d060ca46b7 upstream. afs_atcell_get_link() resolves the @cell and .@cell symlinks of a dynamic root in rcu pathwalk mode. Before it looks at the dentry it gets the afs_net through afs_i2net(), which reads ->net_ns from the afs_super_info in sb->s_fs_info. The @cell dentries are kept around when unused and the dynamic root has no ->d_revalidate(), so a lookup that finds @cell in the dcache gets to ->get_link() in rcu mode. afs_kill_super() frees the afs_super_info with a plain kfree() in afs_destroy_sbi(). Right now a pathwalk can't still be in afs_atcell_get_link() at that point, but only by accident. umount(2) waits for a grace period in namespace_unlock() before it drops the mount. And a mount whose last reference goes away elsewhere, like the chdir out of a lazily unmounted directory, still gets a grace period from bdi_unregister(). afs_fill_super() sets up a private bdi, so generic_shutdown_super() unregisters it from kill_anon_super() and bdi_remove_from_list() waits in synchronize_rcu_expedited() before afs_destroy_sbi() runs. That grace period protects the rcu readers of bdi_list in the writeback code. It has nothing to do with pathwalk. Don't rely on it and free the afs_super_info after a grace period. Fixes: 30bca65bbbae ("afs: Make /afs/@cell and /afs/.@cell symlinks") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:48 2026 +0900 ASoC: cs42l52: Fix the NG Type Switch bit [ Upstream commit 8b08b98796d2da103f2432550c14a7c687e72080 ] The NG Type Switch enum selects between "Apply Specific" and "Apply All", which is the NGALL bit. The datasheet puts NGALL at bit 7 of the Noise Gate Control register. The enum uses bit 6, which is NG, the noise gate enable owned by the NG Enable Switch. cs42l52.h names it CS42L52_NG_ENABLE_SHIFT. cs42l56 has the same Noise Gate register and puts its NG All Switch at bit 7. So changing the noise gate type turns the noise gate on or off, and NGALL cannot be set. Use bit 7. Fixes: dfe0f98b8d2e ("ASoC: Add support for CS42L52 Codec") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L52_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:47 2026 +0900 ASoC: cs42l56: Put the Limiter Cushion control on the limiter register [ Upstream commit 203436d2aeb7093290459e344e1912a418a6ebfd ] The Limiter Cushion control writes bits 4:2 of the ALC Thresholds register. Those bits are ALCMIN, which the ALC MIN control owns. The datasheet puts CUSH at bits 4:2 of the Limit Thresholds Control register, next to LMAX, which the Limiter MAX control already uses. So setting the limiter cushion changes the ALC minimum threshold, and the cushion itself cannot be set. Use CS42L56_LIM_THRESHOLD_CTL. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L56_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Tiraspolsky <[email protected]> Date: Sat Oct 10 03:37:53 2026 -0700 ASoC: Intel: avs: Reset the stream unless it is already prepared [ Upstream commit f6be9f558a83fe30a03bd3adae461c821a0cef8c ] Commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") resets the HDA stream when ->prepare() is called in the XRUN state. User space does not always recover that way. PipeWire's ALSA backend recovers from an underrun with snd_pcm_drop(), snd_pcm_prepare() and a new start, so ->prepare() runs in the SETUP state, hdac_stream->prepared is still set and the reset is skipped. Every recovery attempt then fails the same way: spa.alsa: hw:avsmax98927,1p: snd_pcm_avail after recover: Broken pipe On a Google Pixelbook (Kaby Lake, max98927 speakers) this happens after an occasional underrun during normal playback and silences the speakers for one to four minutes, until the PCM is closed. It can be provoked by stopping PipeWire with SIGSTOP for 0.5 s during playback: in one run that single underrun led to 1297 failed recoveries over two minutes, until the sink was suspended. A plain alsa-lib program that recovers with snd_pcm_drop() and snd_pcm_prepare() hits the same loop, while snd_pcm_prepare() straight from XRUN recovers at once. Skip the reset only when the stream is already PREPARED, the repeated ->prepare() case the check exists for, and reset it otherwise. With this change both kinds of recovery succeed with a single restart. Fixes: cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Sergey Tiraspolsky <[email protected]> Acked-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:50 2026 +0900 ASoC: max98371: Fix the Speaker DHT Min Volume bits [ Upstream commit f7934340c56a84fc1b246ebf6b2e806d775f3b54 ] Register 0x31 holds two 4-bit fields. The datasheet puts SPK_GAIN_MIN at bits 7:4 and DHT_VROT_PNT at bits 3:0. The Speaker DHT Min Volume and Speaker DHT Rotation Volume controls both use bits 3:0. So setting the minimum speaker gain changes the DHT rotation point, and SPK_GAIN_MIN cannot be set. Move Speaker DHT Min Volume to bits 7:4. Fixes: ca2cd6bc6663 ("ASoC: Add max98371 codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:52 2026 +0900 ASoC: nau8822: Fix the 128x oversampling switch bits [ Upstream commit 4db45fc1da3d62d0fa6e8f1e457ae92e8741ed07 ] The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. The NAU8822 datasheet register map puts DACOS and ADCOS at bit 3 of those registers. In R14, bit 5 is inside HPF[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 1e3cb6c321be ("ASoC: nau8822: new codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:49 2026 +0900 ASoC: pcm3168a: Fix the DAC zero flag polarity bit [ Upstream commit b26edc925c1cfa0184cd270ed81d4833db045ce0 ] The DAC Zero Flag Polarity enum uses PCM3168A_DAC_ATSPDA_SHIFT, which is bit 6 of register 70. That bit is ATSPDA, the attenuation speed, which the DAC Volume Rate Multiplier enum already owns. The datasheet puts ZREV, the zero flag polarity, at bit 0. The header defines PCM3168A_DAC_ZREV_SHIFT for it, but nothing uses it. So changing the zero flag polarity changes the attenuation speed, and ZREV cannot be set. Use PCM3168A_DAC_ZREV_SHIFT. Fixes: a9b17a638af5 ("ASoC: pcm3168a: Add driver for pcm3168a codec") Link: https://www.ti.com/lit/ds/symlink/pcm3168a.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Reviewed-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Oct 21 11:42:34 2026 -0400 ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture [ Upstream commit 746de48c3a250f0c264105dcbfcdf0c5001e970b ] When ch_count is smaller than blob->alh_cfg.device_count (e.g. a mono capture stream, such as a SmartMic, aggregated across multiple SDW links), step = ch_count / blob->alh_cfg.device_count truncates to 0. The subsequent GENMASK(step - 1, 0) then underflows step - 1 (u32) to UINT_MAX, causing GENMASK()'s internal shift to use an out-of-bounds exponent: UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2363:13 shift exponent 18446744069414584384 is too large for 64-bit type 'long unsigned int' Treat ch_count < device_count the same way as the existing "channels equal to output reference channels" case: apply the same ch_mask to every aggregated device instead of trying to split channels that can't be evenly divided. Fixes: 0390a102cc18 ("ASoC: SOF: ipc4-topology: use different channel mask for each sdw amp feedback") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> [ sashal: used a standalone condition because the playback-specific channel check is absent ] Signed-off-by: Sasha Levin <[email protected]>
Author: Avi Weiss <[email protected]> Date: Sun Oct 11 06:54:59 2026 +0300 ASoC: stm32: spdifrx: fix synchronization state check [ Upstream commit 0936bbd35a247665c64886135835faa3c3f4f29f ] The interrupt handler uses a logical AND to check whether SPDIFRX was in the SYNC state before clearing errors. Since both SYNC (1) and ENABLE (3) are nonzero, this also treats ENABLE as SYNC (and any other non-zero value that might be added). The logical && basically just converts this to check for != 0. So errors occurring while SPDIFRX is enabled cause the driver to retry synch instead of disconnecting the PCM stream. Fix is to change the logical && to equality (==) and only retry when exactly in sync state. Fixes: 0c93c291321f2 ("ASoC: stm32: spdifrx: retry synchronization in sync state") Signed-off-by: Avi Weiss <[email protected]> Reviewed-by: Olivier Moysan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HyeongJun An <[email protected]> Date: Thu Oct 8 22:09:51 2026 +0900 ASoC: wm8978: Fix the 128x oversampling switch bits [ Upstream commit d0567ca9a2faa33efbe5ae84ef7b86423a93bffd ] The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. Table 66 of the WM8978 datasheet puts DACOSR128 and ADCOSR128 at bit 3 of those registers. In R14, bit 5 is inside HPFCUT[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 823dba519122 ("ASoC: Fix broken bitfield definitions in WM8978") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Weiming Shi <[email protected]> Date: Sun Sep 6 19:01:53 2026 +0800 asymmetric_keys: reject trust keys without IDs commit 9695df3b1db4ac4534274d38ee16e3b9b0bf910e upstream. The PKCS#8 parser deliberately leaves the asym_key_ids payload slot empty. key_or_keyring_common() unconditionally dereferences that slot when a PKCS#8 key is supplied to a key_or_keyring restriction. Both the plain and :chain forms reach this branch, allowing an unprivileged caller to trigger a NULL pointer dereference through KEYCTL_RESTRICT_KEYRING followed by add_key(). Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:key_or_keyring_common (crypto/asymmetric_keys/restrict.c:205 crypto/asymmetric_keys/restrict.c:279) Call Trace: <TASK> __key_create_or_update (security/keys/key.c:884) key_create_or_update (security/keys/key.c:1021) __do_sys_add_key (security/keys/keyctl.c:134) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Kernel panic - not syncing: Fatal exception Reject an asymmetric restriction key without key IDs. A PKCS#8 private key cannot identify the signer of a candidate certificate and is not a valid trust anchor. Fixes: 3c58b2362ba8 ("KEYS: Implement PKCS#8 RSA Private Key parser [ver #2]") Cc: [email protected] Reported-by: Xiang Mei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sung Byeongchan <[email protected]> Date: Thu Oct 8 02:35:42 2026 +0900 autofs: ignore notification errors from a replaced pipe commit 65676cd4203c0e41a94caf54080a7f0a95434bda upstream. autofs_notify_daemon() takes a reference to the current notification pipe under wq_mutex, then drops the mutex before writing the request. The write can block while the daemon enters catatonic mode and installs a replacement pipe. If the old pipe's reader is then closed, the delayed write returns -EPIPE and the generic error path enters catatonic mode again. That transition acts on the current superblock state, closes the replacement pipe, and releases the new daemon generation's wait queues. Only enter catatonic mode when the pipe which failed is still the current pipe. Factor the already-locked transition so the identity check and state change are atomic with respect to another replacement. This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest. An unprivileged UID 65534 lookup filled the old packet pipe before a normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe received HUP and both a pending victim lookup and a later lookup failed with ENOENT in two out of two fresh-mount runs. With this change, the new pipe remained active, received an intact 304-byte request, and both victim lookups completed in two out of two runs. Normal lookup and restart-without-a-blocked-writer controls passed. No KASAN, oops, refcount, or lock diagnostic was observed. A source reproducer and complete local logs are available privately on request. The demonstrated impact is limited to denial of a shared autofs service during a legitimate daemon restart. No memory corruption, information leak, privilege escalation, or code execution primitive was observed. Fixes: 8d7b48e0bc5fa ("autofs4: add miscellaneous device for ioctls") Cc: [email protected] Signed-off-by: Sung Byeongchan <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Ian Kent <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sun Sep 13 11:47:43 2026 +0200 ax25: bound REJ-driven fast retransmits with the existing N2 counter REJ deliberately bypasses the T1/N2 backoff to trigger an immediate go-back-N retransmit -- that is the whole point of REJ, fast recovery from a single lost or out-of-order frame. But unlike every other recovery path in this same state machine (T1 timeout, state 4 enquiry/DM, state 1/2 SABM retries), the REJ case in ax25_std_state3_machine() never touches n2count, so it has no bound. If something keeps corrupting or reordering every retransmitted burst -- lossy RF, or packet reordering over a UDP-based transport such as axudp -- each attempt draws an immediate fresh REJ and the link retransmits at wire/CPU speed indefinitely, a "machine-gun" storm that never reaches the N2 give-up already relied on everywhere else in this file. Reported independently twice: Chris Maness (KQ6UP) on a plain AX.25 link with no ROSE involved at all, and observed live on a ROSE/FPAC White Pages link (f6bvp-8<->f6bvp-10, same LAN, so plain network reordering over the Internet is not the trigger there -- likely lossy retransmission of the same PDU) reaching ~5900 pkt/s. Both hit the same code path since ax25_std_in.c is shared regardless of what rides on top of AX.25. Count consecutive REJ-driven fast retransmits the same way a T1 timeout already does in this state, and once N2 of them have failed to get an in-sequence frame through, fall back to the paced state 4 enquiry -- which will genuinely disconnect after N2 further tries if the link stays bad, exactly like every other recovery path already does. A single frame accepted in sequence resets the counter, so an isolated REJ during otherwise healthy traffic never gets close to N2. Deployed on three Raspberry Pi nodes (f6bvp-12, f6bvp-8, f6bvp-10) since 2026-09-13, running live production AX.25/ROSE/NET-ROM traffic since, with no recurrence of the machine-gun storm and no other AX.25 regression observed. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit a3aa611e37d4345ebcc98c847dedaf4bcf23c7ee) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 25 14:10:34 2026 +0200 ax25: check frame length in ax25_decode() and ax25_rx_iframe() Two more reads on the receive path assume bytes that a short frame does not have: - On a connection set up with SABME (modulo 128), ax25_decode() reads a two-byte control field for I and S frames (frame[1]) without checking that the second byte is there. - ax25_rx_iframe() reads the PID byte of an I frame without checking that anything is left after the control field, so an I frame made of its control field alone is dispatched on a byte past its end. The same function also receives reassembled segments. Return AX25_ILLEGAL from ax25_decode() when the control field is incomplete, which the state machines already handle as a malformed frame, and drop an I frame that has no PID byte. The first check in ax25_decode() also covers an empty frame on its own, independently of the length check proposed for ax25_rcv(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 5b010290c0e627fd09b92eb8d690f0726d7cfe7c) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Tue Oct 6 01:28:14 2026 +0200 ax25: don't accept frames on a device that is going down ax25_rcv() creates a connection on an incoming SABM, for a listening socket or for a callsign registered by ROSE or NET/ROM. Like the ones made by ax25_send_frame(), it holds no reference on the ax25_dev and relies on ax25_kill_by_device() to detach it before the ax25_dev is freed. If it is added to ax25_list after ax25_kill_by_device() has walked the list, it is left pointing to a freed ax25_dev. ax25_rcv() is called from the packet type handler, under rcu_read_lock(), and ax25_kill_by_device() now clears device_up and waits for the RCU readers before its walk. Drop the frame when device_up is clear: a frame that gets past the test is fully processed before the walk starts, and none is processed behind it. The window is much smaller than for ax25_send_frame(): the core already drops what is received on a device that is no longer running, so only a frame that was queued before the device was stopped and is processed late can hit it. I could not exercise it. The change was checked for regressions only: incoming connections still work in the ROSE tests of the previous patch, where every AX.25 link is opened by an incoming SABM on one side. Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 748551f72b27325043eafe969311b15ae1eb0c7c) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Oct 2 15:04:48 2026 +0200 ax25: don't create two connections for the same link in ax25_send_frame() ax25_send_frame() looks for an existing connection with ax25_find_cb() and, when there is none, creates one and adds it to the list. The lookup and the insertion are not done under the same lock, so two callers sending to a neighbour at the same time both find nothing and both create a control block: the same link ends up with several connections, each sending its own SABM, and the frames queued on the ones that lose are never delivered. ROSE and NET/ROM call ax25_send_frame() for every frame they send to a neighbour, from process context and from softirq context, so this happens as soon as several circuits start together on a link that is not established yet. Add ax25_cb_add_unique(), which searches the list and inserts the new control block under ax25_list_lock, and returns the existing connection when another sender got there first; ax25_send_frame() then drops its own control block and queues the frame on that connection. The SABM is only sent once the control block is known to be the one in the list. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, eight ROSE calls started at the same instant with no AX.25 connection up: before, /proc/net/ax25 shows four connections for the same pair of callsigns on three runs out of three; after, one. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 2649f91b6dd2c48348975d03e8f94d8e6a09cf71) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Oct 2 14:37:30 2026 +0200 ax25: don't free an incoming SABM skb left on the listener's queue When a SABM comes in for a listening socket, ax25_rcv() creates the new socket, puts the skb on the listener's receive queue and only then allocates the digipeater path. If that allocation fails, the skb is freed with kfree_skb() while it is still linked on the queue, and the accept backlog count taken by sk_acceptq_added() is never given back. The next accept() or the close of the listener then walks a queue that contains a freed skb. Allocate the path before the skb is queued, so that the error path only has to free an skb nobody else knows about and to destroy the new socket. The later allocation remains for a connection that has no listening socket. Only reachable when the atomic allocation fails for a call that comes through digipeaters. Regression tested in QEMU (6.12.94 with lockdep and KASAN): 14 incoming connections to a listening socket, each accepted, served and closed, before and after; no report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 2d67e8e9f3d627327114fb946c3a28ef72becb2d) Signed-off-by: Sasha Levin <[email protected]>
Author: Ashutosh Desai <[email protected]> Date: Tue Apr 21 05:48:58 2026 +0000 ax25: fix OOB read after address header strip in ax25_rcv() A crafted AX.25 frame with a valid address header but no control byte causes skb->len to reach zero after skb_pull() strips the header. The subsequent reads of skb->data[0] (control) and skb->data[1] (PID) are then out of bounds. Linearize the skb after confirming the device is an AX.25 interface. Guard with skb->len < 1 after the pull - one byte suffices for LAPB control frames which have no PID byte. Add a separate skb->len < 2 check inside the UI branch before accessing the PID byte. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Ashutosh Desai <[email protected]> [F6BVP: v5 as posted on netdev; the author withdrew it only because the subsystem was being removed from the kernel that day. Applied unchanged.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit e653f27001ca2a31a445ee20d9f90be65b85d7e3) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Tue Oct 6 01:28:14 2026 +0200 ax25: read the connection's ax25_dev only once when walking ax25_list ax25_kill_by_device() detaches a connection from a device that goes down by setting s->ax25_dev to NULL. It does so after it has dropped ax25_list_lock, while the connection is still on ax25_list. __ax25_find_cb() and ax25_find_listener() walk that list and test s->ax25_dev against NULL before they dereference it, but they load the pointer a second time for the dereference. ax25_send_to_raw() dereferences it without any test. If ax25_kill_by_device() clears the pointer in between, the walker dereferences NULL: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ax25_find_cb+0x121/0x330 [ax25] ax25_send_frame+0xdc/0x980 [ax25] rose_send_frame+0xce/0x270 [rose] rose_transmit_restart_request+0x1b3/0x260 [rose] rose_transmit_link+0x31d/0x560 [rose] rose_write_internal+0x3ab/0x15b0 [rose] rose_release+0x2b2/0x4b0 [rose] Load the pointer once in the three walkers and use that value, and add the missing NULL test to ax25_send_to_raw(). The ax25_dev itself cannot go away under the walker: ax25_kill_by_device() has to take ax25_list_lock again, in ax25_cb_del(), before the device teardown gets as far as freeing it. The oops above was obtained on 6.12.94 with KASAN, after 382 seconds of the syzbot C reproducer of the ax25_find_cb() use-after-free report, with the interface brought up again in a loop, while testing an earlier version of the next patch. With this series the same test runs for 600 seconds without an oops. Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 3696f3cf8690e335a2cc7e8103f018bc205de738) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Tue Oct 6 13:20:51 2026 +0200 ax25: send a private copy of each I frame ax25_kick() keeps every I frame on the ack queue until it is acknowledged and hands a clone of it to the device. After a REJ or a T1 timeout the frame goes back to the write queue and ax25_kick() clones it again. A clone shares its data with the original, so ax25_send_iframe() and ax25_transmit_buffer() write the control field and the address header of the new clone in the very bytes used by the previous one. If the previous clone is still waiting in the device queue, its control field is rewritten there: it leaves with the N(R) current at the time of the retransmission, not the one it was sent with. Frames queued behind it, an RR for instance, were built in between with a lower N(R). The peer then receives an N(R) lower than one it has already been given. ax25_validate_nr() rejects it and ax25_std_nr_error_recovery() resets the link with a SABM, in the middle of a transfer. The layers above pay for it: on a ROSE circuit, the frames replayed after the reset carry stale sequence numbers and the circuit is reset as well, with loss of data. Hand a private copy to the device instead. The frames are small (256 bytes of data by default) and the link is slow, the extra copy is not measurable. Found on a test bench: two virtual machines with four CPUs each, a 6.12.94 kernel with KASAN and lockdep, one ROSE circuit over an AX.25 link on a serial line (mkiss), 192 messages each way in bursts of 24, and three REJ frames injected by one side. Instrumentation showed that frames reached the driver in the order they were given to dev_queue_xmit(), that V(R) never went backwards on the sender, and that the driver nevertheless saw frames whose N(R) was lower than the one before. Counting, on the receiver, the frames whose N(R) is lower than the previous one: - this code plus the two pending AX.25 fixes used on the bench (REJ guard, requeue on re-establishment): 4 runs, 13 such frames, 4 link resets; with this patch: 6 runs, none, no link reset; - the same with the transmit serialisation patches for AX.25 and ROSE on top: link resets in most runs before; with this patch: 6 runs, none, no link reset, no ROSE reset, 192/192 messages both ways in every run. Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 1b464137f3173fadf81a7a1bf4a9584ebaf72c7b) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu Oct 8 15:09:05 2026 +0200 ax25: send unacknowledged I frames again when a link is re-established When a connection goes back through state 1 from state 3 or 4 (invalid N(R), FRMR, illegal frame), the UA that re-establishes it resets V(S), V(A) and V(R) but leaves the I frames that were waiting for their acknowledgment in the ack queue. From then on every acknowledgment frees the frame at the head of the queue, an old one, instead of the one it is for, so the queue keeps that many frames too many for ever: - they stay charged to the socket that sent them, whose send memory is never given back; - they are sent again by the next go-back-N, long after the event, and the peer gets duplicates; - they were not sent again when the link came back, so the layer above lost them. Seen on a live ROSE node: an AX.25 connection in state 3 with V(S) == V(A), empty write queue and 18 frames in its ack queue, and the ROSE sockets using it showing a send queue that never drains. Requeue those frames when the UA is received, as is already done when the peer resets the link with a SABM in state 3 or 4. Same change in the DAMA slave state machine. Like that existing path, this can send again a frame that the peer had received just before the reset: AX.25 has no way to know. The layer above sees a duplicate instead of a silent loss. ROSE drops an exact duplicate, but resets the circuit when the replayed frame carries an N(R) that is no longer valid. On the nodes below those resets came with link re-establishments caused by a late N(R), which "ax25: send a private copy of each I frame" removes: with both patches the node that is instrumented saw no re-establishment and no reset in 49 hours, against five resets in the 47 hours before. Tested in QEMU (6.12.94 with lockdep and KASAN), two nodes over a mkiss serial link, one ROSE circuit, 40 messages 150 ms apart, the link forced through state 1 three times by an injected FRMR. Before: 6 runs of 6 deliver 40/40 and leave one frame in the ack queue, the ROSE socket keeps 960 bytes of send memory. After: 6 of 6 deliver 40/40 and the send memory goes back to zero. No lockdep, KASAN or refcount report. On four production nodes since 3 October 2026, six since 6 October. A relay node that had 18 to 20 such frames on one link is sampled every hour: 124 samples and 1301 link states in five days, none with a frame left in an ack queue. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 7b22827cb729de19ccba284ebaff3eeee21d4f11) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu Oct 1 14:07:43 2026 +0200 ax25: serialise the transmission of I frames on a connection ax25_kick() takes frames off the write queue, numbers them from V(S) and moves them to the ack queue, with no lock. It is called from process context by the senders (ax25_output()) and from softirq context by the receive path and the timers. A connection used by ROSE or NET/ROM carries several circuits, so ax25_output() can run for the same connection on two CPUs at once, and against the receive path. Both then read the same V(S) and two different I frames are sent under the same N(S). The peer keeps the first and rejects the second; the go-back-N that follows resends whatever the ack queue holds for that number, and one of the two frames is never sent again while the AX.25 counters look consistent on both sides. The layer above sees a hole: a ROSE circuit receives its frames out of sequence, ignores them, and stays frozen with its window full. Seen on a live ROSE node relaying several circuits over one AX.25 link: fm F6BVP-9 to F6BVP-13 ctl I55^ pid=1(X.25) len 254 LCI 030 DATA S2 fm F6BVP-9 to F6BVP-13 ctl I55^ pid=1(X.25) len 254 LCI 02E DATA S2 fm F6BVP-13 to F6BVP-9 ctl REJ6v Add a lock to the ax25_cb covering V(S), V(A) and the write and ack queues, taken in ax25_kick(), ax25_frames_acked() and ax25_requeue_frames(). The frames are not sent with the lock held, since ax25_transmit_buffer() may end up in ax25_disconnect(): ax25_kick() puts the numbered frames on a transmit queue which is emptied, in order, by one context at a time once the lock is dropped. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, four ROSE circuits each sending 400 numbered messages at the same time: before, every circuit freezes and 300 to 600 of the 1600 messages get through; after, no sender is blocked and more than 1500 get through (the ROSE side needs "rose: process received frames and send with the socket locked" for the rest: 1600/1600 in order on six runs out of six with both). No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") [F6BVP: v2: in ax25_frames_acked(), loop on what skb_dequeue() returns instead of on skb_peek(): ax25_clear_queues() purges the ack queue without ax25->lock, so skb_dequeue() could return NULL and __skb_queue_tail() dereference it in softirq context (reported by Sasha Levin). Same fix submitted to mod-orphan.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 3f42b974059565c9e60229a9ff1ca21d10334671) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Tue Oct 6 01:28:14 2026 +0200 ax25: wait for ax25_send_frame() before detaching the connections of a device A connection created by ax25_send_frame(), for ROSE, NET/ROM or IP over AX.25, points to the ax25_dev of its device without holding a reference on it. It relies on ax25_kill_by_device() to detach it when the device goes down, before ax25_dev_device_down() frees the ax25_dev. On NETDEV_DOWN the two run one after the other. In between, the ax25_dev is still on ax25_dev_list, so ax25_send_frame() still finds it, creates a connection and adds it to ax25_list after ax25_kill_by_device() has finished walking that list. The connection is left with a pointer to an ax25_dev that is freed a moment later, which ax25_find_cb() and the AX.25 timers then dereference: BUG: KASAN: slab-use-after-free in ax25_find_cb+0x2ed/0x330 [ax25] Read of size 8 at addr ffff8880031e8c10 by task repro/3287 ax25_find_cb+0x2ed/0x330 [ax25] rose_transmit_link+0xea/0x560 [rose] rose_write_internal+0x3ab/0x15b0 [rose] rose_release+0x2b2/0x4b0 [rose] Allocated by: ax25_dev_device_up, ax25_device_event Freed by: kfree_rcu_monitor, queued from ax25_device_event The buggy address is located 16 bytes inside of freed 256-byte region, cache kmalloc-256 This is the trace of the syzbot report below. An earlier commit, "rose: use timer_shutdown_sync() for t0timer teardown", attributed that report to the ROSE t0 timer; the freed object in the report is the ax25_dev, as it is here. A connection that is on the list in time is not safe either while it is still being set up: ax25_kill_by_device() can detach it, clearing its ax25_dev pointer, between the moment ax25_send_frame() adds it and the moment it starts the link and queues the frame, which then dereference NULL. Make the two exclude each other with RCU. ax25_send_frame() now runs entirely under rcu_read_lock() and gives up when the device is no longer marked up. ax25_kill_by_device() clears device_up and calls synchronize_rcu() before it walks the list: once that returns, every connection ax25_send_frame() was working on is complete and on the list, and no new one can appear behind the walk. This adds one RCU grace period to taking an AX.25 interface down. Tested on 6.12.94 with KASAN and lockdep, with the modules of this tree and the rest of this series: - with a 100 ms delay inserted between ax25_kill_by_device() and ax25_dev_device_down(), a single "ifconfig bpq0 down" during eight ROSE call requests left connections on the list and ended in a use-after-free in ax25_heartbeat_expiry(); with the series the list is empty after the down and there is no report; - the syzbot C reproducer, with the interface brought up again in a loop, caused 217 KASAN reports and a panic after 41 seconds; with the series it ran for 600 seconds without any report; - 60 plain "ifconfig bpq0 down" / "up" under 20 ROSE call requests per second, and a ROSE call through a three node chain over mkiss, behave as before; - eight ROSE calls started at the same instant still end up on a single AX.25 connection. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 45071a40f7d5db10350dbd177decd3f68fdaaa01) Signed-off-by: Sasha Levin <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Sun Oct 25 14:09:17 2026 +0800 block: avoid potential deadlock on zone revalidation failure commit 3dd63dba8f9cb6990a40af7ed66ee0159f475819 upstream. If revalidating the zones of a zoned block device with blk_revalidate_disk_zones() fails during a SCSI disk rescan, the following lockdep splat is thrown: [ 347.251859] [ T11230] sda: failed to revalidate zones [ 347.261380] [ T11230] ====================================================== [ 347.263882] [ T11230] WARNING: possible circular locking dependency detected [ 347.266353] [ T11230] 7.1.0+ #1194 Not tainted [ 347.268052] [ T11230] ------------------------------------------------------ [ 347.270537] [ T11230] tcsh/11230 is trying to acquire lock: [ 347.272555] [ T11230] ffffffff8f91d400 (wq_pool_mutex){+.+.}-{4:4}, at: destroy_workqueue+0x15d/0x8d0 [ 347.275914] [ T11230] but task is already holding lock: [ 347.278646] [ T11230] ffff88812fa1bcc0 (&q->q_usage_counter(io)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x16/0x30 [ 347.282503] [ T11230] which lock already depends on the new lock. [ 347.286239] [ T11230] the existing dependency chain (in reverse order) is: [ 347.289408] [ T11230] -> #2 (&q->q_usage_counter(io)#5){++++}-{0:0}: [ 347.292437] [ T11230] blk_alloc_queue+0x5ca/0x750 [ 347.294379] [ T11230] blk_mq_alloc_queue+0x14c/0x240 [ 347.296375] [ T11230] scsi_alloc_sdev+0x871/0xd10 [scsi_mod] [ 347.298619] [ T11230] scsi_probe_and_add_lun+0x600/0xc50 [scsi_mod] [ 347.301056] [ T11230] __scsi_scan_target+0x187/0x3b0 [scsi_mod] [ 347.303385] [ T11230] scsi_scan_channel+0xf2/0x180 [scsi_mod] [ 347.305651] [ T11230] scsi_scan_host_selected+0x20b/0x2d0 [scsi_mod] [ 347.308119] [ T11230] do_scan_async+0x42/0x420 [scsi_mod] [ 347.310276] [ T11230] async_run_entry_fn+0x94/0x5a0 [ 347.312284] [ T11230] process_one_work+0x8da/0x1690 [ 347.314287] [ T11230] worker_thread+0x5fe/0x1010 [ 347.316216] [ T11230] kthread+0x358/0x450 [ 347.317675] [ T11230] ret_from_fork+0x5b9/0x8e0 [ 347.319181] [ T11230] ret_from_fork_asm+0x11/0x20 [ 347.320778] [ T11230] -> #1 (fs_reclaim){+.+.}-{0:0}: [ 347.322890] [ T11230] fs_reclaim_acquire+0xd5/0x120 [ 347.324464] [ T11230] __kmalloc_cache_node_noprof+0x39/0x620 [ 347.326223] [ T11230] init_rescuer+0x19b/0x560 [ 347.327697] [ T11230] workqueue_init+0x33b/0x6a0 [ 347.329224] [ T11230] kernel_init_freeable+0x2eb/0x600 [ 347.330881] [ T11230] kernel_init+0x1c/0x140 [ 347.332334] [ T11230] ret_from_fork+0x5b9/0x8e0 [ 347.333847] [ T11230] ret_from_fork_asm+0x11/0x20 [ 347.335360] [ T11230] -> #0 (wq_pool_mutex){+.+.}-{4:4}: [ 347.337510] [ T11230] __lock_acquire+0xdea/0x2260 [ 347.339030] [ T11230] lock_acquire+0x187/0x2f0 [ 347.340495] [ T11230] __mutex_lock+0x1ab/0x2600 [ 347.341464] [ T11230] destroy_workqueue+0x15d/0x8d0 [ 347.342485] [ T11230] disk_free_zone_resources+0xd5/0x560 [ 347.343577] [ T11230] blk_revalidate_disk_zones+0x620/0xac7 [ 347.344723] [ T11230] sd_zbc_revalidate_zones+0x1dd/0x790 [sd_mod] [ 347.345938] [ T11230] sd_revalidate_disk+0xc66/0x8e60 [sd_mod] [ 347.347112] [ T11230] scsi_rescan_device+0x1f9/0x310 [scsi_mod] [ 347.348318] [ T11230] store_rescan_field+0x19/0x20 [scsi_mod] [ 347.349507] [ T11230] kernfs_fop_write_iter+0x3d2/0x5e0 [ 347.350565] [ T11230] vfs_write+0x469/0x1000 [ 347.351484] [ T11230] ksys_write+0x116/0x250 [ 347.352403] [ T11230] do_syscall_64+0xf0/0x6e0 [ 347.353361] [ T11230] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 347.354533] [ T11230] other info that might help us debug this: [ 347.356432] [ T11230] Chain exists of: wq_pool_mutex --> fs_reclaim --> &q->q_usage_counter(io)#5 [ 347.358919] [ T11230] Possible unsafe locking scenario: [ 347.360307] [ T11230] CPU0 CPU1 [ 347.361327] [ T11230] ---- ---- [ 347.362340] [ T11230] lock(&q->q_usage_counter(io)#5); [ 347.363344] [ T11230] lock(fs_reclaim); [ 347.364526] [ T11230] lock(&q->q_usage_counter(io)#5); [ 347.365968] [ T11230] lock(wq_pool_mutex); [ 347.366811] [ T11230] *** DEADLOCK *** This happens because SCSI disk rescan is executed from a work context and a failure of blk_revalidate_disk_zones() causes a call to disk_free_zone_resources() which will free the disk zone write plug workqueue. Avoid this by delaying the destruction of the disk zone write plug workqueue to disk_release(). Do this by introducing the function disk_release_zone_resources() and using this new function from disk_release(). This new function destroys the zone write plugs workqueue and calls disk_free_zone_resources(), thus allowing to remove the call to destroy_workqueue() from disk_free_zone_resources(). disk_alloc_zone_resources() is modified to not create the disk zone write plug work queue if it already exists. Fixes: a8f59e5a5dea ("block: use a per disk workqueue for zone write plugging") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> [ stanleyjhu: 6.12.y has no zone write plug kthread worker and does not use WQ_PERCPU, so only the workqueue part applies: disk_alloc_zone_resources() reuses an existing workqueue, disk_free_zone_resources() drains it instead of destroying it, and the new disk_release_zone_resources() destroys it from disk_release(). ] Signed-off-by: Stanley Jhu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Wed Sep 2 00:04:36 2026 +0300 Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn [ Upstream commit 86b55991d3cd690e73c5ef8d20b75ae4905b357a ] l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Assisted-by: deepseek-4-flash # finding the race condition Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joas Antonio dos Santos <[email protected]> Date: Fri Oct 9 12:59:19 2026 -0300 calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() [ Upstream commit 8070ed578b6b9134e045627fb745c887a806d46e ] calipso_skbuff_setattr() adjusts payload_len by the length of the option it inserts or resizes: payload = ntohs(ip6_hdr->payload_len); ip6_hdr->payload_len = htons(payload + len_delta); GRO can build BIG TCP packets larger than IPV6_MAXPLEN, and stores payload_len == 0 for them; ipv6_payload_len() then falls back to skb->len. For such a packet forwarded to a destination mapped to CALIPSO, the code above writes len_delta (or 65536 + len_delta when shrinking) into payload_len, and ipv6_payload_len() no longer falls back to skb->len. nf_tables, conntrack and sch_cake rely on it. The same arithmetic also wraps when a packet grows past IPV6_MAXPLEN, and a BIG TCP packet that shrinks below IPV6_MAXPLEN should get its real length back. Set payload_len from the skb length with ipv6_set_payload_len(), which stores 0 above IPV6_MAXPLEN and the real length otherwise, as ipv6_gro_complete() does. The network header was just reset to skb->data, so skb->len - sizeof(*ip6_hdr) is the payload length. Tested on one kernel (arm64, QEMU) with SELinux permissive, a minimal mdp-generated policy (network_peer_controls=1), "netlabelctl calipso add pass doi:16" and a NetLabel mapping of fd00:2::/64 to CALIPSO DOI 16. calipso_skbuff_setattr() was called through netlbl_skbuff_setattr() from a test-only debugfs hook (not part of this patch) adding a level-only label; payload_len after the call: case before fix after fix real length 1000, unlabeled 1016 1016 1016 70000 GSO, payload_len 0 16 0 70016 65530 GSO, grows past MAXPLEN 10 0 65546 65540 GSO with a 24 byte hop header, shrinks below MAXPLEN 65528 65532 65532 1000 with a 24 byte hop header 992 992 992 (0 means ipv6_payload_len() returns the real length.) On the forward path, with a client injecting unlabeled UDP through a router to a server, the router adds the CALIPSO option and the server delivers all datagrams (Udp6InDatagrams 5, Ip6InTruncatedPkts 0) with this patch. Fixes: 81fbc812132c ("ipv6/gro: insert temporary HBH/jumbo header") Suggested-by: Eric Dumazet <[email protected]> Suggested-by: Wang Zhan <[email protected]> Signed-off-by: Joas Antonio dos Santos <[email protected]> Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Wang Zhan <[email protected]> Acked-by: Paul Moore <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Etienne Perot <[email protected]> Date: Fri Aug 28 21:52:51 2026 +0000 cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children commit 8e359920216689b3b79e0fe8961a77fe312a511f upstream. Since commit b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill"), the fork path snapshots the kill_seq of the child's future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs the child if that cgroup's kill_seq has changed in the meantime, to catch forks racing with a cgroup.kill sweep. For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork() is taken before the target cgroup has been resolved: kargs->cgrp is always NULL at this point (it is only set at the end of the function). So the "if (kargs->cgrp)" branch is dead code and the snapshot always records the kill_seq of the parent's cgroup. cgroup_post_fork() then compares it with the kill_seq of the target cgroup, so the child gets SIGKILLed whenever the two cgroups have been killed a different number of times. As a result, once cgroup.kill has been written to a cgroup, every child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is killed on the spot, for as long as the cgroup exists: kill_seq is not exposed to userspace and never resets. Re-snapshot kill_seq from the target cgroup once it has been resolved, and drop the dead branch at the early snapshot site. This does not reopen the race fixed by b69bb476dee9. For CLONE_INTO_CGROUP, everything from the snapshot to the check in cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is only ever incremented under cgroup_mutex. tj: Updated the comment above kill_seq to reflect the new serialization rules as suggested by Shakeel Butt. Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") Cc: [email protected] Cc: Shakeel Butt <[email protected]> Assisted-by: LLM Signed-off-by: Etienne Perot <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Frank Sorenson <[email protected]> Date: Thu Oct 22 10:22:28 2026 -0400 cifs: add revalidation on FSCTL failure in smb2_duplicate_extents() [ Upstream commit 53676a5e28231186c9f56d87b7998b640699bc15 ] smb2_duplicate_extents() has no handling for FSCTL_DUPLICATE_EXTENTS_TO_FILE failure: when the FSCTL fails, local inode metadata may be stale from the pre-extension or from concurrent remote writes, but is never refreshed. Force revalidation on FSCTL failure and use i_size_read() for the pre-extension check. Fixes: cfc63fc8126a ("smb3: fix cached file size problems in duplicate extents (reflink)") Cc: [email protected] Signed-off-by: Frank Sorenson <[email protected]> Signed-off-by: Paulo Alcantara <[email protected]> [ sashal: Used a standalone failure block because the upstream success branch is absent. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Sep 21 15:44:50 2026 +0200 coredump: hold RCU while releasing parked threads commit 61d58591aa0188bf2463e263962256316ff8b576 upstream. coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop. Fixes: a94e2d408eae ("coredump: kill mm->core_done") Cc: [email protected] Acked-by: Oleg Nesterov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ming-Hung Tsai <[email protected]> Date: Tue Aug 18 18:05:47 2026 +0800 dm cache: fix demotion stats in passthrough mode commit 2ccb8878c149443c6acf628b438c9c942c20abb2 upstream. The demotion counter is incremented per incoming write bio before the invalidation begins, causing the demotion count to exceed the actual number of cached blocks when multiple bios target the same cached block. Additionally, the counter is incremented unconditionally regardless of invalidation failure. Reproduce steps: 1. Create a cache device consisting of 512 cache entries modprobe brd rd_size=262144 dmsetup create cmeta --table "0 8192 linear /dev/ram0 0" dmsetup create cdata --table "0 65536 linear /dev/ram0 8192" dmsetup create corig --table "0 65536 linear /dev/ram0 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --io_size=2048m nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache with multiple jobs to trigger multiple bios hitting the same cached block. fio --filename=/dev/mapper/cache --name=test --rw=write --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --numjobs=4 5. Check if demoted matches cached block count. These numbers should match but may differ due to overcounting per bio. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fix by moving the demotion counter increment into invalidate_complete(), gated on the success flag. Reported-by: Ben Marzinski <[email protected]> Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: [email protected] Signed-off-by: Ming-Hung Tsai <[email protected]> Reviewed-by: Benjamin Marzinski <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Benjamin Marzinski <[email protected]> Date: Tue Aug 25 15:22:26 2026 -0400 dm cache: fix issue with background work locking commit bc9781c0247de107876f32929f1637db93a42b34 upstream. dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: [email protected] Signed-off-by: Benjamin Marzinski <[email protected]> Reviewed-by: Matthew Sakai <[email protected]> Reviewed-by: Ming-Hung Tsai <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ben Cressey <[email protected]> Date: Wed Aug 26 00:25:33 2026 +0000 dm-crypt: fix a tiny race condition in crypt_dec_pending commit 148845aa1921d95ef5dc851c76e6a284f6657df6 upstream. crypt_dec_pending reads io->error before calling atomic_dec_and_test. Another context, for example crypt_endio called from an interrupt, may set io->error and drop its reference between the read and the decrement. crypt_dec_pending then drops the last reference and completes the bio with the stale status - so a read that failed and was never decrypted, or a write that failed, is reported as successful. The read was placed before the decrement by commit b35f8caa0890 ("dm crypt: wait for endio to complete before destruction"), because that commit freed dm_crypt_io before calling bio_endio. This is no longer the case, dm_crypt_io lives in the per-bio data now. Read io->error after atomic_dec_and_test instead. atomic_dec_and_test is fully ordered, so no additional barrier is needed. Fixes: b35f8caa0890 ("dm crypt: wait for endio to complete before destruction") Cc: [email protected] Reviewed-by: Jose Fernandez (Anthropic) <[email protected]> Signed-off-by: Ben Cressey <[email protected]> Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Genjian Zhang <[email protected]> Date: Fri Aug 7 23:57:15 2026 +0800 dm-ebs: fix incorrect device offset check in ebs_ctr() commit 7ac81e2d2240f2c57bd073b0733e0b2abca38e82 upstream. <offset> is a backing-device sector offset; ti->len is the virtual target length. Comparing them rejects valid tables, e.g.: dmsetup create ebs0 --table "0 1048576 ebs /dev/sda 2097152 1 8" -> ebs: Invalid device offset sector (-EINVAL) Drop the check. Bounds against the backing device are already enforced later by device_area_is_invalid() via ebs_iterate_devices(). Cc: [email protected] Fixes: d3c7b35c20d6 ("dm: add emulated block size target") Signed-off-by: Genjian Zhang <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ben Cressey <[email protected]> Date: Thu Aug 20 21:44:58 2026 +0000 dm-integrity: fix infinite loop on discard with large tag size commit 18d80c77b4c7dd20699e81cedfbbff4e9d198f28 upstream. When integrity_metadata handles a discard, it fills a buffer with DISCARD_FILLER and writes it over the tags, max_blocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksums_onstack and max_size is set to HASH_MAX_DIGESTSIZE. So if the tag size is larger than HASH_MAX_DIGESTSIZE, max_blocks is zero, bi_size is never decremented and the loop never terminates. Fix this by using sizeof(checksums_onstack) as max_size. The array has MAX_TAG_SIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so max_blocks is at least 1. Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Cc: [email protected] Reviewed-by: Jose Fernandez (Anthropic) <[email protected]> Signed-off-by: Ben Cressey <[email protected]> Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Cheng <[email protected]> Date: Mon Aug 24 19:34:49 2026 +0800 dm-integrity: require stable writes for internal hash modes commit b2fd92f016e9d692fd3c8c08d0ee014e9212279d upstream. dm-integrity direct, bitmap and inline internal-hash modes compute integrity tags from the pages carried by the write bio. The lower data write also uses those pages, so the tag and the data write depend on the same memory contents staying unchanged while writeback is in flight. Without stable writes, a buffered writer can modify a writeback folio after dm-integrity has submitted the data bio and before the lower device has consumed the data. After a crash, this can leave data from the later contents with a tag calculated from the earlier contents, causing permanent checksum failures on read. Set BLK_FEAT_STABLE_WRITES for internal-hash D, B and I modes so filesystems wait for writeback folios to become stable before modifying them again. Journal mode is left unchanged because it copies data into the journal before computing and persisting the tag. Tested using dm-delay over a virtio-blk test disk, dm-integrity internal_hash:crc32c and no-journal ext4. The D and B reproducers both failed with checksum errors before this change and completed with READ_RC=0 and zero mismatches after it. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: [email protected] Reported-by: Sun Yangkai <[email protected]> Link: https://github.com/chencheng-fnnas/reproducer/blob/main/dm-integrity-writeback-race.py Signed-off-by: Chen Cheng <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Waiman Long <[email protected]> Date: Sun Aug 30 19:41:24 2026 -0400 Drivers: hv: Avoid infinite retry loop in init_vp_index() [ Upstream commit 32ea0a33e3a0fb7c10c601b43e1b2f6c06a3f5fd ] There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. Link: https://sashiko.dev/#/message/20260422030903.E1BFCC2BCB0%40smtp.kernel.org [1] Fixes: 6640b5df1a38 ("Drivers: hv: vmbus: Don't assign VMbus channel interrupts to isolated CPUs") Signed-off-by: Waiman Long <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Kelley <[email protected]> Date: Mon Aug 31 20:45:14 2026 -0700 Drivers: hv: Don't reset VMBus connection state on error/exit paths [ Upstream commit ec31dc39e835ccde0930daccece8c492d28282fc ] In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded. Reported-by: Sashiko <[email protected]> Closes: https://lore.kernel.org/linux-hyperv/[email protected]/ Fixes: 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback") Signed-off-by: Michael Kelley <[email protected]> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Wed Oct 7 00:02:52 2026 +0200 drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hang commit 752480ad62964edf0254e151110d3e53a7cb37de upstream. SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Fri Oct 9 13:21:33 2026 +0800 drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr commit de9f6bcdb44f0e410031002e2f103826ea6b6259 upstream. amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Thu Aug 20 16:32:51 2026 +0200 drm/amdgpu: Fix VCE 3 ring align_mask [ Upstream commit 2ee9836545e690c9e66ec203445d7705959fd7a8 ] The largest frame is 20 dwords, so 0xf mask is too small. This was always wrong, but we were lucky with the VCE_CMD_END commands inserted after fence and vm_flush. Fixes: 8897ea8c761b ("drm/amdgpu: Implement insert_end for VCE 3") Cc: [email protected] Acked-by: Alex Deucher <[email protected]> Signed-off-by: David Rosca <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Thu Oct 22 10:09:11 2026 -0400 drm/amdgpu: free the userptr ranges when a CS fails after parser_bos [ Upstream commit 1b4da805a0ba354a549ce07459c871c17dd94fe0 ] amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: [email protected] [ sashal: Adapted cleanup to use amdgpu_ttm_tt_get_user_pages_done() in the existing error_backoff path. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Christian König <[email protected]> Date: Wed Oct 7 14:46:57 2026 +0200 drm/exec: don't immediately add prelocked obj to array of locked objs commit 26401a4999f1596a515b2e704e7066ac09306488 upstream. When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop. Signed-off-by: Christian König <[email protected]> Reported-by: Vitaly Prosyak <[email protected]> Reviewed-by: Vitaly Prosyak <[email protected]> Tested-by: Vitaly Prosyak <[email protected]> Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: [email protected] # v6.6+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dibin Moolakadan Subrahmanian <[email protected]> Date: Thu Oct 22 08:55:05 2026 -0400 drm/i915/dmc: Harden DMC firmware payload parsing [ Upstream commit 8bb1858db453cd4250e3b633f5d2d09206024ca6 ] Validate the conversion of the DMC firmware size from dwords to bytes using check_mul_overflow() before calculating the firmware payload size. Reject zero-length payloads and zero MMIO counts in the DMC firmware header so malformed firmware is caught early. Also set dmc_fw_size only after the payload allocation succeeds. Fixes: eb805623d8b1 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: [email protected] Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian <[email protected]> Reviewed-by: Mitul Golani<[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit efde6601a1f1daedfe3dcc2816c934ddb44e3eef) Signed-off-by: Joonas Lahtinen <[email protected]> [ sashal: Changed logging arguments from `display->drm` to `&i915->drm`. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Fri Oct 2 10:36:43 2026 -0300 drm/vc4: hdmi: Move packet RAM enable to PM runtime [ Upstream commit 3f57b34485dc01e5a2db60a89a6ae5439a897e53 ] Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. Link: https://github.com/raspberrypi/linux/issues/7069 Fixes: b47a72f30768 ("drm/vc4: hdmi: Switch to HDMI connector") Signed-off-by: Dave Stevenson <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: MaÃra Canal <[email protected]> Signed-off-by: MaÃra Canal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Hellström <[email protected]> Date: Thu Oct 22 07:35:58 2026 -0400 drm/xe: Bump LRU for external objects on exec and rebind [ Upstream commit d2ce8fcd778ee6d92748c92d23a56d4416c29d86 ] The VM's private BOs get their LRU position refreshed in bulk via ttm_lru_bulk_move_tail() on vm->lru_bulk_move, both after a successful non-LR exec and after the LR preempt-fence rebind worker runs. External objects (BOs potentially shared across VMs) are never added to that per-VM bulk move list, so their LRU position is never refreshed by either path. This makes external objects in active use look more evictable than they are. Add xe_vm_bump_lru(), which, under a single lru_lock critical section, performs the bulk move of the VM's private BOs and bumps each external object locked by the drm_exec transaction. Use it from both the non-LR exec path and the LR rebind worker, replacing the open-coded bulk move. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: <[email protected]> # v6.8+ Assisted-by: LLM Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 324ba30cca180c2e1d02090743dd78ccb15b9e4a) Signed-off-by: Rodrigo Vivi <[email protected]> [ sashal: Adjusted header context to accommodate missing xe_vm_bind_kernel_bo() and xe_vm_resume_rebind_worker() declarations. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Joseph Qi <[email protected]> Date: Thu Oct 22 14:40:46 2026 +0800 eventfs: fix SRCU read lock leak in eventfs_iterate() Commit 1b95382da85c ("eventfs: Use children field for rcu head and add memory barriers") added an early bail out to the ei->children loop: smp_rmb(); if (ei->is_freed) return -EINVAL; Upstream wraps eventfs_iterate() in guard(srcu)(&eventfs_srcu), so that return still drops the read lock. The 6.12.y backport instead brackets the function with srcu_read_lock() and a shared "out" label that calls srcu_read_unlock(), so this path returns while still holding eventfs_srcu for reading. The unbalanced reader prevents the grace period from ever completing, so the call_srcu() callback queued by free_ei() never runs and the eventfs_inode is leaked. Every readdir that races with removal adds another reader. Set ret and jump to "out" like the other bail out paths in this function do. Fixes: 1b95382da85c ("eventfs: Use children field for rcu head and add memory barriers") Signed-off-by: Joseph Qi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Fri Oct 9 23:51:54 2026 +0200 eventfs: Free the eventfs_inode after an rcu grace period too commit 2cd88c498ecff8e22bf4c397b8eb226db70ac343 upstream. tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone. With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away: BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: <TASK> tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...] Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60 Before commit 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") release_ei() used call_rcu(), which covered the walker, while eventfs_iterate() needs the SRCU grace period. Wait for both and chain call_rcu() from the SRCU callback. Cc: [email protected] Fixes: 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Wed Oct 21 11:55:26 2026 -0400 ext4: free the sbi after a grace period [ Upstream commit c17b44266a1f9fcb49b894d4611d1254bf1aa313 ] ext4_get_link() follows a symlink that keeps its target in a data block in rcu pathwalk mode with ext4_getblk(EXT4_GET_BLOCKS_CACHED_NOWAIT). That reads s_mount_state in the ASSERT() of ext4_getblk() and again in ext4_es_lookup_extent(), and the lookup bumps the extent status hit or miss counter, all through sb->s_fs_info. ext4_put_super() destroys those counters, clears sb->s_fs_info and frees the sbi without waiting for a grace period. A pathwalk that is still in ext4_get_link() when the last reference to the mount goes away then dereferences a NULL s_fs_info, the freed sbi or the destroyed percpu counters. With a pathwalk held up in ext4_get_link() while the last reference goes away: KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:ext4_getblk+0xf0/0x640 Call Trace: <TASK> ext4_get_link+0x26c/0x410 pick_link+0xf96/0x1780 step_into_slowpath+0x9b8/0x1250 path_lookupat+0x484/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. Keep sb->s_fs_info and free the sbi together with the extent status counters after a grace period. Split the counters out of ext4_es_unregister_shrinker() for that. The shrinker still gets wasted in ext4_put_super(), the counters go with the sbi. Fixes: 6493792d3299 ("ext4: convert symlink external data block mapping to bdev") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> [ sashal: omitted ext4_es_destroy_stats() integration with the extent KUnit tests ] Signed-off-by: Sasha Levin <[email protected]>
Author: Matteo Croce <[email protected]> Date: Fri Oct 16 22:33:33 2026 +0200 fat: stop reading directory entries past the end-of-directory marker commit 6a2875517c778ac1111b6920e94cbab91cda8724 upstream. The FAT specification[1] (FAT Directory Structure -> "DIR_Name[0]") states: If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0). The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free. Linux did not honour this. fat_get_entry() kept advancing past the 0x00 terminator; if the trailing on-disk slots were not zero-filled (buggy formatters, read-only media written by other operating systems, on-disk corruption) the driver surfaced arbitrary bytes as real directory entries. On a typical affected image, `ls /mnt` returns ~150 bogus entries with random binary names, multi-gigabyte sizes, dates ranging from 1980 to 2106, and a flood of -EIO from stat(). Earlier attempts (v1..v3, see [2][3][4]) added `de->name[0] == 0` guards at each call site. As Hirofumi pointed out on v3, those guards reject the entry but fat_get_entry() has already advanced *pos past it; the next readdir() resumes after the marker and walks straight back into the garbage. His suggestion was to centralise the check. This patch: * Adds fat_get_entry_eod(), a small wrapper around fat_get_entry() that returns -1 when name[0] == 0 and seeks *pos to dir->i_size. Per spec every slot after the 0x00 marker is also zero, so jumping to the end of the directory is correct: subsequent reads return -1 from fat_bmap() without re-fetching trailing zero slots, and callers persisting *pos across invocations (notably readdir's ctx->pos) keep reporting end-of-directory on re-entry. * Converts the read/search paths to use the new wrapper: fat_parse_long(), fat_search_long(), __fat_readdir(), and fat_get_short_entry() -- the last covers fat_get_dotdot_entry(), fat_dir_empty(), fat_subdirs(), fat_scan(), and fat_scan_logstart() transitively. * Leaves fat_add_entries() and __fat_remove_entries() on raw fat_get_entry(): the write paths legitimately need to operate on free/zero slots. fat_add_entries() additionally detects an allocated entry past a 0x00 marker (the spec violation that produces the garbage) and treats it as filesystem corruption: fat_fs_error_ratelimit() is called -- which honours the configured errors= mount option (panic / remount-ro / continue) -- and the operation returns -EIO so we don't write fresh entries into an already-corrupt directory. [1] https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc [2] https://lore.kernel.org/lkml/[email protected]/ [3] https://lore.kernel.org/lkml/[email protected]/ [4] https://lore.kernel.org/lkml/[email protected]/ Reported-by: Timothy Redaelli <[email protected]> Suggested-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Matteo Croce <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> [nb: keep i_pos in fat_add_entries(), it is still used here because the fat_add_new_entries() rework is not in this tree] Signed-off-by: Nicolai Buchwitz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Sep 21 15:44:56 2026 +0200 fork: release the files of a failed fork after sched_cancel_fork() commit 296a98c1fa50778c3b31eebed1a3f903f9684349 upstream. Reorder copy_process() cleanup so sched_fork() taking scx_fork_rwsem scx_pre_fork() is safe and isn't held around exiting files. Right now, a fork that fails while another thread closed the bpf link fd will deadlock against its own read side. It also blocks every fork on the system: copy_process() holds scx_fork_rwsem for read exit_files() close_files() filp_close_sync() bpf_scx_unreg() kthread_flush_work() waits for the disable work scx_root_disable() percpu_down_write(&scx_fork_rwsem) Simply release the child's files after sched_cancel_fork() dropped the lock. The task starts out as a copy of its parent so p->files points to the parent's table until copy_files() replaces it. exit_files() must not run for a fork that failed before that. Clear p->files up front so exit_files() is a no-op for those and make copy_files() set it explicitly for CLONE_FILES. Reported-by: Chris Mason <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Fri Oct 2 05:59:02 2026 +0000 fsnotify: prevent mark additions during connector teardown commit 36ebddca56b9d8993d6dc984fdecc748ee1f5e06 upstream. fsnotify_destroy_marks() keeps a reference to its current mark while it drops conn->lock to destroy the mark. This stabilizes the forward-walk cursor, but does not prevent a new mark from being inserted before it. For example, an inotify watch re-added after IN_IGNORED sorts before the old, detached mark for the same group. The walk can miss the replacement and then detach the entire connector from the object. The replacement is still on its group's marks_list and, for inotify, in the watch IDR. The group mutex no longer protects the connector's object from disappearing. An unprivileged fdinfo read racing the final detach can consequently call igrab(NULL): BUG: KASAN: null-ptr-deref in igrab+0x24/0x100 Write of size 4 at addr 0000000000000148 Call Trace: igrab+0x24/0x100 inotify_show_fdinfo+0x1dc/0x5e0 seq_show+0x397/0x690 Set a DESTROYING flag under conn->lock before starting the walk, and reject new marks on that connector with -ENOENT. The existing add-mark error paths undo the temporary group-list entry and the backend's watch allocation. Do not wait for teardown while holding the group mutex, which the destroyer needs. Once the old connector is detached, an add can install a fresh connector as before. This closes the insertion race for all object types using the common connector teardown, without changing the mark reference or SRCU lifetime rules. Fixes: 6b3f05d24d35 ("fsnotify: Detach mark from object list when last reference is dropped") Cc: [email protected] Signed-off-by: Kyle Zeng <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aaron Ahmed <[email protected]> Date: Fri Oct 16 23:04:03 2026 +0000 ftrace: Initialize modname and offset in print_rec() commit e1f339ff3b83857b93baf8b88186275a413d445e upstream. print_rec() leaves 'modname' and 'offset' uninitialized and kallsyms_lookup() only sets them on success. When the lookup fails like when a module is being loaded or unloaded, 'modname' holds a garbage value, passes the 'if (modname)' check, and is dereferenced by seq_printf(). Oops: general protection fault RIP: 0010:string+0x48/0xe0 Call Trace: vsnprintf+0x1f5/0x650 seq_printf+0x8e/0xb0 print_rec+0x6c/0xc0 t_show+0x4c/0x440 seq_read_iter+0x119/0x480 This can be triggered by reading available_filter_functions while a module is being loaded or unloaded. Initialize both variables so a failed lookup skips the module name. Cc: [email protected] Fixes: b39181f7c690 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function") Link: https://patch.msgid.link/[email protected] Tested-by: Gavin Inglis <[email protected]> Signed-off-by: Aaron Ahmed <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jann Horn <[email protected]> Date: Wed Oct 21 17:37:12 2026 -0400 futex: Fix mm reuse handling for FUT_OFF_MMSHARED [ Upstream commit 3267512ad1c2cc0c7768c5b014dc2cceb398a801 ] A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM. It is possible for a process to wait on a shared futex with a different MM because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED futex by another process. This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address. Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID. Leave private futexes as before to avoid influencing the performance of the hotpath. (Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by setting clear_child_tid such that it points into anonymous memory, which causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.) Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()") Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/ Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] [ sashal: Replaced futex_mm_data infrastructure with a direct mm_struct field initialized in mm_init(). ] Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Tue Oct 13 14:01:10 2026 +0800 gpio: mxc: fix both_edges bit operations [ Upstream commit b7719c575dec69146f6d537fd616b27083c0cf45 ] gpio_set_irq_type() can be called concurrently for different pins on the same port. The IRQ core serializes per irq descriptor, but different pins have different descriptors, so on SMP systems two concurrent gpio_set_irq_type() calls for pins on the same port run without mutual exclusion. The read-modify-write of port->both_edges is performed outside the port-wide scoped_guard(gpio_generic_lock_irqsave) section, so concurrent updates for different pins can overwrite each other, causing missed interrupts or stuck IRQ lines on dual-edge triggered pins. The original uniprocessor MXC SoCs were not affected; the race became reachable on multi-core i.MX7 and i.MX8 SoCs that reuse this driver. Convert both_edges from u32 to unsigned long and use set_bit(), clear_bit(), and test_bit() to make the modifications atomic. Fixes: 910862ec092c ("mxc: emulate GPIO interrupt on both-edges") Reviewed-by: Frank Li <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Tue Oct 13 14:01:11 2026 +0800 gpio: mxc: fix wakeup_pads bit operations [ Upstream commit 170aeff46fb54f41545c85a72aec525aebc79d44 ] gpio_set_wake_irq() can be called concurrently for different pins on the same port. The writer-vs-writer race is the concern: two concurrent gpio_set_wake_irq() calls for different pins on the same port both do a non-atomic read-modify-write on the same wakeup_pads word. The old |= and &= compile to separate load/modify/store instructions that can interleave, losing one CPU's update. assign_bit() uses an atomic RMW instruction, so concurrent writers to different bits in the same word are safe. The reader side (for_each_set_bit in noirq_suspend, wakeup_pads > 0) runs in noirq context where no concurrent writer can execute, so reader atomicity is not needed. wakeup_pads is a u32, while assign_bit() operates on unsigned long pointers. On 64-bit platforms, this causes an 8-byte read-modify-write on a 4-byte field, corrupting the adjacent is_pad_wakeup. So change wakeup_pads to unsigned long and reorder to avoid wasting words. And fix the enable/disable path unconditionally sets/clears the wakeup_pads bit even when enable_irq_wake()/disable_irq_wake() fails. Only update the bit on success. Fixes: f60c9eac54af ("gpio: mxc: enable pad wakeup on i.MX8x platforms") Assisted-by: LLM Reviewed-by: Frank Li <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Tue May 26 08:35:02 2026 +0200 gpio: mxc: use BIT() macro [ Upstream commit 9de94681ee48770ec7e2062451a572b557bf9298 ] Replace the open-code with the BIT() macro. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Stable-dep-of: 170aeff46fb5 ("gpio: mxc: fix wakeup_pads bit operations") Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Wed Jul 2 11:22:09 2025 +0200 gpio: mxc: use lock guards for the generic GPIO chip lock [ Upstream commit ba441322c7aac4735d78fc6781e497a01fb8eac7 ] Simplify the code by using lock guards for the bgpio_lock. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Stable-dep-of: b7719c575dec ("gpio: mxc: fix both_edges bit operations") Signed-off-by: Sasha Levin <[email protected]>
Author: Kent Gibson <[email protected]> Date: Thu Oct 15 10:57:49 2026 +0800 gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths [ Upstream commit c28846ca1ac6134881114d272314623c8433e372 ] A drive-by review by Sashiko reports that, after a failed call to gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly, bypassing the freeing of possibly alloced bitmaps, potentially leaking memory. It is an unlikely error path, but is possible. Defer the return code check until after the bitmap_free() block. Fixes: 9b407312755f ("gpiolib: rework the wrapper around gpio_chip::set_multiple()") Reported-by: Sashiko <[email protected]> Link: https://lore.kernel.org/linux-gpio/[email protected]/ Signed-off-by: Kent Gibson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Loic Poulain <[email protected]> Date: Mon Oct 12 14:54:56 2026 +0200 i2c: qcom-cci: Fix HALT_ACK reset request being dropped commit 195f3d74b5de98969dc4fad956393bb00787efd1 upstream. A HALT_ACK interrupt indicates that the corresponding I2C master has entered the halted state and must be reset before further operation. The M0 and M1 HALT_ACK status bits may be asserted simultaneously in a single interrupt. However, the interrupt handler currently overwrites the reset mask when processing each HALT_ACK condition, causing the first reset request to be lost if both events are reported together. Accumulate reset requests instead of overwriting them so that both masters are properly reset when M0 and M1 HALT_ACK events occur in the same interrupt. Fixes: e517526195de4 ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Loic Poulain <[email protected]> Cc: <[email protected]> # v5.8+ Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Wed Oct 21 17:36:25 2026 -0400 i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe() [ Upstream commit aaabefc79b0ff0018e8e3832169bbe359d0551fc ] In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak. Switch to devm_clk_get() so that the clock is automatically managed and released. Fixes: 560746eb79d3 ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Enrico Zanda <[email protected]> Date: Wed Oct 21 17:36:24 2026 -0400 i2c: viai2c-wmt: Replace dev_err() with dev_err_probe() in probe function [ Upstream commit 3b7d8d151a7ebebc5257766110c102ab173b5844 ] This simplifies the code while improving log. Signed-off-by: Enrico Zanda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andi Shyti <[email protected]> Stable-dep-of: aaabefc79b0f ("i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe()") Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Sep 21 15:44:53 2026 +0200 io-wq: order the exit bit against worker creation task work Commit 0e5663856b69219ef2f02e04bac9f5c5be19718a upstream. io_wq_exit_workers() cancels task work for queued worker creation with task_work_cancel_match(). That has a plain load of task->task_works. io_queue_worker_create() adds the new entry and tests IO_WQ_BIT_EXIT to cancel it if the workqueue is already on its way out. That must be ordered. task_work_add() has a full barrier via cmpxchg(). But io_wq_exit_start() sets the bit with set_bit() which doesn't have any memory ordering. So afaict, on weakly ordered architectures the exiting task may load task_works before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with worker_refs and the exiting task waits on worker_done indefinitely. If the task still has rings then io_uring_del_tctx_node() provides the barrier via test_and_set_bit() in io_wq_set_exit_on_idle(). When it has closed all rings though that barrier is gone. Add the barrier after the set_bit(). Fixes: 71a85387546e ("io-wq: check for wq exit after adding new worker task_work") Cc: [email protected] Reviewed-by: Jens Axboe <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:40 2026 +0000 io_uring/cancel: don't forget that the work was running Commit 8aa0e5db4845fb5ac11abe40d7b1cac0656c3ee3 upstream. If the request to be cancelled is being run by io-wq, io_async_cancel_one() flags the work, signals the worker and returns -EALREADY. Since commit ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") io_try_cancel() goes on regardless, as poll may be armed for the request. If it isn't, and nothing else turns up, the result is the -ENOENT of the last search. __io_async_cancel() makes up for that. On -ENOENT it tries the io-wq of every task that uses the ring, and that of the caller is one of them. So the work is found a second time, and the result is -EALREADY after all. Unless the worker is done with it by then. If the work is flagged before io_wq_submit_work() looks at IO_WQ_WORK_CANCEL, all the worker does is to queue the request to be failed by task work. Then it isn't anywhere to be found until the task work has run, and - IORING_REGISTER_SYNC_CANCEL returns -ENOENT, - IORING_OP_ASYNC_CANCEL completes with -ENOENT, for a request that they have just cancelled, and that completes with -ECANCELED. With a read of an empty pipe, IOSQE_ASYNC, and a sync cancel right behind it, 1 to 3 of 1,000,000 calls return -ENOENT, and 50 to 110 with IORING_SETUP_DEFER_TASKRUN (4 CPUs, KVM). Nothing is written to the pipe, and all of these reads end with -ECANCELED. Remember that the work was found. IORING_OP_ASYNC_CANCEL completes with -EALREADY, as it does if the worker is a bit slower. For IORING_REGISTER_SYNC_CANCEL it means to try again, which ends with 0. The result of a linked timeout, which calls io_try_cancel() by itself, and the number that is returned for IORING_ASYNC_CANCEL_ALL and _ANY don't change. Fixes: ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Date: Thu Oct 22 10:50:03 2026 -0400 io_uring/cancel: don't spin on local work the task can't run [ Upstream commit fddcf4c5321b3ea5f72166c3fd36a9d1c34f80c7 ] io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit(). An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel. Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state. Fixes: 360cd42c4e95 ("io_uring: optimise io_req_local_work_add") Reported-by: [email protected] Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> [ sashal: Used !llist_empty(&node->ctx->work_llist) instead of the unavailable io_local_work_pending() helper. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:42 2026 +0000 io_uring/cancel: let CANCEL_ALL find parked requests Commit fe6ca13c98b1223f6005f32913ebd32e4df64b77 upstream. A cancellation with IORING_ASYNC_CANCEL_ALL or _ANY goes on until it finds nothing more. A request may stay where it was found for a while after it has been cancelled, so each one that matches is stamped with the sequence number of the cancellation, and is skipped from then on. io_cancel_cb() does so for io-wq work as well. There is no need to: pending work is taken off the list, and the workers are looked at once per call. And it does harm. A request that is run by io-wq may be parked while it still is the current work of the worker: poll gets armed for it, or it is put on ->futex_list or ->waitid_list. io-wq worker io_try_cancel() io_wq_submit_work() io_arm_poll_handler() io_poll_add_hash() io_async_cancel_one() io_cancel_cb() stamps the request sets IO_WQ_WORK_CANCEL = -EALREADY io_poll_cancel() skips the request = -ENOENT io_assign_current_work(NULL) The flag comes too late for the worker to see it, and the search that would have found the request takes it for done. The cancellation returns, and the request stays. With a multishot poll, IOSQE_ASYNC, and IORING_OP_ASYNC_CANCEL with IORING_ASYNC_CANCEL_ALL up to 63us later, that happens to 4 of 1,000 requests (4 CPUs, KVM). Take the stamp off again if the work matches. If the request is found on one of the lists it gets a new one, and io_cancel_cb() doesn't match it a second time. __io_async_cancel() tries the io-wq of the caller twice. So far the stamp has kept it from counting work that is running there the second time. Skip it instead, so that the number that is returned stays the same. Fixes: 8e29da69fead ("io_uring: add support for IORING_ASYNC_CANCEL_ALL") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:41 2026 +0000 io_uring/cancel: recognize "no timeout" on 32-bit Commit 3774e4d4c8533da2caae95556c4d635c7c4f45b8 upstream. IORING_REGISTER_SYNC_CANCEL waits without a limit if both fields of io_uring_sync_cancel_reg::timeout are -1. io_sync_cancel() compares them with -1UL. They are of type long long. With a long of 32 bits -1UL is 4294967295, which is what it stays when it is converted for the comparison, and the fields are never equal to it. So { -1, -1 } is taken for a timeout. ktime_set() takes the nanoseconds as an unsigned long, so what becomes of it is -1s + 4294967295ns = 3.29s. If the request is being run by io-wq and can't be interrupted, the call returns -ETIME after that time, rather than waiting for the request to be gone. On i386, with a buffered read from a null_blk device that takes 4s to complete a request, IOSQE_ASYNC, that is what each call does. Fixes: 78a861b94959 ("io_uring: add sync cancelation API through io_uring_register()") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:26 2026 +0000 io_uring/cmd: don't leave list poison in ->hash_node Commit 4c83e39f4d1944d7146fd06094f2c8053238d55c upstream. io_uring_cmd_del_cancelable() uses hlist_del() to take a command off ->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in ->hash_node. Requests are recycled through the request cache without being reinitialised, and not every user of ->hash_node sets it up before it is used: If a vectored futex wait is woken while futex_wait_multiple_setup() is still queueing the futexes, io_futexv_wait() doesn't add the request to ->futex_list, and leaves the completion to the task_work queued by the wake up. io_futexv_complete() ends in __io_futex_complete(), whose hlist_del_init() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through LIST_POISON2: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...] RIP: 0010:io_futexv_complete+0x219/0x420 Call Trace: tctx_task_work_run+0x804/0x950 tctx_task_work+0x71/0xa0 task_work_run+0x118/0x200 Leave the node unhashed. Fixes: 93b8cc60c37b ("io_uring: cancelable uring_cmd") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:36 2026 +0000 io_uring/io-wq: don't exit with a creation pending Commit e231d2e8f80d3649ecd3851b7f2abdfbe606c04b upstream. A worker that is the last one to go to sleep while work is pending asks for another worker. io_wq_dec_running() bumps ->nr_running on behalf of the new worker and queues create_worker_cb() as task_work for the owner of the io-wq. Until that has run, everybody else takes it that a worker is running which is going to look after the work list: io_wq_enqueue() doesn't create one, and other workers that go to sleep don't find themselves to be the last. If the worker that made the request exits, io_worker_exit() cancels the task_work, and io_worker_cancel_cb() drops ->nr_running without a look at the work list: worker A worker B io_wq_enqueue() blocks, work is pending nr_running++ queues create_worker_cb() wakes, handles the work idle timeout, decides to exit picks up work 1 queues work 2 B is on the free list still: wakes B work 1 blocks nr_running 2 -> 1 io_worker_exit() io_worker_cancel_cb() nr_running 1 -> 0 Work 2 has to wait for work 1, although there is room for more workers. It takes an owner that doesn't get around to run its task_work for the time of the idle timeout, less if the worker exits because its affinity was changed or the io-wq is marked exit-on-idle. Let the worker stay around until its request has been dealt with. Only the worker itself sets ->create_state, so it can't be set behind its back once it has decided to leave. [ 6.12: no exit-on-idle state ] Fixes: 1d5f5ea7cb7d ("io-wq: remove worker to owner tw dependency") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:29 2026 +0000 io_uring/io-wq: don't hide a link from cancellations Commit 436d48a2ed13112d2d27085325838e5bce6b4507 upstream. A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two. [ 6.12: io-wq still calls back through io_wq_data, so a ->put_work callback is added next to ->free_work. io_wq_put_work() keeps the link check of 6.12, without the REQ_F_CQE_SKIP condition that commit 5530a5102e3c adds in 7.3 ] Fixes: 768134d4f481 ("io_uring: don't do flush cancel under inflight_lock") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:28 2026 +0000 io_uring/io-wq: don't lose the signal that ends work Commit 63c103279a95e82280092f2f4232e91e8117a252 upstream. When a thread exits, only its tracked requests are cancelled. Then its io-wq is torn down. io_wq_exit_workers() signals every worker, to get it out of an interruptible sleep, and waits for all of them to exit. Before they do, they go through the work that is left. Unbounded work is cancelled. Bounded work is run, as it is expected to end by itself. Not all of it does. An open has no file yet, so it counts as bounded, and the open of a FIFO waits for the other end. That is what the signal is for. But the workers are signalled once, and a worker that hasn't started the work by then loses the signal: io_wq_exit_workers() io_worker_handle_work() io_wq_worker_wake() set TIF_NOTIFY_SIGNAL io_assign_current_work() io_run_task_work() clear TIF_NOTIFY_SIGNAL io_wq_submit_work() fifo_open() wait_for_partner() wait_for_completion_timeout() The thread never gets out of do_exit(): IORING_OP_OPENAT of a FIFO without a writer, IOSQE_ASYNC exit of the thread that has submitted it hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is killed. Set TIF_NOTIFY_SIGNAL for bounded work that is started with IO_WQ_BIT_EXIT set. The bit is set before the workers are signalled, and it is tested after the flag has been cleared, with clear_notify_signal() providing the barrier. So either the flag stays, or the bit is seen. Work that is started while the io-wq exits is treated like work that is being run at that time: it isn't interrupted unless it waits interruptibly. Fixes: afcc4015d1bf ("io-wq: provide an io_wq_put_and_exit() helper") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:35 2026 +0000 io_uring/io-wq: don't strand work when a worker exits Commit ad41f325be1271b22d99353819c90f0d5e45acc8 upstream. A worker exits if its idle timeout fired and it isn't the last one, if its affinity was changed, or if the wq is marked exit-on-idle. It decides so after it found the work list empty, and until io_worker_exit() is through it stays on the free list and in ->nr_running: worker io_wq_enqueue() io_acct_run_queue() == false queues work io_acct_activate_free_worker() wake_up_process(worker) // found one, nothing to create acct->nr_workers-- break io_worker_exit() Nobody is going to look at the work. If other workers exist, it has to wait until one of them finishes what it is blocked on or hits its idle timeout. If not, which is possible for the affinity and the exit-on-idle case, it sits there until something else is queued. For exit-on-idle it takes a task that closes its last ring and sets up a new one while the workers are on their way out. Make the worker take itself off the free list when it gives up its ->nr_workers slot, then leave ->nr_running, and only then take the final look at the work list. That look and queueing work are both done under acct->lock, so either the worker sees the work and stays, or the enqueue side sees that the worker is gone and wakes or creates another one. If it wants to stay and finds that its slot has been taken, a worker has been created in its place, which is going to look at the work list, and it can leave after all. [ 6.12: ->nr_workers and the free list are under wq->lock, there is no acct->workers_lock ] Fixes: 38aa434ab933 ("io_uring/io-wq: add exit-on-idle state") Fixes: 05c5f4ee4da7 ("io-wq: get rid of FIXED worker flag") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:37 2026 +0000 io_uring/io-wq: let cancel find picked up hashed work Commit e9efeb4fc97b0879512a3c3b995ed448f2487e12 upstream. io_get_next_work() takes all the work items that share a hash off the work list in one go, and the worker runs them one after the other. Only the one it is working on is visible as ->cur_work. The others are neither on the list nor current, so io_wq_cancel_cb() can't find them. IORING_OP_ASYNC_CANCEL and IORING_REGISTER_SYNC_CANCEL return -ENOENT for a request that has not even been started, e.g. a buffered write queued behind another write to the same file that is blocked, and the request is carried out. The cancellation done for a task or ring that goes away gets there in the end, as it keeps trying, but it has to wait for each item to become current. Keep a pointer to the remainder of the chain next to ->cur_work, and have io_wq_worker_cancel() look at it. The items on it belong to the worker, which needs ->lock to move on to the next one. Matching work is flagged with IO_WQ_WORK_CANCEL and fails with -ECANCELED when its turn comes. The worker isn't signalled for it, that would interrupt the unrelated work it is busy with. As the request isn't gone yet, it is reported like running work, with -EALREADY. Fixes: 86f3cd1b589a ("io-wq: handle hashed writes in chains") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:00 2026 +0000 io_uring/kbuf: handle index wrap in last buffer check Commit 6e773b5161506a4d0e739eb3aa4667d28f20219c upstream. io_ring_buffer_select() flags the request with REQ_F_BL_EMPTY if it takes the last buffer of the ring. Head and tail are 16-bit counters, but "head + 1" is computed as an int. If head is 65535 and tail has wrapped to 0, that compares 65536 to 0 and the flag isn't set. A bundle receive relies on the flag to tell that there is no point in trying to get more data. Without it, it goes for another round, finds no buffer, and the request, which has received data, is marked as failed on account of the -ENOBUFS. That severs a link, and ends a multishot. Fixes: c3f9109dbc9e ("io_uring/kbuf: flag request if buffer pool is empty after buffer pick") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:58 2026 +0000 io_uring/napi: don't busy poll past an expired timeout Commit 21ed976c12f6b77d7ea028a4fe9a08e69a56179f upstream. __io_napi_busy_loop() caps the busy poll time to what is left until the timeout of the wait. The difference is negative if the timeout has passed already, which is what an application gets if it uses IORING_ENTER_ABS_TIMER with a time that isn't in the future any more. The min_t(u64, ...) turns that into a huge value, so the cap has no effect and the wait, which should return right away, spins for the full busy poll time first. Fixes: d5cce407e4f5 ("io_uring/napi: postpone napi timeout adjustment") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:57 2026 +0000 io_uring/napi: make stale entries time out after 60s Commit 9c151648780d89e5446e5f89f3fa2e416c3bb911 upstream. With dynamic tracking a NAPI id that hasn't been seen for a minute is meant to be dropped from the list the ring busy polls. The timeout is added to jiffies, but it is defined as 60 * SEC_CONVERSION, and SEC_CONVERSION isn't the number of jiffies in a second. It is the internal factor of __timespec64_to_jiffies(), HZ scaled up by SEC_JIFFIE_SC bits. For HZ=1000 that is 1000 << 22, which puts the timeout at about eight years. On 32-bit the multiplication overflows. So entries are never removed, and every id that a socket of the ring ever had keeps being polled on each wait. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:04 2026 +0000 io_uring/net: don't retry recv on uncommitted buffers Commit 8444de681a179e41a4eb92d5bbe770a0677074a6 upstream. Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") commits ring provided buffers when a receive is going to be retried after a partial transfer, so that another request using the same buffer group can't be handed the memory the first one keeps receiving into. It commits the number of bytes received so far. That does the job for a single buffer which is consumed as a whole, but the request hangs on to all it has mapped: - For a buffer ring with IOU_PBUF_RING_INC only these bytes are consumed. The rest of the buffer stays at the head of the ring. - For a bundle only the buffers which hold these bytes are consumed, the others that were peeked stay in the ring. In both cases the next receive with that buffer group gets memory that the retried request is still going to write to, and whoever comes last overwrites the data of the other. What the retry fills isn't committed at all, as the buffer list isn't known any more at that point. So the kernel hands it out again later on, while the CQE tells the application that it was used, and for an incremental buffer that it is done with. The remainder can't be committed in advance: if the request ends up receiving less, there is no way to tell the application that more was consumed than the CQE accounts for. Complete the request with what it has got instead of retrying it. MSG_WAITALL is no longer honoured for receives into incremental buffers or multi buffer bundles, they can return a short count, with the request marked as failed like for other short MSG_WAITALL transfers. Fixes: 41b70df5b38b ("io_uring/net: commit partial buffers on retry") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tamaki Yanagawa <[email protected]> Date: Sun Oct 18 04:22:32 2026 +0000 io_uring/net: keep recv buffer select length within MAX_RW_COUNT Commit 96262cfab554cf11412de7a6247f0e82c94e130f upstream. Since commit dcbd1c054848 ("io_uring/net: let io_recv_buf_select return the length of the buffer region"), io_recv_buf_select() returns the selected length as an int. For a non-bundle recv with sqe->len == 0 the length comes from the ring provided buffer, which can be up to 4G, so a buffer of 2G or more makes io_recv() fail the request with a bogus negative result (e.g. -2147483648) instead of receiving into it. Clamp the length to MAX_RW_COUNT, which import_ubuf() limits the transfer to anyway. Fixes: dcbd1c054848 ("io_uring/net: let io_recv_buf_select return the length of the buffer region") Cc: [email protected] Signed-off-by: Tamaki Yanagawa <[email protected]> Assisted-by: Claude:claude-opus-5-5 Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Juanlu Herrero <[email protected]> Date: Tue Oct 13 15:37:20 2026 -0700 io_uring/poll: avoid retry wakeup loss when dropping ownership Commit 937d38dcacd675dc0572d6c9b6743960df3128ed upstream. If a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check of io_poll_check_events(), then we stall on processing the request until an unrelated wakeup comes along. Using atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wake-ups are missed. Cc: [email protected] Fixes: a26a35e9019f ("io_uring: make poll refs more robust") Signed-off-by: Juanlu Herrero <[email protected]> Assisted-by: LLM Suggested-by: Anand Natarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Fri Oct 16 09:15:13 2026 -0600 io_uring/poll: don't loop on HUP with multiple references Commit 67bb1ad9a517bedf1e1599fe5448620b9f38bf2a upstream. io_poll_check_events() drops down to one reference when a multishot request sees HUP with more than one, so that the loop goes around once more. It did so by subtracting one less than it had. With the cmpxchg that only takes the local count down: the exchange fails, the next pass reads the unchanged count, and goes through the same motions again. The loop then only ends once io_poll_issue() stops the request. Drop the extra references from the counter instead, and loop once more without trying the exchange. The next pass sees one reference, like it did before, and ends unless a wake up came in. Fixes: 937d38dcacd6 ("io_uring/poll: avoid retry wakeup loss when dropping ownership") Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:38 2026 +0000 io_uring/poll: don't lose a cancel as io-wq arms poll Commit 6d2d4c2530e95ff6ddeb98195d49d99dbca14369 upstream. A request on a pollable file that was forced to io-wq is issued without blocking there. If that ends in -EAGAIN, io_wq_submit_work() arms poll for it and returns. It looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request in between finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_issue_sqe() = -EAGAIN io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY io_poll_cancel() = -ENOENT ... = -ENOENT io_arm_poll_handler() = IO_APOLL_OK return Nobody looks at the flag again, and the signal doesn't matter to a worker that doesn't sleep. The request is armed as if nothing had happened: - a linked timeout completes with -ENOENT, and the request it was meant to limit waits for as long as it takes. - IORING_OP_ASYNC_CANCEL returns -EALREADY, and the request stays. - IORING_REGISTER_SYNC_CANCEL waits for the request to complete if it gets -EALREADY. Since commit 5623eb1ed035 ("io_uring/tctx: add separate lock for list of tctx's in ctx") it doesn't sleep but spins, so its next attempt finds the armed poll. The same goes for a multishot poll, recv or accept that is armed from io-wq. With a read of an empty pipe, IOSQE_ASYNC, and a linked timeout of 5ms or a cancel in the same submission, in a guest that is slow enough (TCG, KASAN), the request is lost in 21 of 24 rounds of 40 or 100 attempts. While it arms poll from io-wq, __io_arm_poll_handler() owns the request. Look at the flag once the request is in the hash table. The table is searched and the request is added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. With the request marked as cancelled, the task work that is queued, right away or because ownership can't be released, fails it with -ECANCELED. What the canceller is told doesn't change. In this window a linked timeout still completes with -ENOENT rather than -ETIME, a cancel request with -EALREADY, and one with IORING_ASYNC_CANCEL_ALL or _ANY with a count that doesn't include the request. But the request is cancelled, so what is new is a request that completes with -ECANCELED after such a result. This doesn't help in two cases: - IORING_ASYNC_CANCEL_ALL and _ANY, if the work is flagged after the test added here, while io-wq still has it as the current work of the worker. io_cancel_cb() stamps it with the sequence of the cancel, so the search of the hash table on behalf of the same cancel takes it for done and skips it. - requests that are parked elsewhere by io-wq, like IORING_OP_FUTEX_WAIT and IORING_OP_WAITID. They have the same problem. Fixes: 90fa02883f06 ("io_uring: implement async hybrid mode for pollable requests") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:45 2026 +0000 io_uring/poll: drop stale double poll entry on rearm Commit f2dbe87968a3aef74a11c025776d293b80964d3f upstream. A file that uses two wait queues for poll, e.g. a tty, gets a second io_poll entry, which IORING_OP_POLL_ADD keeps in ->async_data until the request is freed. io_poll_add() can run more than once for a request though: IORING_OP_POLL_REMOVE with one of the update flags disarms and rearms it, and io_poll_task_func() reissues it if a wake up turns out to be spurious. The second poll_wait() of the new round then finds *poll_ptr set, with ->head cleared by the disarm, and __io_queue_proc() fails what it takes for a third wait queue with -EINVAL. For an update that means that the poll request is completed with -ECANCELED, while the update itself reports success. For a spurious wake up, e.g. tcsetattr() on the polled tty, the poll request fails with -EINVAL. Free the old entry and clear the poll flags before arming, which is what io_arm_apoll() does for internal polling. All entries have been removed from their wait queues at that point. [ 6.12: no io_req_async_data_free(), open-coded ] Fixes: b69de288e913 ("io_uring: allow events and user_data update of running poll requests") Fixes: 6e5aedb9324a ("io_uring/poll: attempt request issue after racy poll wakeup") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:01 2026 +0000 io_uring/sqpoll: let the thread sleep on disabled rings Commit d492dcbb3b81c1c2d0aabef41fa1307093f3a556 upstream. __io_sq_thread() doesn't submit anything as long as the ring has IORING_SETUP_R_DISABLED set. The check that keeps the SQPOLL thread from going to sleep while the SQ ring holds entries doesn't know about that. If an application fills in SQEs first and enables the ring later, the thread finds that there is work each time it is about to sleep, goes around, doesn't submit it, and so on. It uses up a CPU until the ring gets enabled. Entries in the SQ ring of a disabled ring are no reason to stay awake. io_register_enable_rings() clears the flag and then wakes the thread, and the flag is looked at after prepare_to_wait(), so the thread can't miss that. Fixes: 0298ef969a11 ("io_uring: clean R_DISABLED startup mess") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:06 2026 +0000 io_uring/timeout: don't end a linked timeout with 1 Commit c74193430febdd120e35936dda3e5aeec3a54405 upstream. A linked timeout that fires cancels the request it is linked to, and completes with -ETIME if that worked out: ret = io_try_cancel(req->tctx, &cd, 0); ... io_req_set_res(req, ret ?: -ETIME, 0); io_try_cancel() returns 0 or an error, except for requests that are parked on ->futex_list or ->waitid_list. io_futex_cancel() and io_waitid_cancel() return the number of requests that they have cancelled, and io_try_cancel() hands it on. So the linked timeout of an IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV or IORING_OP_WAITID that it has cancelled completes with 1, each time. The waitid test of liburing checks for that 1, and has to be changed to expect -ETIME, which is what the linked timeout of any other request completes with. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Oct 15 14:25:00 2026 -0600 io_uring/timeout: don't flush with the sequence behind the last flush Commit 85f85d573ffa7772e1ad4504d0cec5113a5c5cf1 upstream. io_flush_timeouts() measures the events since the last flush as the distance of the current sequence from ->cq_last_tm_flush. A fired timeout bumps ->cq_timeouts before its CQE is posted, so until it is the sequence can be behind the last flush, and the distance wraps: last flush: seq 100, cq_last_tm_flush = 100 Y: IORING_OP_TIMEOUT, off 50, target_seq 150 pure timeout A fires, cq_timeouts = 1 task_work posts A's CQE, cached_cq_tail = 101 pure timeout B fires before the flush, cq_timeouts = 2 io_flush_timeouts(): seq = 99, events_got = 0xffffffff Y, and every sequence timeout behind it, is ended with -ETIME although no event happened. Two timeouts expiring close together is all it takes, a completion with IOSQE_CQE_SKIP_SUCCESS after a single one does it too. Nothing but those in flight CQEs separates the two, so count from the last flush when the sequence is behind it, as io_timeout() does. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Oct 15 16:38:45 2026 -0600 io_uring/timeout: don't lose a cancel as io-wq arms a timeout Commit 89f193dc3ef462059387e9691bf6af4b1808379a upstream. An IORING_OP_TIMEOUT run by io-wq, because of IOSQE_ASYNC, has the same problem as poll, futex and waitid. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain, while the worker then adds the request and starts the timer: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() adds the request to ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again, and the timeout runs its course. At ring exit, io_uring_try_cancel_requests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout. Look at the flag under ->timeout_lock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list. [ 6.12: ->timeout_lock is a spinlock here ] Fixes: ce35a47a3a02 ("io_uring: add IOSQE_ASYNC") Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Oct 15 14:18:22 2026 -0600 io_uring/timeout: don't put a sequence target behind the last flush Commit fdfce905a58edea053ee7b68b5bd4348dd1b36e0 upstream. io_timeout_fn() and io_kill_timeout() bump ->cq_timeouts when a timeout fires, but its CQE is only posted later from task_work. Until then the sequence io_timeout() computes is one below the last flush per fired timeout. Now that ->cq_last_tm_flush is kept while sequence timeouts are pending, a timeout armed in that window with a small offset gets a target behind the base. Its distance from the base wraps, and it's never completed by events, only by its timer. With DEFER_TASKRUN that window is as wide as the application makes it, as submission runs before the local task_work. Nothing but those in flight CQEs separates the two, so use the last flush as the base for the target when the sequence is behind it. Fixes: c6c0b3eba88c ("io_uring/timeout: don't skip over reached sequences") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:53 2026 +0000 io_uring/timeout: don't skip over reached sequences Commit c6c0b3eba88c3b13ca11ea112404982e86d58f7a upstream. io_flush_timeouts() copes with the wrap of the CQ sequence by looking at the distance from ->cq_last_tm_flush. That relies on the target of each pending timeout being at or ahead of the last flush. io_timeout() breaks that. It sets ->cq_last_tm_flush to the current sequence, on the assumption that nothing has been posted since the last flush. That isn't true. A multishot request posts its CQEs right when it is issued or retried, but they are committed, and the timeouts flushed, at the end of the submission or task_work run: X: IORING_OP_TIMEOUT, off == 1 target_seq == N + 1 io_submit_sqes() multishot recv, posts two CQEs sequence == N + 2 Y: IORING_OP_TIMEOUT, off == 100 ->cq_last_tm_flush = N + 2 io_flush_timeouts() X: events_needed = N + 1 - (N + 2) // 0xffffffff events_got = 0 // not yet X isn't completed although the completions it was waiting for have happened, only its timer can end it now. And as the list is sorted and the walk ends at the first timeout that isn't due, it gets in the way of the ones behind it. The insertion sort has the same problem, it measures the distance of the pending targets from the current sequence. ->cq_last_tm_flush only needs to be brought up to date if no timeout is waiting for a sequence, as io_flush_timeouts() isn't called before the first one is set up. Otherwise it is current enough. Timeouts with a sequence come first in the list, so looking at the first entry will do. Use the last flush as the base for the insertion sort as well. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:54 2026 +0000 io_uring/timeout: keep repeat count on multishot update Commit 3dc2a32cd356ee382aa4a8c7d844c53b2c0ad83b upstream. IORING_TIMEOUT_UPDATE clears ->off of the timeout it updates, to turn a timeout that waits for a number of completions into a pure one. For a multishot timeout ->off isn't a sequence though, it tells whether the number of repeats is limited: io_timeout_finish() only looks at ->repeats if ->off is set. A multishot timeout that was set up to fire N times hence fires forever once its interval has been updated. Leave ->off alone for those, they are never treated as sequence timeouts anyway. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:05 2026 +0000 io_uring/timeout: no ABS update of multishot timeouts Commit b088ae34d4da730dc647261b893a6eb622fe5e1f upstream. IORING_TIMEOUT_MULTISHOT can't be combined with IORING_TIMEOUT_ABS, prep rejects that, as the request is armed again with the same value each time it fires. IORING_TIMEOUT_UPDATE doesn't check and takes an absolute time for a multishot timeout. The first expiry is as asked for, but io_timeout_complete() then arms the timer with ->mode of the original request, i.e. it uses the absolute time as the interval. With CLOCK_MONOTONIC the next expiry is an uptime away, with CLOCK_REALTIME more than fifty years. Fail such an update with -EINVAL, and do so before the timeout is touched. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:27 2026 +0000 io_uring/wait: don't spin on a stuck overflow list Commit 34f5a664c34d3cb62f6bec7f4156754594a7d25b upstream. As long as IO_CHECK_CQ_OVERFLOW_BIT is set, io_cqring_wait_schedule() returns right away, before it gets to look at signals or arms the timeout, for io_cqring_wait() to flush the overflow list. If that doesn't empty the list, and the CQ ring doesn't hold the number of events the caller wants, the loop starts over, with the same result. The task spins in the kernel, and can't be killed. The assumption is that this can't happen: if CQEs can't be flushed, the ring is full, and min_events is capped to the size of the ring. But: - With IORING_SETUP_CQE_MIXED a 32b CQE needs two contiguous entries. It is stuck on the list if a single one is free, and then the ring holds less than cq_entries events. A single threaded application that asks for as many events as the ring has entries never gets out of io_uring_enter(). - Whether the ring is full is up to the CQ head, which the application can write to. While one thread waits for events on an empty ring, another one can move the head back so that the ring looks full and have a CQE overflow. The waiter can't be stopped any more, not even by SIGKILL. Only the application can make room in the CQ ring. Return to it if the list could not be flushed. [ 6.12: io_cqring_wait() is in io_uring.c ] Fixes: 3fcf19d592d5 ("io_uring: parse check_cq out of wq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:44 2026 +0000 io_uring/wait: look at all CQ waiters on wake up Commit 356f92f2412686f822383b784fa102924407457a upstream. io_wake_function() returns -1 if the waiter it is called for doesn't have enough events yet, which makes __wake_up_common() stop walking the wait queue. That assumes that the waiters behind it can't be satisfied either. Each waiter has its own target though, computed from the min_complete it passed in: thread A: io_uring_enter(GETEVENTS, min_complete = 10) // queued first thread B: io_uring_enter(GETEVENTS, min_complete = 1) one CQE is posted: A isn't woken, and B isn't even considered B keeps sleeping with the event it asked for sitting in the CQ ring, until A's demand is met or a timeout or signal ends the wait. Return 0 to carry on with the next waiter. Only waiters whose condition is met are woken, like before. [ 6.12: io_wake_function() is in io_uring.c ] Fixes: bda521624e75 ("io_uring: make CQ ring wakeups be more efficient") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:56 2026 +0000 io_uring/wait: no early -ETIME if min_wait finds work Commit 83cce67298ab1f4d2e9205a49f56975475cdb154 upstream. When the min wait time is over and there is work to run, which for DEFER_TASKRUN includes task_work that was queued lazily and didn't wake the waiter, io_cqring_min_timer_wakeup() ends the wait via io_cqring_timer_wakeup(). That flags it as timed out. io_cqring_wait() runs the work, leaves the loop, and returns 0 if the CQ ring holds something. Running task_work doesn't have to result in a CQE, though. A poll wake up can turn out to be spurious, for instance if somebody else has read the data by the time the request is retried. The application then gets -ETIME once the min wait time has passed, no matter how far away the timeout it asked for is. Wake the task without declaring a timeout. From now on a single CQE satisfies the wait, like in the case where the timer is switched over to the normal timeout. If running the work doesn't post one, the loop in io_cqring_wait() goes back to sleep with the normal timeout. [ 6.12: io_cqring_min_timer_wakeup() is in io_uring.c ] Fixes: 1100c4a2656d ("io_uring: add support for batch wait timeout") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Austin Schuh <[email protected]> Date: Sat Oct 17 10:17:26 2026 -0700 io_uring/wait: wake real-time waiters from hard interrupt context Commit 5b01d5955ac206e38097f777eff6ab2a8b948c41 upstream. Since commit cebf123c634a ("io_uring: implement our own schedule timeout handling"), a CQ wait with a timeout sleeps on io_uring's own hrtimer instead of an hrtimer sleeper. On PREEMPT_RT, an hrtimer that isn't marked for hard interrupt expiry expires in the per-CPU ktimers thread, which runs at SCHED_FIFO 1. A real-time task waiting in io_uring_enter() is therefore not woken at its deadline while any other real-time task is runnable on its CPU: the wakeup waits until every one of them has blocked. hrtimer sleepers, which schedule_hrtimeout_range_clock() used to give io_uring, don't have this problem: __hrtimer_setup_sleeper() marks the timer hard when the sleeping task is in a real-time or deadline class. Both of io_uring's callbacks are fine in hard interrupt context: io_cqring_timer_wakeup() sets a flag and calls wake_up_process(), and io_cqring_min_timer_wakeup() only reads ring state, under RCU, before doing the same or re-arming the timer. Apply the sleeper rule to them. Measured on a Jetson Orin Nano running 6.18.39-rt with this change backported: a SCHED_FIFO 40 task waits in io_uring_enter() for 40,000 deadlines 500us apart, while a SCHED_FIFO 20 task runs bursts of up to 1ms on the same CPU. Before, 6,647 wakeups were more than 100us late, the latest by 1,040us, and 2,758 deadlines passed without a wakeup at all. After, none were more than 100us late and the latest was 18us. This mirrors epoll: epoll_pwait2() waits on an hrtimer sleeper, so its timeout is already hard for real-time tasks, and on the same setup it was never more than 17us late. [ 6.12: the wait code is still in io_uring.c, hrtimer_init_on_stack() API ] Fixes: cebf123c634a ("io_uring: implement our own schedule timeout handling") Cc: [email protected] Assisted-by: LLM Signed-off-by: Austin Schuh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:25 2026 +0000 io_uring/waitid: own the request before clearing ->head Commit c254eec4364b9f4b4cbdce43be3fb4df5a651a70 upstream. io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless. Fixes: ab673c1bcaf2 ("io_uring/waitid: use io_waitid_remove_wq() consistently") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junyeong Lee <[email protected]> Date: Tue Oct 20 00:21:00 2026 +0900 io_uring/waitid: prevent cancel reference wrap Commit 98787d3fa4e99564d2b2bc21255b21f670c450d0 upstream. io_waitid packs the cancellation state into bit 31 of ->refs and uses bits 30:0 as a 31-bit reference counter: #define IO_WAITID_CANCEL_FLAG BIT(31) #define IO_WAITID_REF_MASK GENMASK(30, 0) __io_waitid_cancel() marks a request canceled, then increments the low bits of ->refs to claim completion ownership. When another path owns the request, the increment remains even though cancellation returns false. The request remains discoverable by cancellation, so repeated failed attempts can wrap the 31-bit reference field to zero. A later cancellation can claim ownership and complete the request a second time. Use atomic_fetch_or() when setting the cancel flag and inspect the old flag value. The first cancel attempt continues to the existing ownership increment, preserving its wake and issuer handoff semantics. Later attempts see the cancel flag and return without incrementing the reference field. This makes repeated failed cancellation attempts idempotent while leaving the first-cancel state transitions unchanged. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: [email protected] Assisted-by: LLM Signed-off-by: Junyeong Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:30 2026 +0000 io_uring: don't flood a cancelling task with task_work Commit 22e643e61b9b6299b42ff7d88bab48bccada8a5d upstream. io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round. Fixes: d56d938b4bef ("io_uring: do ctx initiated file note removal") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:39 2026 +0000 io_uring: don't lose a cancel as io-wq parks a request Commit 5cb049d2203d7a81a1c1a737c8df4575e71078e3 upstream. IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV and IORING_OP_WAITID don't block. They put the request on a list of the ring, where a wake up or a cancellation finds it, and return IOU_ISSUE_SKIP_COMPLETE. They do so as well if they are run by io-wq, e.g. because of IOSQE_ASYNC. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request after that, and before it is on the list, finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY ... io_futex_cancel() = -ENOENT ... io_futex_wait() adds the request to ->futex_list = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again. IORING_OP_ASYNC_CANCEL returns -EALREADY and the request stays. It is the problem that "io_uring/poll: don't lose a cancel as io-wq arms poll" deals with for poll. Look at the flag once the request is on the list, and cancel it if it is set. The lists are searched and the requests are added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. What the canceller is told doesn't change, see the other patch, also for IORING_ASYNC_CANCEL_ALL and _ANY. [ 6.12: __io_futex_cancel() and __io_waitid_cancel() take the ctx as well. futex_wait_setup() returns with the hash bucket locked and the futex_q not queued yet, so io_futex_wait() queues it before the check, with ->uring_lock still held ] Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Fixes: 8f350194d5cf ("io_uring: add support for vectored futex waits") Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:03 2026 +0000 io_uring: don't pass restart error codes to userspace Commit e1a64bc64897f4c2fe460922c345f2ed8f889b5f upstream. -ERESTARTSYS and friends are instructions for the system call exit code, which either restarts the call or turns them into -EINTR. They are not supposed to be seen by applications. A request isn't a system call, nobody looks at what it returns before that is put into a CQE. The read/write and the networking opcodes convert these codes to -EINTR by hand. The others don't. An io-wq worker that is blocked in the open of a FIFO, a tty or some other device, or in a splice from an empty pipe, and that gets interrupted because the request is cancelled, completes it with -512: IORING_OP_OPENAT, IOSQE_ASYNC // FIFO without a writer IORING_OP_ASYNC_CANCEL // -EALREADY, worker is signalled CQE of the open: res == -512 There are more candidates, like whatever a file system or driver returns from ->flush(), ->fsync(), ->fallocate() or ->uring_cmd(), or breaking a lease or delegation. Take care of it in io_issue_sqe(), which all of them go through. The helper is moved from rw.c as is. The cost is a compare and a branch that is not taken per request. Fixes: 15b71abe7b52 ("io_uring: add support for IORING_OP_OPENAT") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:31:07 2026 +0000 io_uring: look up the file before queueing to io-wq Commit 98bc044d5a5374f8d3605fe55a8e2df6d6fc3f82 upstream. io_prep_async_work() decides by the file of a request what kind of work it is for io-wq. I/O on regular files and block devices is bounded work, limited to min(SQ entries, 4 * CPUs) workers, for anything else that may block indefinitely the limit is RLIMIT_NPROC. Writes to a regular file are hashed by the inode, so that they are run one after the other instead of having a bunch of workers fight for the inode lock. Since the file is only assigned when a request is issued, a request that is queued without an attempt to issue it, REQ_F_FORCE_ASYNC, doesn't have one at that point. io_prep_async_work() takes that for "not a regular file or block device": - Reads and writes end up as unbound work. 32 reads with IOSQE_ASYNC from a slow block device on a ring with 4 SQ entries get 32 workers, not 4. - Writes aren't hashed. Four buffered writes to one file get four workers, three of which do nothing but wait for the lock. The late assignment is for the benefit of links, where a request may use a fixed file that one of its predecessors installs. By the time a request gets to io_queue_iowq() these are done, it is as good as issued. Assign the file there. io_assign_file() moves up and is forced inline. With a third caller the compiler may stop inlining it, and every request that is issued would pay for a call. IORING_OP_SPLICE is left as it is, unbound and not hashed. The file of the request is where it writes to, which says nothing about how long it takes: a splice from an empty pipe or a socket into a regular file waits for its input. As bounded work, four of these on a ring with 4 SQ entries keep all other bounded work of the task from running, and as hashed work one of them blocks all writes to that file. REQ_F_FORCE_ASYNC is not only set for IOSQE_ASYNC. What changes, and brings back what was the case before the file assignment was deferred: - Requests with IOSQE_ASYNC or IOSQE_IO_DRAIN, and all requests that are submitted while a drain is active: reads and writes on regular files and block devices count against the limit for bounded workers, including the one set with IORING_REGISTER_IOWQ_MAX_WORKERS, so fewer of them run at the same time. - Of these, writes to one regular file are run one at a time, unless they are O_DIRECT and the filesystem has FOP_DIO_PARALLEL_WRITE. - IORING_OP_FALLOCATE and IORING_OP_FTRUNCATE, which always go to io-wq, are run one at a time per file, and in turn with these writes. - The descriptor or the fixed file slot is looked up when the request is queued, not when a worker gets around to it, so closing or replacing it in between no longer has an effect on the request. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Thu Oct 15 19:30:43 2026 +0000 io_uring: wake ring pollers for local task_work Commit b88902d8745a701d24275d012f0830e3628e2a22 upstream. With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, io_uring_poll() reports EPOLLIN if local work is pending. That only helps if the work is there at the time of the call. When DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->poll_wq, and the wake up in io_req_local_work_add() was replaced by waking the submitter directly. Since then ->poll_wq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to: submitter completion poll(ring_fd) io_uring_poll() // nothing yet schedule() io_req_local_work_add() // ->cq_wait_nr: nobody waits // sleeps on Wake ->poll_wq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring. [ 6.12: the code is in io_uring.c, ->poll_activated is a bitfield, and there is no IOU_F_TWQ_IN_WAKE to tell a wake up handler apart, so the wake up always goes through the RCU callback ] Fixes: 130bd686d9be ("io_uring: waitqueue-less cq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Co-Authored-By: Claude Fable 5.1 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zihan Xi <[email protected]> Date: Thu Aug 27 18:25:14 2026 +0000 ipv4: avoid divide by zero in fib_rebalance commit 5046d2880fec7d49ebed2fd2866747ee1d06ad71 upstream. fib_rebalance() computes the total eligible nexthop weight in one pass and programs upper bounds in a second pass. A concurrent change to ignore_routes_with_linkdown can make the first pass return zero while the second pass sees an eligible nexthop, resulting in division by zero. If the first pass reports a zero total, set each nexthop upper bound to -1 and skip the division. This matches the IPv6 fix in commit d2c26c2911dd ("ipv6: avoid divide by zero in rt6_multipath_rebalance") and preserves the lock-free rebalance path. Fixes: 0e884c78ee19 ("ipv4: L3 hash-based multipath") Cc: [email protected] Reported-by: Vega <[email protected]> Signed-off-by: Zihan Xi <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Thu Oct 22 15:09:57 2026 -0400 ipv4: udp: Create exceptions before socket matching [ Upstream commit 4c3499f79f8c7e8561266bcc220a18538cec0458 ] Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to create FNHEs that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ipv4_sk_update_pmtu() / ipv4_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the FNHE cache of the nexthop resolved by the no socket helpers and another in the FNHE cache of the nexthop used by the socket. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Cc: [email protected] Reported-by: Amit Klein <[email protected]> Reported-by: Noam Caspi <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ sashal: inlined udp_err_update_exception() in the udp_err() wrapper. ] Signed-off-by: Sasha Levin <[email protected]>
Author: K Prateek Nayak <[email protected]> Date: Wed Oct 21 11:29:44 2026 -0400 kernel/watch_queue: Use pipe_buf() to retrieve the pipe buffer [ Upstream commit 547476063e123e73fc3aea8432104ab092ffea84 ] Use pipe_buf() helper to retrieve the pipe buffer in post_one_notification() replacing the open-coded the logic. Suggested-by: Oleg Nesterov <[email protected]> Signed-off-by: K Prateek Nayak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]> Stable-dep-of: 5e531d62f1f8 ("watch_queue: Fix note pool publication race in watch_queue_set_size()") Signed-off-by: Sasha Levin <[email protected]>
Author: Srish Srinivasan <[email protected]> Date: Sat Sep 12 11:59:49 2026 +0530 keys/trusted_keys: return immediately after TPM unseal failure commit f92d0ccb05bf9089072cb067dda0dffd5394c4ef upstream. trusted_tpm_unseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed. Return immediately when unseal fails to preserve the original error. Cc: [email protected] # v5.15+ Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Srish Srinivasan <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang <[email protected]> Date: Fri Oct 9 13:11:59 2026 +0800 keys: Avoid the owner account dereference in named keyring lookup commit 51409aaa01f8602552c336009fd22b226b0cdf1d upstream. Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check. find_keyring_by_name() reads keyring->user->uid under keyring_name_lock, but that lock protects the keyring's name entry and allocation, not its separate key_user. A named session-keyring join can overlap a privileged KEYCTL_CHOWN on another CPU. If the keyring holds the last reference to its old dynamic key_user and the ownership transfer succeeds, the following ordering is possible: Named join Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock) Chown neither takes keyring_name_lock nor key_session_mutex, so it can free the old account between the pointer load and the UID read. The lookup then reads freed memory even though the keyring itself is alive. Use keyring->uid for the mapping check. key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check. KASAN report as below: BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500 Cc: [email protected] Fixes: 2ea190d0a006 ("keys: skip keys from another user namespace") Assisted-by: LLM Signed-off-by: Cen Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0002-v3-2baa8cad2bb554364e10@gmail.com Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang <[email protected]> Date: Fri Oct 9 13:52:16 2026 +0800 keys: Check the authorization payload in process keyring searches commit 0a0ec45bf577a9b4d4960567f20d3877ef480de9 upstream. An authorization payload and its saved credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the descendant paused after validation, the paths can interleave as follows: 1. The descendant enters search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790 Cc: [email protected] Fixes: e59428f721ee ("keys: Move the RCU locks outwards from the keyring search functions") Assisted-by: LLM Signed-off-by: Cen Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0004-v3-598361863b76bc25d58d@gmail.com Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Adrian Martinez <[email protected]> Date: Sat Oct 10 23:40:00 2026 +0300 KEYS: Fix key_reject_and_link() race with keyring restriction commit 0b157166e612b70f98a332b6c7be7eac6f8e9593 upstream. The restrict_link check in key_reject_and_link() is done before taking the keyring semaphore, racing with a concurrent keyring_restrict() that installs the restriction while holding the semaphore in write mode. Move the check to after __key_link_lock(), so it is done under the semaphore, matching the pattern used in __key_create_or_update(). Cc: [email protected] Fixes: 5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring") Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Adrian Martinez <[email protected]> Link: https://lore.kernel.org/r/CACO1+RT+m==BY+ZPkE+fo536D0qu3wog4xE1dfuXQ56g+=Qv=A@mail.gmail.com Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Tue Oct 13 16:12:51 2026 -0700 keys: make keyring indexes independent of kernel addresses commit de891c73c1cf41ac8de12c07fa2c84d6a912ad0c upstream. KEYCTL_READ returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides. Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit. Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diff_objects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced. Cc: [email protected] Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Assisted-by: Codex:gpt-6-astra Signed-off-by: Kyle Zeng <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang <[email protected]> Date: Mon Oct 19 22:57:21 2026 +0800 keys: Protect the read method check against type removal commit 925c84e3cc21caf09de92d9bcafab0147790debf upstream. keyctl_read_key() checks key->type->read without holding key->sem. A reference keeps the key alive, but does not pin the module containing its type. A surviving RxRPC key can therefore be read while AF_RXRPC is being unloaded: KEYCTL_READ task Module unload and key GC ---------------- ------------------------ lookup_user_key() permission / possession checks load key->type af_rxrpc_exit() unregister_key_type() GC: down_write(key->sem) GC: retype to key_type_dead GC: up_write(key->sem) unregister_key_type() returns free_module() read saved type's read member The final access can read freed module storage. The read invocation in __keyctl_read_key() is already protected by key->sem, but the earlier method check is outside that critical section. Move the method check into __keyctl_read_key(), after key_validate() and under its existing read hold on key->sem. The check and invocation then use the same protected type for length queries and every read retry. The GC cannot retype the key until the semaphore is released, and type unregistration waits for that GC pass before the module can be freed. Return -EOPNOTSUPP when validation succeeds and the type has no read method. A temporary buffer may now be allocated before this result; allocation and copying to userspace remain outside the semaphore. Assisted-by: LLM Cc: [email protected] # v5.10+ Fixes: d3ec10aa9581 ("KEYS: Don't write out to userspace while holding key semaphore") Suggested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Cen Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Reviewed-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0010-v7-fc85721ff5cfb9e33ac6@gmail.com Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang <[email protected]> Date: Fri Oct 9 13:11:03 2026 +0800 keys: Protect the type name while describing a key commit fced7238b7e80cf8aa688d5af976e4aa6e33c329 upstream. keyctl_describe_key() must keep the key type's name alive until kasprintf() has consumed it. The retained key reference keeps the key and its description alive, but does not pin the module providing its type. The name is passed to kasprintf() without holding key->sem. kvasprintf() uses the saved name pointer in two formatting passes, with a GFP_KERNEL allocation between them. With AF_RXRPC=m, a task that passes View permission before type retirement can overlap a privileged module unload in this order: 1. KEYCTL_DESCRIBE looks up the key, saves key->type->name in the kasprintf() arguments and completes the first formatting pass. 2. While the formatter is delayed before its second pass, af_rxrpc_exit() calls unregister_key_type(), which removes the type from the registry and waits for key_gc_keytype(). 3. The collector takes key->sem for writing, retypes the retained key to key_type_dead and completes retirement. Unregistration and module exit return, allowing free_module() to release the type and name. 4. The formatter resumes its second pass and reads the saved name from released module storage, which can fault in string(). Hold key->sem for reading across kasprintf(). The collector then cannot retype the key or complete retirement until both formatting passes have finished. If retirement wins the lock first, formatting uses the core key_type_dead name instead. Release the semaphore immediately after kasprintf(), including on allocation failure, before copying to userspace. Oops report as below: BUG: unable to handle page fault for address: fffffbfff8054794 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:string+0x23f/0x470 Call Trace: vsnprintf+0x330/0x1110 Cc: [email protected] Fixes: aa9d4437893f ("KEYS: Fix the size of the key description passed to/from userspace") Assisted-by: LLM Signed-off-by: Cen Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0009-v4-6b537c5732fd957c33fa@gmail.com Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefano Garzarella <[email protected]> Date: Wed Sep 23 19:35:06 2026 +0200 KEYS: trusted: Fix blob allocation size in tpm2_key_decode() commit 11077cbcc2695f71c944a84a5f08c6672ab759f1 upstream. tpm2_key_decode() allocates 4 bytes more than needed. The ASN.1 callbacks tpm2_key_priv() and tpm2_key_pub() provide the lengths of TPM2B_PRIVATE and TPM2B_PUBLIC, so ctx.priv_len and ctx.pub_len already account for the 2-byte `size` field each of those structures starts with. I noticed this while reviewing commit 114f00d738f1 ("KEYS: trusted: Fix tpm2_load_cmd() boundary check"), which correctly reports ctx.priv_len + ctx.pub_len as the decoded blob size [1]. Let's allocate exactly that amount, matching the data copied into the blob. [1] https://lore.kernel.org/linux-integrity/apfoKo-BdwaLXtkT@sgarzare-redhat/ Cc: [email protected] # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Stefano Garzarella <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksandr Khromov <[email protected]> Date: Tue Aug 25 10:19:21 2026 +0900 ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION commit db2267b27c054a6c2151ff7fbb67927e784f31d6 upstream. smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION, that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns FileSysIdentifier. Those eight bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. Report the file system id statfs() returned, which is what the field is for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so assemble the value first, val[0] as the low half, and convert it on the way out. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Signed-off-by: Aleksandr Khromov <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksandr Khromov <[email protected]> Date: Mon Aug 24 21:23:32 2026 +0900 ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION commit c0cd3fc6824122014da2b3b0cb7ddeaa2946ec8e upstream. smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION, that is the whole of struct smb2_fs_control_info, but never assigns FileSystemControlFlags. Those four bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. ksmbd does not implement quota tracking, so report no control flags. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Signed-off-by: Aleksandr Khromov <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksandr Khromov <[email protected]> Date: Mon Aug 24 13:22:46 2026 +0300 ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in commit 399aa12450a61a5c73dc77e73f069ece9687c95d upstream. smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION, that is the whole of struct object_id_info, but writes only 46 of them: - objid[] is 16 bytes, and when the volume UUID is not available only sizeof(stfs.f_fsid) (8) bytes are copied into it; - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only strlen("1.1.0") (5) bytes are copied into it. The response buffer is zeroed on allocation (kvzalloc() in smb2_allocate_rsp_buf()), so for a standalone request the remaining 31 bytes are zero. In a compound request they need not be. The offset of the next response is advanced by the length pinned for the previous one, so if a preceding command wrote its reply into the buffer and then failed, smb2_set_err_rsp() pins only the short error response and the next reply lands inside the area that has already been written. Only the header is cleared there: memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2); The client then receives up to 31 bytes of a response it was not meant to see, including one that failed with an access denied error. Clear the structure before filling it in. As a side effect version_string is now NUL terminated. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Suggested-by: ChenXiaoSong <[email protected]> Cc: [email protected] Signed-off-by: Aleksandr Khromov <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amirmohammad Eftekhar <[email protected]> Date: Thu Oct 1 14:43:54 2026 -0700 KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry commit c8f4cfe1cf93bce924e27f2abead7a4c4a487505 upstream. Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails in the "not from VM-Entry" case, i.e. when emulating RSM or handling KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM trying to run L1 with a nested MMU, and is especially problematic if the vCPU manages to free its nested state before the VM crashes. Constructing the root for a nested EPT MMU goes through vmcs12, which is dynamically allocated/freed when nVMX is enabled/disabled. And so if the nested state is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL pointer deref when attempting to get L1=>L2 EPTP. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Call Trace: <TASK> kvm_mmu_load+0xcd/0x870 [kvm] kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x9c/0x4d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47491b </TASK> Modules linked in: kvm_intel kvm irqbypass CR2: 0000000000000078 ---[ end trace 0000000000000000 ]--- RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Cc: David Woodhouse <[email protected]> Fixes: 72e9cbdb4338 ("KVM: nVMX: fix SMI injection in guest mode") Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: [email protected] Signed-off-by: Amirmohammad Eftekhar <[email protected]> [sean: write changelog] Signed-off-by: Sean Christopherson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hyunwoo Kim <[email protected]> Date: Tue Oct 20 19:45:03 2026 -0700 KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots [ Upstream commit 7a2c70e777a00c32ebafd376a6fe31ebb91c5b20 ] kvm_mmu_zap_oldest_mmu_pages() excludes a shadow page whose root_count is non-zero from top-level reclaim, because such a page cannot be freed. The path in mmu_page_zap_pte() that recursively zaps a parentless nested TDP child has no such check. As a result, a shadow page can be zapped even if the page itself can't be freed; as the comment in kvm_mmu_zap_oldest_mmu_pages() notes, zapping it will just force vCPUs to rebuild the page. As in top-level reclaim, do not recursively prepare zapping of a nested TDP child whose root_count is non-zero. Fixes: 2de4085cccea ("KVM: x86/MMU: Recursively zap nested TDP SPs when zapping last/only parent") Signed-off-by: Hyunwoo Kim <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> [sean: resolve minor conflict due to lack of lockless aging in 6.12] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Fri Oct 30 13:05:25 2026 +0100 Linux 6.12.115 Link: https://lore.kernel.org/r/[email protected] Tested-by: Dominique Martinet <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: SJ Park <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Sean Lyon <[email protected]> Tested-by: Richard Narron <[email protected]> Tested-by: Barry K. Nathan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kaiwen Shi <[email protected]> Date: Sun Aug 30 07:05:51 2026 +0800 mac802154: fix data race and NULL deref on local->assoc_dev commit c037915f80c4db47f7d061d68e703ffd551b1a34 upstream. local->assoc_dev is shared between the association path and the association-response worker without common synchronization. mac802154_perform_association() stores the coordinator pointer and waits for a response. Its timeout and error paths clear the pointer and return to mac802154_associate(), which may then free the coordinator object. Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit and enter mac802154_process_association_resp(), which dereferences assoc_dev. The worker's bit test and the handler's pointer dereference are not atomic with respect to cleanup. Cleanup can clear assoc_dev between them, causing a NULL dereference, or free the coordinator while the response handler still uses the pointer. The recorded result is exposed to the same window. assoc_status and assoc_addr are written by the handler but read by the association path while the associating bit is still set, so a second response for the same request - a malicious one, for instance - can replace them between those reads and leave the caller with an incoherent status and address pair. The response handler only needs the coordinator extended address. Replace assoc_dev with a cached address, removing the pointer lifetime dependency. Protect the cached address and the associating bit with a dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee an atomic __le64 access on all 32-bit architectures. wpan_dev->association_lock cannot be reused here: nl802154_associate() holds it across rdev_associate(), hence for the whole of mac802154_perform_association() including the wait for the response. A response handler taking that lock would only get it once the association has already given up. Reset the completion, publish the cached address, and set the associating bit while holding the lock. The response handler takes the lock, rechecks the bit and the cached address, records the response, clears the bit, and only then completes the waiter. Thus cleanup cannot pass the handler between its state check and completion, and the cached 64-bit value cannot tear. The handler clears the bit before completing, not the woken waiter: otherwise complete() is issued under the lock and a second (e.g. malicious) response can reacquire it before the waiter and replace the result. So a wait that returns success implies the bit is already clear, and the success and negative-response paths return directly. The transmit-error and timeout paths still clear it under assoc_lock, which serializes any racing response against the cleanup while the call returns the error it already selected. Both paths snapshot assoc_status and assoc_addr under the same lock. Both users run in process context, so a plain spinlock is sufficient. The lock is not held while waiting for the completion. Suggested-by: Miquel Raynal <[email protected]> Suggested-by: Xuanqiang Luo <[email protected]> Fixes: fefd19807fe9 ("mac802154: Handle associating") Cc: [email protected] Signed-off-by: Kaiwen Shi <[email protected]> Reviewed-by: Xuanqiang Luo <[email protected]> Reviewed-by: Miquel Raynal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kairui Song <[email protected]> Date: Sun Dec 22 20:29:36 2024 +0800 mm, madvise: fix potential workingset node list_lru leaks [ Upstream commit 62e72d2cf702a5e2fb53d9c46ed900d9384e4a06 ] Since commit 5abc1e37afa0 ("mm: list_lru: allocate list_lru_one only when needed"), all list_lru users need to allocate the items using the new infrastructure that provides list_lru info for slab allocation, ensuring that the corresponding memcg list_lru is allocated before use. For workingset shadow nodes (which are xa_node), users are converted to use the new infrastructure by commit 9bbdc0f32409 ("xarray: use kmem_cache_alloc_lru to allocate xa_node"). The xas->xa_lru will be set correctly for filemap users. However, there is a missing case: xa_node allocations caused by madvise(..., MADV_COLLAPSE). madvise(..., MADV_COLLAPSE) will also read in the absent parts of file map, and there will be xa_nodes allocated for the caller's memcg (assuming it's not rootcg). However, these allocations won't trigger memcg list_lru allocation because the proper xas info was not set. If nothing else has allocated other xa_nodes for that memcg to trigger list_lru creation, and memory pressure starts to evict file pages, workingset_update_node will try to add these xa_nodes to their corresponding memcg list_lru, and it does not exist (NULL). So they will be added to rootcg's list_lru instead. This shouldn't be a significant issue in practice, but it is indeed unexpected behavior, and these xa_nodes will not be reclaimed effectively. And may lead to incorrect counting of the list_lru->nr_items counter. This problem wasn't exposed until recent commit 28e98022b31ef ("mm/list_lru: simplify reparenting and initial allocation") added a sanity check: only dying memcg could have a NULL list_lru when list_lru_{add,del} is called. This problem triggered this WARNING. So make madvise(..., MADV_COLLAPSE) also call xas_set_lru() to pass the list_lru which we may want to insert xa_node into later. And move mapping_set_update to mm/internal.h, and turn into a macro to avoid including extra headers in mm/internal.h. Link: https://lkml.kernel.org/r/[email protected] Fixes: 9bbdc0f32409 ("xarray: use kmem_cache_alloc_lru to allocate xa_node") Reported-by: [email protected] Closes: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Kairui Song <[email protected]> Cc: Chengming Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Qi Zheng <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Yu Zhao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: aca1f2d5de17 ("mm/huge_memory: initialise workingset state before folio split") Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Stoakes (ARM) <[email protected]> Date: Tue Oct 20 10:42:30 2026 +0100 mm/huge_memory: bypass THP tuneables for huge pfnmap mappings [ Upstream commit e384abeb559d10d6505aec053ede9368d81d4c71 ] The sysfs THP tuneables at /sys/kernel/mm/transparent_huge_pages/ rather confusingly only control the behaviour of THP in some instances. They are not applicable to MADV_COLLAPSE operations, nor to DAX mappings. Long-term, THP is predicated upon compaction being able to obtain large folios to populate THP ranges. However, vm_normal_folio() returns NULL for PFN map mappings, thus their reference count is maintained by the driver, not core mm. As a consequence, the folios are not subject to reclaim nor compaction, so are not truly part of the THP mechanism at all. However, since commit 5dd40721f147 ("mm: allow THP orders for PFNMAPs") introduced the ability to establish huge PFN maps, they have been subject to THP tuneables. This is incorrect - if a huge PFN map is available (defined by vma->vm_ops->huge_fault being non-NULL for a VM_PFNMAP VMA), then it should be mapped huge upon fault-in. Correct this by explicitly checking for this while ensuring that smaps continues to accurately report THPeligible statistics. While here, abstract the entire file-backed THP check in vma_can_map_huge_file(), with sensible separation of logic into helper functions. Failing to map huge PFN maps has resulted in significant real-world performance degradation, see links for details. [[email protected]: rename some functions] Link: https://lore.kernel.org/[email protected] Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs") Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> Signed-off-by: Zi Yan <[email protected]> Reported-by: Cedric Le Goater <[email protected]> Closes: https://lore.kernel.org/linux-mm/[email protected]/ Reported-by: Saravanan D <[email protected]> Closes: https://lore.kernel.org/linux-mm/[email protected]/ Reviewed-by: Zi Yan <[email protected]> Tested-by: Saravanan D <[email protected]> Tested-by: Lance Yang <[email protected]> Reviewed-by: SJ Park <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> [ ljs - Converted to tva_flags, made file_thp_enabled() const in huge_mm.h + other smaller changes. Updated commit msg to reflect. ] Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matt Fleming <[email protected]> Date: Wed Oct 21 11:39:15 2026 -0400 mm/huge_memory: initialise workingset state before folio split [ Upstream commit aca1f2d5de17e138bc6c4859126b77e516b82541 ] xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but __folio_split() leaves the xa_state's xa_lru unset. That lets a live, memcg-charged xa_node exist without being linked into the mapping's shadow_nodes list_lru; when reclaim later walks the list_lru it trips VM_WARN_ON(!css_is_dying()). Use mapping_set_update() to install both the workingset update callback and the shadow_nodes list_lru on the xa_state. Link: https://lore.kernel.org/[email protected] Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()") Signed-off-by: Matt Fleming <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=c5b060ce82921a2fd500 Reviewed-by: Zi Yan <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Barry Song <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dev Jain <[email protected]> Cc: Kairui Song <[email protected]> Cc: Lance Yang <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Muchun Song <[email protected]> Cc: Nico Pache <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hyunwoo Kim <[email protected]> Date: Wed Aug 12 01:18:57 2026 +0900 mm/pagewalk: fix stale walk->action escaping walk_pmd_range() [ Upstream commit aedf2efd18977e0cef7eb963166e2b1fcc0aa321 ] If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry. In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE. This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect. This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried. In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are). The result is an out-of-bounds write, triggered by a local fuzzer: [ 2.272695] ================================================================== [ 2.273471] BUG: KASAN: slab-out-of-bounds in __mincore_unmapped_range+0x14f/0x190 [ 2.274302] Write of size 1 at addr ffff888008d9b000 by task poc/106 [ 2.274966] [ 2.275154] CPU: 0 UID: 1000 PID: 106 Comm: poc Not tainted 7.2.0-rc6-00429-ga7c7074b58d2 #55 PREEMPT(lazy) [ 2.275159] 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 [ 2.275164] Call Trace: [ 2.275170] <TASK> [ 2.275172] dump_stack_lvl+0x53/0x70 [ 2.275200] print_report+0xd0/0x630 [ 2.275210] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.275219] ? irqentry_exit+0xd2/0x670 [ 2.275224] ? irqentry_exit+0xd2/0x670 [ 2.275226] ? __virt_addr_valid+0xef/0x1a0 [ 2.275239] ? __mincore_unmapped_range+0x14f/0x190 [ 2.275242] kasan_report+0xce/0x100 [ 2.275245] ? __mincore_unmapped_range+0x14f/0x190 [ 2.275248] __mincore_unmapped_range+0x14f/0x190 [ 2.275252] mincore_unmapped_range+0x45/0x70 [ 2.275254] walk_pgd_range+0xafc/0xfc0 [ 2.275261] ? __pfx_walk_pgd_range+0x10/0x10 [ 2.275264] ? __update_load_avg_se+0x3d1/0x670 [ 2.275275] __walk_page_range+0xc0/0x310 [ 2.275278] ? __pfx_find_vma+0x10/0x10 [ 2.275281] ? finish_task_switch.isra.0+0x16d/0x4f0 [ 2.275290] walk_page_range_mm_unsafe+0x26f/0x3a0 [ 2.275293] ? __pfx_mtree_load+0x10/0x10 [ 2.275298] ? __pfx_walk_page_range_mm_unsafe+0x10/0x10 [ 2.275302] ? __free_frozen_pages+0x54d/0x7e0 [ 2.275308] __do_sys_mincore+0x132/0x380 [ 2.275311] do_syscall_64+0xf9/0x540 [ 2.275316] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.275322] RIP: 0033:0x422ccd [ 2.275326] Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 [ 2.275329] RSP: 002b:00007fffffffec18 EFLAGS: 00000287 ORIG_RAX: 000000000000001b [ 2.275337] RAX: ffffffffffffffda RBX: 0000000000000066 RCX: 0000000000422ccd [ 2.275339] RDX: 00000000004d0940 RSI: 0000000001000000 RDI: 00007ffff4000000 [ 2.275340] RBP: 00000000004d0940 R08: 0000000000000100 R09: 0000000000000100 [ 2.275342] R10: 0000000000000100 R11: 0000000000000287 R12: 20c49ba5e353f7cf [ 2.275343] R13: 00000000004990d3 R14: 0000000000000000 R15: 0000000000000001 [ 2.275346] </TASK> [ 2.275347] [ 2.296904] The buggy address belongs to the object at ffff888008d9b000 [ 2.296904] which belongs to the cache sigqueue of size 80 [ 2.298151] The buggy address is located 0 bytes inside of [ 2.298151] allocated 80-byte region [ffff888008d9b000, ffff888008d9b050) [ 2.299408] [ 2.299601] The buggy address belongs to the physical page: [ 2.300191] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8d9b [ 2.301001] flags: 0x100000000000000(node=0|zone=1) [ 2.301535] page_type: f5(slab) [ 2.301884] raw: 0100000000000000 ffff888107e46780 dead000000000122 0000000000000000 [ 2.302687] raw: 0000000000000000 0000000800240024 00000000f5000000 0000000000000000 [ 2.303489] page dumped because: kasan: bad access detected [ 2.304092] [ 2.304276] Memory state around the buggy address: [ 2.304801] ffff888008d9af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2.305567] ffff888008d9af80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2.306340] >ffff888008d9b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.307115] ^ [ 2.307474] ffff888008d9b080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.308237] ffff888008d9b100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.308997] ================================================================== A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry. Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check. The pattern also exists in walk_pud_range() so fix it there too. This issue was found through AI-based fuzzing. Link: https://lore.kernel.org/[email protected] Fixes: 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") Assisted-by: Claude:claude-opus-5 Signed-off-by: Hyunwoo Kim <[email protected]> Reviewed-by: Lorenzo Stoakes (ARM) <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Cc: Max Boone <[email protected]> Cc: Liam R. Howlett <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdul Wasey <[email protected]> Date: Mon Oct 19 11:15:41 2026 +0000 mptcp: move the OoO check back into __mptcp_try_fallback() The 6.12.y backport of upstream commit 1bba3f219c5e ("mptcp: do not fallback when OoO is present") put the out-of-order queue check in __mptcp_finish_join() instead of __mptcp_try_fallback(). So the fix itself is missing, as fallback still happens with OoO data queued. Worse, the passive side now refuses every MP_JOIN while its OoO queue is not empty, which is the normal state of a connection already sending data over more than one subflow. The joining subflow is reset, so such a connection can't add a new path, and a path that comes back after an outage can't rejoin while data is in flight. Move the check to __mptcp_try_fallback(), as upstream does. Tested on 6.12.113 in netns: 6 connections (5 uploading) over two paths, then a third endpoint added mid-transfer. Without this patch only the idle connection gets a subflow on the new path and the other 5 joins are reset. With it, all 6 join. Same result in 3 of 3 runs each. Fixes: aab400cf8e35 ("mptcp: do not fallback when OoO is present") Signed-off-by: Abdul Wasey <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Oct 12 14:57:04 2026 +0200 namei: test for a negative dentry the way traverse_mounts() does commit 98b6cf102b35b2bb48d1fd74d5f664eb66fe83eb upstream. lookup_fast_for_open() only hands an O_CREAT open a cached dentry if it's positive. Otherwise the open goes on to lookup_open(), which takes the directory lock and creates the file. It tests for that with !dentry->d_inode, but traverse_mounts() later decides with the type in d_flags. And when a dentry is instantiated __d_set_inode_and_type() stores ->d_inode first and only then releases the type into ->d_flags. So a refwalk that took its reference to a negative dentry right before another task instantiates it can find ->d_inode already set in lookup_fast_for_open(), go on to step_into(), and still find the negative type in traverse_mounts(). The open then fails with -ENOENT, which an O_CREAT open must never do. rcuwalk doesn't get that far, the d_seq check in step_into() catches the instantiation. Use d_is_negative() so both look at the type. While the type is still negative the open takes lookup_open() and waits for the directory lock like any other O_CREAT open of a negative dentry. On its own the window is a couple of instructions in the creating task, so it takes an interrupt or a preempted vcpu in exactly the right spot. I haven't caught it without help in about 600 million racing O_CREAT opens. The debug patch below stalls the creating task between the two stores for names starting with "ocrace", the way an interrupt landing there would. The reproducer below opens "ocrace" with O_CREAT through symlinks on a strictatime tmpfs: following them updates their atime, which drops the walk out of rcuwalk, so the name is always looked up in refwalk. With echo 20 > /proc/sys/fs/ocrace_instantiate_us ./ocreat_enoent -t 60 on a KASAN kernel open() failed with -ENOENT 43 times in 4.9 million calls. With this patch it never failed in 4.8 million calls. Tracing step_into_slowpath() during such a run, each of the 98 -ENOENTs it returned came right after the same task had entered it with a dentry that was still typed negative. // SPDX-License-Identifier: GPL-2.0 /* * ocreat_enoent: open(O_CREAT) racing the creation of the same name. * * Writers unlink "ocrace" and create it again. Readers open it with * O_CREAT through a symlink of their own on a strictatime tmpfs. * Following the symlink updates its atime, which drops the walk out of * rcu mode, so the name is always looked up in refwalk. An O_CREAT open * must never fail with ENOENT. * * -p arms a cpu-clock perf timer with that period in ns on every writer, * so that interrupts land at random points in it. * * usage: ocreat_enoent [-t secs] [-w writers] [-r readers] [-p ns] */ #define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <pthread.h> #include <stdatomic.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mount.h> #include <sys/stat.h> #include <sys/syscall.h> #include <unistd.h> #include <linux/perf_event.h> #define DIR "/tmp/oc" static atomic_int stop; static atomic_long opens, creates, enoent, other; static long period; static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void *writer(void *arg) { (void)arg; if (period) { struct perf_event_attr attr = { .type = PERF_TYPE_SOFTWARE, .size = sizeof(attr), .config = PERF_COUNT_SW_CPU_CLOCK, .sample_period = period, }; if (syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0) < 0) die("perf_event_open"); } while (!atomic_load(&stop)) { int fd; unlink(DIR "/ocrace"); fd = open(DIR "/ocrace", O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); atomic_fetch_add(&creates, 1); } return NULL; } static void *reader(void *arg) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", (long)arg); while (!atomic_load(&stop)) { int fd = open(lnk, O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); else if (errno == ENOENT) atomic_fetch_add(&enoent, 1); else atomic_fetch_add(&other, 1); atomic_fetch_add(&opens, 1); } return NULL; } int main(int argc, char **argv) { int secs = 60, nw = 4, nr = 12, c, n = 0; pthread_t t[256]; while ((c = getopt(argc, argv, "t:w:r:p:")) != -1) { switch (c) { case 't': secs = atoi(optarg); break; case 'w': nw = atoi(optarg); break; case 'r': nr = atoi(optarg); break; case 'p': period = atol(optarg); break; default: return 2; } } if (nw + nr > 256) return 2; mkdir(DIR, 0755); if (mount("oc", DIR, "tmpfs", MS_STRICTATIME, "mode=0755")) die("tmpfs"); for (long i = 0; i < nr; i++) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", i); if (symlink("ocrace", lnk)) die("symlink"); } for (long i = 0; i < nw; i++) if (pthread_create(&t[n++], NULL, writer, NULL)) die("writer"); for (long i = 0; i < nr; i++) if (pthread_create(&t[n++], NULL, reader, (void *)i)) die("reader"); sleep(secs); atomic_store(&stop, 1); for (int i = 0; i < n; i++) pthread_join(t[i], NULL); printf("%ds: %ld opens, %ld creates, ENOENT %ld, other errors %ld\n", secs, atomic_load(&opens), atomic_load(&creates), atomic_load(&enoent), atomic_load(&other)); umount2(DIR, MNT_DETACH); return atomic_load(&enoent) ? 1 : 0; } # diff --git a/fs/dcache.c b/fs/dcache.c # --- a/fs/dcache.c # +++ b/fs/dcache.c # @@ -32,9 +32,13 @@ # #include <linux/bit_spinlock.h> # #include <linux/rculist_bl.h> # #include <linux/list_lru.h> # +#include <linux/delay.h> # #include "internal.h" # #include "mount.h" # # +/* debug: stall "ocrace*" names between ->d_inode and the type */ # +static int sysctl_ocrace_instantiate_us; # + # #include <asm/runtime-const.h> # # /* # @@ -200,6 +204,13 @@ # } # # static const struct ctl_table fs_dcache_sysctls[] = { # + { # + .procname = "ocrace_instantiate_us", # + .data = &sysctl_ocrace_instantiate_us, # + .maxlen = sizeof(int), # + .mode = 0644, # + .proc_handler = proc_dointvec, # + }, # { # .procname = "dentry-state", # .data = &dentry_stat, # @@ -405,6 +416,10 @@ # unsigned flags; # # dentry->d_inode = inode; # + /* debug: an interrupt landing right here */ # + if (unlikely(READ_ONCE(sysctl_ocrace_instantiate_us)) && # + !strncmp(dentry->d_name.name, "ocrace", 6)) # + udelay(READ_ONCE(sysctl_ocrace_instantiate_us)); # flags = READ_ONCE(dentry->d_flags); # flags &= ~DCACHE_ENTRY_TYPE; # flags |= type_flags; Fixes: e747e15156b7 ("fs: try an opportunistic lookup for O_CREAT opens too") Cc: [email protected] # v6.12+ Link: https://patch.msgid.link/[email protected] Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alice Mikityanska <[email protected]> Date: Thu Feb 5 15:39:14 2026 +0200 net/ipv6: Introduce payload_len helpers [ Upstream commit b2936b4fd56294e49d6c8e9152ea6c4982757c7d ] The next commits will transition away from using the hop-by-hop extension header to encode packet length for BIG TCP. Add wrappers around ip6->payload_len that return the actual value if it's non-zero, and calculate it from skb->len if payload_len is set to zero (and a symmetrical setter). The new helpers are used wherever the surrounding code supports the hop-by-hop jumbo header for BIG TCP IPv6, or the corresponding IPv4 code uses skb_ip_totlen (e.g., in include/net/netfilter/nf_tables_ipv6.h). No behavioral change in this commit. Signed-off-by: Alice Mikityanska <[email protected]> Acked-by: Paolo Abeni <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 8070ed578b6b ("calipso: keep BIG TCP payload_len in calipso_skbuff_setattr()") Signed-off-by: Sasha Levin <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Aug 28 14:07:47 2026 -0500 net/iucv: fix the recvmsg window update commit fa5acd038ea657ad5033713d6916214cbd349151 upstream. iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which allocates GFP_KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where msg_recv is sampled for the advertised window and subtracted after dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomic_xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Fixes: 238965b71b96 ("net/af_iucv: build proper skbs for HiperTransport") Cc: [email protected] Tested-by: Aswin Karuvally <[email protected]> Signed-off-by: Bryam Vargas <[email protected]> Reviewed-by: Alexandra Winter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Allison Henderson <[email protected]> Date: Sat Oct 3 09:34:08 2026 -0700 net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure [ Upstream commit 98d446b7c013254a8a7b49720557676a3a851fde ] rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one. Fixes: 55b7ed0b582f ("RDS: Common RDMA transport code") Assisted-by: LLM Signed-off-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aohan Mei <[email protected]> Date: Wed Aug 26 10:51:20 2026 +0800 net/sched: cls_flower: validate mask pointer after nla_next() commit fee10655709c5c597e8e9f722f3035d9ea31ff3a upstream. fl_set_enc_opt() iterates the key's nested tunnel-option attributes with nla_for_each_attr() while advancing a single mask pointer via nla_next() at the bottom of each loop, so the mask cursor is driven by the number of key attributes rather than by the mask's own attributes. The nla_ok() added by commit c96adff956191 ("cls_flower: call nla_ok() before nla_next()") only validates the mask pointer that was just consumed; the pointer produced by nla_next() is used by the next iteration (fl_set_geneve_opt() and siblings) without any validation. The mask's nested attributes are validated with NL_VALIDATE_LIBERAL, which merely warns on trailing bytes that do not form a complete attribute. A mask carrying one valid attribute plus 1-3 residue bytes (or a non-aligned attribute length making msk_depth negative) therefore reaches the next iteration with msk_depth != 0, so neither the !msk_depth check in fl_set_enc_opt() nor the !depth check in the per-type helpers fires. nla_type() then reads past the mask payload and nla_parse_nested_deprecated() iterates with an nla_len taken from those bytes, reading well beyond the mask attribute (KASAN: slab-out-of-bounds read in __nla_validate_parse from fl_change()). Validate the advanced mask pointer as well: when the mask is not legitimately exhausted (msk_depth != 0) and the new pointer fails nla_ok(), reject the filter with -EINVAL. An exactly exhausted mask still skips the check, preserving exact-match behaviour for the remaining key attributes. Fixes: c96adff95619 ("cls_flower: call nla_ok() before nla_next()") Reported-by: TencentOS Corvus AI <[email protected]> Cc: [email protected] Signed-off-by: Aohan Mei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jérémy Jean <[email protected]> Date: Thu Oct 8 18:13:49 2026 +0000 net/sched: fix use-after-free in __tcf_action_put() commit 7b16eb911091aae237a8673da94e4dfb9cd21d54 upstream. __tcf_action_put() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as: BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64 Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock. Fixes: 16af6067392c ("net: sched: implement reference counted action release") Cc: [email protected] Assisted-by: LLM Signed-off-by: Jérémy Jean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mashiro Chen <[email protected]> Date: Tue Apr 14 04:49:21 2026 +0800 net: ax25: fix integer overflow in ax25_rx_fragment() ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen, which is an unsigned short. When the total exceeds 65535, fraglen wraps around to a small value. The subsequent alloc_skb(fraglen) allocates a too-small buffer, and skb_put() in the copy loop triggers skb_over_panic(). Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation header byte is in the linear data area before dereferencing skb->data. This also rejects zero-length skbs, which the original code did not check for. Two issues in the overflow error path are also fixed: First, the current skb, after skb_pull(skb, 1), is neither enqueued nor freed before returning 1, leaking it. Add kfree_skb(skb) before the return. Second, ax25->fraglen is not reset after skb_queue_purge(). Add ax25->fraglen = 0 to restore a consistent state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen <[email protected]> [F6BVP: v4 as posted on netdev; it was set aside only because the subsystem was being removed from the kernel. Applied unchanged.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 0674e0f082be20adb8e7eb03718d85e71d8b05de) Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolai Buchwitz <[email protected]> Date: Fri Oct 9 12:10:41 2026 +0200 net: bcmgenet: unshare the skb before writing the control block [ Upstream commit 89771ce4f8f67dcffae561b2ccac95c0f6e3aa01 ] bcmgenet stores first_cb, last_cb and bytes_sent in the skb control block and reads them back on completion to free the skb and credit BQL. ether_setup() leaves IFF_TX_SKB_SHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites last_cb, so the earlier slots complete without crediting their bytes and BQL stalls the queue until the watchdog resets it. Unshare the skb before writing the control block. Reproduce with pktgen in clone_skb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "add_device eth0" > $pg/kpktgend_0 echo "dst_mac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "clone_skb 8" > $pg/eth0 echo "count 0" > $pg/eth0 echo start > $pg/pgctrl & sleep 5 echo stop > $pg/pgctrl wait cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight inflight stays nonzero on the now idle queue. clone_skb 0 leaves it at zero. Fixes: f48bed16a756 ("net: bcmgenet: Free skb after last Tx frag") Signed-off-by: Nicolai Buchwitz <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jun Yang <[email protected]> Date: Mon Aug 31 19:13:04 2026 +0800 net: bridge: mcast: don't truncate the port group walk on teardown commit 5a3f7a683aee56e1f15c9d53041f3236767eaae7 upstream. __br_multicast_disable_port_ctx() and br_multicast_del_port() walk port->mglist with hlist_for_each_entry_safe(). However, br_multicast_find_del_pg() can also delete other entries from the same list through br_multicast_fwd_src_remove() or __fwd_del_star_excl(). If such an entry is the iterator's saved next node, hlist_del_init() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after del_nbp() frees the port: BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320 __mdb_fill_info+0x1191/0x1320 br_mdb_dump+0x594/0xe40 rtnl_mdb_dump+0x1cf/0x5d0 Use hlist_del_init_rcu() to unlink the group while preserving ->next. br_multicast_del_pg() and the teardown walks run under br->multicast_lock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer. Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so br_multicast_find_del_pg() would fall through its port scan and hit the trailing WARN_ON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlist_unhashed() identifies exactly this case. Fixes: b08123684bd5 ("net: bridge: mcast: install S,G entries automatically based on reports") Cc: [email protected] Suggested-by: Nikolay Aleksandrov <[email protected]> Reported-by: TencentOS Corvus AI <[email protected]> Signed-off-by: Jun Yang <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Oct 22 13:15:21 2026 +0200 net: call getsockopt_iter if available commit 5bd0dec150f56b6307d599132dcb7c01007bbecc upstream. Update do_sock_getsockopt() to use the new getsockopt_iter callback when available. Add do_sock_getsockopt_iter() helper that: 1. Reads optlen from user/kernel space 2. Initializes a sockopt_t with the appropriate iov_iter (kvec for kernel, ubuf for user buffers) and sets opt.optlen 3. Calls the protocol's getsockopt_iter callback 4. Writes opt.optlen back to user/kernel space The optlen is always written back, even on failure. Some protocols (e.g. CAN raw) return -ERANGE and set optlen to the required buffer size so userspace knows how much to allocate. The callback is responsible for setting opt.optlen to indicate the returned data size. Important to say that iov_out does not need to be copied back in do_sock_getsockopt(). When optval is not kernel (the userspace path), sockptr_to_sockopt() sets up opt->iter_out as a ITER_DEST ubuf iterator pointing directly at the userspace buffer (optval.user). So when getsockopt_iter implementations call copy_to_iter(..., &opt->iter_out), the data is written directly to userspace — no intermediate kernel buffer is involved. When optval.is_kernel is true (the in-kernel path, e.g. from io_uring), the kvec points at the already-provided kernel buffer (optval.kernel), so the data lands in the caller's buffer directly via the kvec-backed iterator. In both cases the iterator writes to the final destination in-place at protocol callback. There's nothing to copy back — only optlen needs to be written back. Signed-off-by: Breno Leitao <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Emanuele Ghidoli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mashiro Chen <[email protected]> Date: Wed Apr 8 01:15:59 2026 +0800 net: netrom: validate source address in nr_find_socket() nr_find_socket() dispatches incoming NR_INFO frames into a connected socket by matching the frame's circuit index/id pair (bytes[15-16]) against the socket's my_index/my_id. It performs no validation of the frame's source callsign against the socket's dest_addr. This means any node on the network can craft an NR_INFO frame with a guessed or brute-forced circuit index/id pair and have it accepted into an arbitrary STATE_3 connection as if it came from the legitimate peer. Circuit IDs are assigned sequentially starting at (1,1), making them predictable in practice. Combined with other receive path bugs, this lets a third party feed frames into a circuit it does not own. nr_find_peer() already checks the source address for CONNREQ; do the same for the other frame types. Fix by adding a source address parameter to nr_find_socket() and requiring it to match the socket's recorded dest_addr for all frame-dispatch lookups. The internal nr_find_next_circuit() caller, which only checks for circuit ID availability, passes NULL to skip the source check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Mashiro Chen <[email protected]> [F6BVP: rebased on mod-orphan; dropped the reference to an unassigned CVE from the changelog. Checked that every caller other than nr_find_next_circuit() is in nr_rx_frame() for non-CONNREQ frames, whose network source is the remote node recorded in dest_addr.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 70bf32b0eda85781a416cb929b7c6b4761abd2a8) Signed-off-by: Sasha Levin <[email protected]>
Author: Aohan Mei <[email protected]> Date: Sat Oct 3 09:34:07 2026 -0700 net: rds: fix uninitialized trans dereference in CM event handler commit 492ba6ac1b1ffb8a06ff52db0825c1af2cdb28c8 upstream. rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA device is an InfiniBand CA (RDMA_NODE_IB_CA). On any other device type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but the event switch dereferences it: unconditionally in the RDMA_CM_EVENT_CONNECT_REQUEST case via trans->cm_handle_connect(), and (with a connection context) in the ROUTE_RESOLVED and ESTABLISHED cases. An RDS listener on an iWARP device therefore crashes the kernel as soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO the wild load becomes a NULL dereference at offset 0xa0 (&trans->cm_handle_connect) in the iw_cm_wq workqueue. GCC masks the bug in default builds by folding the uninitialized load into &rds_ib_transport; Clang-built kernels take the real uninitialized path and oops. The active side can land on a non-IB device too: the id that rds_ib_conn_path_connect() creates is not restricted to a node type, so rdma_resolve_addr() binds it to whichever device serves the local address, and an iWARP RNIC on the same netdev qualifies. The crash there is different: resolving a route on an iWARP id never fills in cm_id->route.path_rec, and the ROUTE_RESOLVED case writes path_rec[0].sl before it calls into the transport. The iWARP transport was dropped long ago and IB is the only transport left, so make that explicit: initialize trans to &rds_ib_transport at declaration, drop the conditional assignment, reject a connect request that arrives on a non-IB device, and drop a connection whose address resolved to one instead of resolving a route on it. The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST on purpose: a non-zero return from the handler makes rdma_cm destroy the id the event was delivered on, which is right for the request's freshly created id but would free a connection id that RDS still owns for any other event. On the active side the id stays ic->i_cm_id and the connection's shutdown destroys it, so that case returns 0. Fixes: dcdede0406d3 ("RDS: Drop stale iWARP RDMA transport") Reported-by: TencentOS Corvus AI <[email protected]> Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ Cc: [email protected] Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei <[email protected]> [achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of bailing out for every event on a non-IB device, so that rdma_cm does not destroy connection ids RDS still tracks; drop a connection whose address resolved to a non-IB device before a route is resolved on it; changelog adjusted] Assisted-by: LLM Signed-off-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jonas Köppeler <[email protected]> Date: Mon Mar 23 18:49:20 2026 +0100 net_sched: codel: fix stale state for empty flows in fq_codel [ Upstream commit 815980fe6dbb01ad4007e8b260a45617f598b76d ] When codel_dequeue() finds an empty queue, it resets vars->dropping but does not reset vars->first_above_time. The reference CoDel algorithm (Nichols & Jacobson, ACM Queue 2012) resets both: dodeque_result codel_queue_t::dodeque(time_t now) { ... if (r.p == NULL) { first_above_time = 0; // <-- Linux omits this } ... } Note that codel_should_drop() does reset first_above_time when called with a NULL skb, but codel_dequeue() returns early before ever calling codel_should_drop() in the empty-queue case. The post-drop code paths do reach codel_should_drop(NULL) and correctly reset the timer, so a dropped packet breaks the cycle -- but the next delivered packet re-arms first_above_time and the cycle repeats. For sparse flows such as ICMP ping (one packet every 200ms-1s), the first packet arms first_above_time, the flow goes empty, and the second packet arrives after the interval has elapsed and gets dropped. The pattern repeats, producing sustained loss on flows that are not actually congested. Test: veth pair, fq_codel, BQL disabled, 30000 iptables rules in the consumer namespace (NAPI-64 cycle ~14ms, well above fq_codel's 5ms target), ping at 5 pps under UDP flood: Before fix: 26% ping packet loss After fix: 0% ping packet loss Fix by resetting first_above_time to zero in the empty-queue path of codel_dequeue(), matching the reference algorithm. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Fixes: d068ca2ae2e6 ("codel: split into multiple files") Co-developed-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jonas Köppeler <[email protected]> Reported-by: Chris Arges <[email protected]> Tested-by: Jonas Köppeler <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Tue May 12 15:36:14 2026 +0200 netfilter: nft_byteorder: remove multi-register support [ Upstream commit bb061d3de41707415269be75ebf700efb03ec212 ] 64bit byteorder conversion is broken when several registers need to be converted because the source register array advances in steps for 4 bytes instead of 8: for (i = ... src64 = nft_reg_load64(&src[i]); ~~~~~ u32 *src nft_reg_store64(&dst64[i], Remove the multi-register support, it has other issues as well: Pablo points out that commit caf3ef7468f7 ("netfilter: nf_tables: prevent OOB access in nft_byteorder_eval") alters semantics: before the loop operated on registers, i.e. for ( ... ) dst32[i] = htons((u16)src32[i]) .. but after the patch it will operate on bytes, which makes this useless to convert e.g. concatenations, which store each compound in its own register. Multi-convert of u32 has one theoretical application: ct mark . meta mark . tcp dport @intervalset Because ct mark and meta mark are host byte order, use with intervals has to convert the byteorder for ct/meta mark value to network byte order (bigendian). nftables emits this: [ meta load mark => reg 1 ] [ byteorder reg 1 = hton(reg 1, 4, 4) ] [ ct load mark => reg 9 ] [ byteorder reg 9 = hton(reg 9, 4, 4) ] ... I.e. two separate calls. Theoretically it could be changed to do: [ meta load mark => reg 1 ] [ ct load mark => reg 9 ] [ byteorder reg 1 = htonl(reg 1, 4, 8) ] ... But then all it would take to change the set to meta mark . tcp dport . ct mark ... and we'd be back to two "byteorder" calls. IOW, support to convert a range of registers is both dysfunctional and dubious. Simplify this: remove the feature. Pablo Neira Ayuso points out that nftables before 1.1.0 can generate incorrect byteorder conversions, see 9fe58952c45a, "evaluate: skip byteorder conversion for selector smaller than 2 bytes" in nftables.git). Affected rulesets fail to load with this change and old userspace due to 'len != size' check. Fixes: c301f0981fdd ("netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval()") Cc: <[email protected]> # may break rule load with old nftables versions Reported-by: Michal Kubecek <[email protected]> Link: https://lore.kernel.org/netfilter-devel/[email protected]/ Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Wed Oct 7 18:14:00 2026 -0700 netlink: avoid hashing the network namespace pointer [ Upstream commit f88bb3606e4bd11ee035b682cddc2999e604609a ] The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINK_USERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of init_net. Use the namespace's unique, non-address net_cookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlink_compare_arg_init(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlink_compare() is safe under RCU, including during namespace teardown. netlink_release() removes the socket from the hash table and defers its final put with call_rcu(). cleanup_net() runs the per-net exit methods and waits for outstanding RCU callbacks with rcu_barrier() before freeing namespace storage. Unlike ns.ns_id, net_cookie is also available and initialized during setup_net() in older stable kernels, making the change straightforward to backport to v5.15 and later. Fixes: c428ecd1a21f ("netlink: Move namespace into hash key") Assisted-by: LLM Signed-off-by: Kyle Zeng <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Tue Oct 6 15:42:32 2026 -0700 netlink: reset skb headers before unicast and multicast filtering [ Upstream commit 8bf659bd54e1f00e34cf5244b1d289c506fa47c0 ] Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code. Fixes: b1153f29ee07 ("netlink: make socket filters work on netlink") Assisted-by: LLM Signed-off-by: Kyle Zeng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 25 13:38:55 2026 +0200 netrom: bound fragment reassembly in nr_queue_rx_frame() nr_sock.fraglen is an unsigned short, but nr_sendmsg() accepts messages of up to 65536 bytes, which nr_output() then splits into NR_INFO frames with the MORE flag. Reassembling such a message on the receiving side makes fraglen wrap to 0, so alloc_skb() returns a buffer far smaller than the data copied into it just after. The same happens with any stream of MORE fragments that adds up to more than 65535 bytes. Mashiro Chen proposed rejecting fragments once the total would exceed USHRT_MAX by returning 1 to the caller. Review pointed out that this return value makes nr_state3_machine() put the frame back on the resequencing queue after nr_queue_rx_frame() has already pulled its headers, and that the limit would reject a legitimate 65536-byte message. Instead: - make fraglen an unsigned int, so a full 64 KiB message fits; - when a message would grow beyond 65536 bytes, drop what has been gathered so far, consume the frame and return 0, so the caller does not retry it; - discard the remaining fragments of that message up to its last fragment, using a new NR_COND_FRAG_DISCARD condition bit, rather than delivering its tail as a separate message. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Mashiro Chen <[email protected]> Closes: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/ Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 6ad8be739b22495d6edc3f6d7b916098ceb3fdf0) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Sep 26 11:34:02 2026 +0200 netrom: clear nr_neigh->ax25 under the routing lock in nr_link_failed() nr_route_frame() swaps nr_neigh->ax25 for the ax25_cb returned by ax25_send_frame() and puts the old one while holding nr_route_lock. nr_link_failed(), called by AX.25 when that link fails, looks the neighbour up under the lock but then clears nr_neigh->ax25, puts the ax25_cb and bumps nr_neigh->failed after dropping it. If a frame is routed to the same neighbour at that moment, both paths can see the same ax25_cb and put it twice. Do the whole of nr_link_failed() in one critical section. The neighbour no longer needs a temporary reference, since it cannot be unlinked while the lock is held. This depends on "netrom: use a single lock for the node and neighbour lists". Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 6e6f80bff5c901f317c3750cdf375766800ecc1a) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Sep 26 11:56:18 2026 +0200 netrom: fix nr_node leak when nr_del_node() removes the last route nr_del_node() takes a reference on the node with its lookup. When the route it deletes is not the last one, it drops that reference before returning. When it is the last one, it only unlinks the node with nr_remove_node_locked(), which drops the list's reference, and returns still holding its own: the unlinked node is never freed. Seen with kmemleak on a live node after adding and then deleting a route to a dummy node with nrparms (SIOCADDRT then SIOCDELRT): the 96-byte nr_node allocated by nr_add_node(), callsign and mnemonic of the dummy node in its hex dump, is reported as unreferenced. Drop the lookup reference in both cases. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit a4b96115783fdefae9599f9a84a39e24fb288d6b) Signed-off-by: Sasha Levin <[email protected]>
Author: Junjie Cao <[email protected]> Date: Sat Sep 26 11:33:35 2026 +0200 netrom: fix reference count leak in nr_rt_device_down When a device goes down, nr_rt_device_down() clears the routes that use this device. However, it fails to drop the per-route reference to the neighbour (nr_neigh): neither nr_neigh->count nor its refcount is decremented when the route is removed. Mirror the behaviour of nr_dec_obs() / nr_del_node() by decrementing nr_neigh->count and calling nr_neigh_put(), so that the neighbour reference is properly released when a device goes down. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Junjie Cao <[email protected]> [F6BVP: rebased on the single nr_route_lock; the list reference is still dropped last by nr_remove_neigh_locked(), so the neighbour stays valid while its routes are removed.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit b0f6830b24b75618e299c8e5451367e8742272da) Signed-off-by: Sasha Levin <[email protected]>
Author: Stanislav Fort <[email protected]> Date: Fri Sep 25 12:23:50 2026 +0200 netrom: linearize and validate lengths in nr_rx_frame() Linearize skb and add targeted length checks in nr_rx_frame() to prevent out-of-bounds reads when processing malformed NET/ROM frames. - Require skb to be linear and at least NR_NETWORK_LEN + NR_TRANSPORT_LEN (20 bytes) before reading network/transport fields. - For the existing sockets path, ensure NR_CONNACK includes the window byte (>= 21 bytes), which nr_state1_machine() reads. - For CONNREQ handling, ensure window (byte 20) and user address (bytes 21-27) are present (>= 28 bytes), and do so before nr_find_listener() so no listener reference can leak. - Preserve existing BPQ extension handling: - NR_CONNACK len == 22 -> 1 extra byte (TTL) - NR_CONNREQ len == 37 -> 2 extra bytes (timeout) nr_route_frame() only guarantees 15 bytes before handing a frame addressed to a local node to nr_rx_frame(), so a short frame received from any AX.25 neighbour is enough to trigger the over-read. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Eric Dumazet <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Stanislav Fort <[email protected]> [F6BVP: v4 never reached mainline (whitespace-damaged posting, subsystem removed in 7.1); rebased onto mod-orphan, added comments. Tested on a two-VM QEMU bench (6.12.94, mkiss link): an AX.25 peer sends CONNREQ frames truncated to 20 and 27 bytes; without this patch both are accepted as connections, the user callsign being read past the end of the frame; with it only the complete 35-byte CONNREQ is accepted. v2: apply the CONNACK length check to a plain CONNACK only, so that 20-byte CONNACK|CHOKE refusals and resets are no longer dropped (reported by Sasha Levin). Same fix submitted to mod-orphan.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit db51201afd46992c9206fa79878badb2236bb7d3) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Sep 26 11:33:13 2026 +0200 netrom: look up and update routes in one critical section nr_add_node(), nr_del_node(), nr_add_neigh() and nr_del_neigh() look up a node or neighbour with nr_node_get()/nr_neigh_get_dev(), which take and drop the routing lock, and only then take the lock again to change the routes. In between, another task can unlink the object they found. nr_add_node() can then store a neighbour that is no longer on nr_neigh_list in a node's routes; that route's reference becomes the last one, and the next time the route is dropped the neighbour is freed and read again straight away: nr_neigh->count--; nr_neigh_put(nr_neigh); /* frees it */ if (nr_neigh->count == 0 && ...) /* use after free */ This is what syzbot reports in nr_add_node() (evicting the worst of three routes) and in nr_dec_obs() through nr_rt_ioctl(). Lizhi Xu analysed the first race; the fix posted then filtered neighbours by refcount and was not taken. Now that one lock covers both lists and the routes, do the lookup and the update in a single critical section in all four functions, using new __nr_node_get()/__nr_neigh_get_dev() variants that expect the lock to be held. A node or neighbour found there stays linked while it is used, so a route can no longer outlive its neighbour's list entry. Concurrent additions of the same node or neighbour no longer create duplicate entries either. Also factor the "drop one route's use of a neighbour" sequence into nr_neigh_route_put_locked(), which reads count and locked before dropping the reference, and use it in nr_add_node(), nr_del_node() and nr_dec_obs(). nr_add_node() is also called from nr_route_frame() in softirq context, where the kmemdup(GFP_KERNEL) of the digipeater list could sleep; the neighbour creation shared with nr_add_neigh() now allocates with GFP_ATOMIC, like the rest of nr_add_node() already did. This depends on "netrom: use a single lock for the node and neighbour lists". Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=2860e75836a08b172755 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=df52f4216bf7b4d768e7 Link: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 1292cb18feed7503f861695134206c99347cc7bb) Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Fri Sep 25 13:37:31 2026 +0200 netrom: require full NET/ROM headers in nr_route_frame() nr_route_frame() only checked that an incoming frame was long enough for the two network layer addresses and the time-to-live byte, and did so against skb->len without making sure the bytes were in the linear part of the skb. A valid NET/ROM network frame always carries the 5-byte transport header as well, so anything shorter than NR_NETWORK_LEN + NR_TRANSPORT_LEN (20 bytes) is malformed, whether it is for this node or in transit. Use pskb_may_pull() for that length, as suggested in review, so the header fields are also guaranteed to be linear before they are read here or later in nr_rx_frame(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Greg Kroah-Hartman <[email protected]> [F6BVP: taken from the nr_route.c part of Greg's "netrom: do some basic forms of validation on incoming frames"; the nr_rx_frame() part is handled separately. Switched from a skb->len test to pskb_may_pull() following Simon Horman's review.] Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit dc06212ff6bb781fad2b5082e3ecb7cc93336da0) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 25 14:51:52 2026 +0200 netrom: use a single lock for the node and neighbour lists NET/ROM routing uses three kinds of locks: nr_node_list_lock, nr_neigh_list_lock and a lock in every nr_node. They are taken in opposite orders on different paths: - nr_del_node() and nr_dec_obs() take the node list lock, then a node lock, then the neighbour list lock (through nr_remove_neigh()); - nr_add_node(), called for every frame received from a neighbour, holds a node lock and takes the neighbour list lock; - nr_rt_device_down() takes the neighbour list lock, then the node list lock, then each node lock. Taking an interface down while routes are being changed or frames are coming in can therefore deadlock, which is what the open syzbot reports against nr_del_node(), nr_remove_neigh() and nr_rt_device_down() show. Fixing the order case by case was tried several times and never covered every combination. As suggested by Jakub, replace all three with one nr_route_lock that covers both lists and the routes of every node. The per-node lock goes away: with the lists and routes[] under the same lock it no longer protects anything, and routing tables are small and change rarely. nr_remove_neigh() gets a variant for callers that already hold the lock. Node refcounting is unchanged apart from the hold/put pair that nr_node_lock()/nr_node_unlock() used to add around each critical section. nr_route_frame() still calls ax25_send_frame() with the lock held, as it did under the node lock, so the lock is documented as never to be taken with an AX.25 list lock held; nr_link_failed() is called from AX.25 with only linkfail_lock held. No change in behaviour otherwise; the other issues found on the way (unlocked updates of nr_neigh->ax25 and failed, duplicate entries from concurrent nr_add_node(), a reference leak in nr_rt_device_down()) are left for separate patches. Link: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/ Suggested-by: Jakub Kicinski <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 602c964d5e3d006cbd6e514aa971c5ab7257d66a) Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Tue Sep 22 08:34:16 2026 -0700 nios2: fix __wsum type degradation in csum_fold() [ Upstream commit b963f2345fa20417401c51a69dedb6a58eea33a9 ] csum_fold() shifts a bitwise __wsum type, which sparse reports as "restricted __wsum degrades to integer". Sparse only checks the body of a static inline once something instantiates it, so this went unnoticed until a recent block layer change added the first csum_fold() caller to a file built on this architecture. Force cast to a __u32 for the shift, as the other architectures do. Fixes: eea9507a69d6 ("nios2: Library functions") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Wed Oct 21 11:58:01 2026 -0400 ntfs3: free the sbi after a grace period [ Upstream commit c01b091b06412d3b1b53d8c2925f6de586c8a2fc ] If the "nocase" mount option ntfs3 uses custom hash and dentry compare functions. Both access ntfs3 superblock private information in rcu pathwalk. ntfs_put_super() and ntfs3_kill_sb() drop the info without any rcu delay. A lookup that's still inside the filesystem when the last reference to the mount is dropped causes a UAF. With a pathwalk held up in ntfs_d_hash() while the last reference to the mount goes away: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x752/0x940 Read of size 8 at addr ff1100010453c850 by task walker/99 Call Trace: <TASK> ntfs_nls_to_utf16+0x752/0x940 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_cache_noprof+0x249/0x560 ntfs_init_fs_context+0x2db/0x5a0 alloc_fs_context+0x52e/0xc70 [...] Freed by task 98: kfree+0x1db/0x5b0 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 task_work_run+0x131/0x250 The bug is currently masked by the grace period in namespace_unlock() for umount(2). Keep the necessary information until the filesystem private info is freed and free it with an rcu delay. ntfs3_free_sbi() now runs from an rcu callback and drops the upcase table via ntfs_put_shared(). So switch s_shared_lock over to spin_lock_bh(). Otherwise the callback can deadlock against a task holding the lock on the same cpu. Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> [ sashal: Adjusted ntfs_put_super() context because the early mount-options cleanup block was already absent. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang <[email protected]> Date: Sun Oct 11 23:35:06 2026 +0800 ocfs2/dlm: Protect the recovery list during debugfs reads [ Upstream commit 4c435828932bf46f29860e4a0375bcae101b778a ] Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory. Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module. Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged. KASAN report as below: BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896 CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #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: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] </TASK> Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0) [Page and memory-state dumps omitted.] Fixes: 007dce53a29c ("ocfs2/dlm: Dump the dlm state in a debugfs file") Signed-off-by: Cen Zhang <[email protected]> Link: https://patch.msgid.link/pm-ocfs2-objects-candidate-0049-v3-184e46c47f5283f06191@gmail.com Reviewed-by: Joseph Qi <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Schauer <[email protected]> Date: Fri Aug 28 08:08:22 2026 +0200 page_pool: keep frag_offset aligned for odd-sized requests commit dc0df5a0c62ccea1d0e08d39a4dc9064de81d411 upstream. page_pool_alloc_frag_netmem() rounds the requested fragment size with size = ALIGN(size, dma_get_cache_alignment()); dma_get_cache_alignment() returns 1 unless the architecture defines ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not. There the ALIGN() is a no-op and pool->frag_offset advances by the raw, unrounded size. A single caller asking for an odd size then leaves frag_offset misaligned for every fragment carved out of that page afterwards. The pool is shared, so the damage is not confined to the caller that caused it. The per-cpu system_page_pool used by generic XDP hits this. skb_pp_cow_data() allocates its fragments with the raw packet length: size = min_t(u32, len, PAGE_SIZE); truesize = size; page = page_pool_dev_alloc(pool, &page_off, &truesize); leaving frag_offset odd for whatever is carved out of that page next. Its own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer, napi_build_skb() installs it as skb->head, and skb_shinfo(skb) == skb->head + skb->end is misaligned with it. skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the atomic_inc() in __skb_clone() straddles a cache line. On x86 with split lock detection -- fatal for kernel split locks by default -- this panics the machine: Oops: Split lock detected RIP: 0010:skb_clone+0x154/0x1e0 Call Trace: <IRQ> raw_local_deliver+0x1ed/0x2c0 ip_protocol_deliver_rcu+0x54/0x1c0 ip_local_deliver_finish+0x85/0x100 ip_local_deliver+0x67/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 Reproduced by attaching any generic-mode XDP program to loopback and opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone every locally delivered UDP packet; ordinary DNS traffic then triggers it, roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8. Tracing page_pool_alloc_frag_netmem() over one such run shows the amplification -- two odd-sized requests, nine misaligned offsets: requested size & 7: 0: 17035 5: 1 7: 1 frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5 and skb_pp_cow_data() returning heads that were aligned on entry: head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4) head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5) Round the fragment size up to at least the alignment struct skb_shared_info requires, so fragments are always suitably aligned for the objects callers build on them. Architectures needing a larger DMA alignment keep it. This also makes the remainder computed in page_pool_alloc_netmem(), *size = max_size - *offset; aligned, since max_size is a power of two -- which fixes the matching misalignment of skb->end. Verified with a controlled A/B under QEMU/KVM: same tree, same config, same compiler, same rootfs and identical traffic, differing only by this patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which passes raw packet lengths to the pool. Measured at the return of skb_pp_cow_data(): unpatched patched skb_pp_cow_data calls 40800 40800 misaligned skb->head 1120 0 dataref at line offset >60 80 0 The last row counts the accesses that actually fault: skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so `lock incl` splits a 64-byte cache line only when that address lands at offset 61..63. All 80 occurrences were at offset 61; the panic reported above was at offset 62. Eliminating the misalignment removes every one of them. Same class of bug as commit 3bed3cc4156e ("net: Do not allocate page fragments that are not skb aligned"), which fixed the older netdev_alloc_frag()/napi_alloc_frag() allocators. Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool") Cc: [email protected] Signed-off-by: Florian Schauer <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Gruhlke <[email protected]> Date: Sun Oct 11 21:01:45 2026 +0200 PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV [ Upstream commit e8df1d194c39b7a5159d570798941851f70a8668 ] With RRS Software Visibility, pci_dev_wait() considers a device ready as soon as reading the Vendor ID doesn't return the RRS value. Devices aren't required to respond with RRS while they aren't ready, so the read may return ~0 and pci_dev_wait() stops waiting too early. This was seen with Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs. Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0, so check its Command register instead, as is done without RRS SV. Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS") Link: https://lore.kernel.org/r/[email protected] Suggested-by: Lukas Wunner <[email protected]> Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Haris Okanovic <[email protected]> Date: Tue Oct 13 13:56:00 2026 -0500 perf: Fix perf_pmu_migrate_context() leaving events behind [ Upstream commit e76b36b4be7160eaa14b416681e548b125702395 ] __perf_pmu_remove() walks the group leaders of a CPU and PMU with perf_event_groups_for_cpu_pmu(), removing each one as it goes. perf_remove_from_context() takes the leader out of the groups rbtree, after which rb_next() on that node returns NULL, prematurely ending the walk. Other groups stay behind in the source context. On CPU hotplug, they are then torn down with the dying CPU. They keep running until teardown, while the PMU's interrupt and migrated events are on a new CPU, which drivers rely on never happening. Walk ctx->event_list instead and pick out the PMU's events by their pmu_ctx. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Haris Okanovic <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Stoakes (ARM) <[email protected]> Date: Wed Oct 21 16:53:49 2026 +0100 perf: Track the perf mlock gift separately commit 78436f3882fb8d848c823bf8cf754988202c5ca5 upstream. The locked_vm field in struct user_struct was originally introduced by commit 789f90fcf6b0 ("perf_counter: per user mlock gift") to provide an mlock-like budget for perf measured against mm->pinned_vm (since 2011). perf grants each user a 'gift' of perf_event_mlock_kb * online CPUs of buffer pages which is charged to user->locked_vm without any RLIMIT_MEMLOCK check. Only pages beyond the gift are checked against RLIMIT_MEMLOCK, per-mm, via mm->pinned_vm, which makes it different from the standard mlock() check, which is per-mm and made against RLIMIT_MEMLOCK. However, since this was introduced, a number of other components have utilised this field where a shared resource needed to be limited against RLIMIT_MEMLOCK. The other users are currently MSG_ZEROCOPY, io_uring, AF_XDP, iommufd, s390 KVM zPCI and most recently, secretmem in commit 97d34aa65c29 ("mm/secretmem: properly account locked pages"). This field is shared between all of these, but because the gift is not checked against RLIMIT_MEMLOCK, user->locked_vm alone can exceed it - 16 CPUs * 516 KiB is already more than the default 8 MiB - after which every other user of the field fails unconditionally. This was reported by a user who saw secretmem failing while running a simultaneous perf record. Resolve the issue by simply giving perf its own field separate from the rest. BPF used user->locked_vm up until commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory accounting infra for bpf maps") which landed in 5.11. Thus also eliminate the now-defunct ifdef for CONFIG_BPF_SYSCALL for user->locked_vm. This issue exists between all of the components which use user->locked_vm and perf, however secretmem is the first user who has caused a report over many years and has been backported, so target the fix at that. Fixes: 97d34aa65c29 ("mm/secretmem: properly account locked pages") Closes: https://lore.kernel.org/[email protected] Reported-by: Ameer Hamza <[email protected]> Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] [ ljs - Applied to open-coded accounting in perf_mmap()/perf_mmap_close(). ] Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antoine Huret <[email protected]> Date: Thu Oct 15 14:55:56 2026 +0200 perf: Update cgroup time when rotating multiplexed events commit e4c7c401c6b9174c0c893084fdaa6a84bd2520d7 upstream. Since commit bd2756811766 ("perf: Rewrite core context handling"), perf_rotate_context() only updates the context time before scheduling out the flexible events. It no longer updates the cgroup time, which ctx_sched_out() used to do. Cgroup events take their times from the per-cpu cgroup clock, so between two cgroup switches the rotations see a frozen clock. The events rotated out lose the running time they accumulated, and the next update, usually a read, credits the whole interval to the events that happen to be on the PMU at that moment. As a result, the time_running of multiplexed cgroup events is wrong, and so are their scaled counts, as long as no other cgroup runs on the CPU, e.g. a busy job alone on its CPUs. Counting cycles over one second of a busy loop in a cgroup gives from half to several times the max frequency of the CPU. Update the cgroup time before rotating the CPU context, as was done before the rewrite. Fixes: bd2756811766 ("perf: Rewrite core context handling") Closes: https://lore.kernel.org/r/PR3PR07MB69223331EED5BEBE150375B7849C2@PR3PR07MB6922.eurprd07.prod.outlook.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Antoine Huret <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aviv Vaknin <[email protected]> Date: Fri Oct 2 23:28:20 2026 +0300 pid_namespace: make zap_pid_ns_processes() freezable commit 81933038f5e273d17ed22792f906889393b204c5 upstream. When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. Fixes: 3eb07c8c8adb ("pid namespaces: destroy pid namespace on init's death") Fixes: b9a985db9896 ("pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes") Cc: [email protected] # 6.1+ Suggested-by: Oleg Nesterov <[email protected]> Signed-off-by: Aviv Vaknin <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Oleg Nesterov <[email protected]> Reviewed-by: Bradley Morgan <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Aug 24 14:08:20 2026 +0200 pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper commit 5c0985dd3c32fc2bbd0e8beaf13cf52cd97376a2 upstream. Since commit 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes() clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise kernel_wait4() doesn't sleep and returns -ERESTARTSYS if signal_pending() is true and the reaper busy-waits. But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again. For example, klp_send_signals() sets it raw against any task that hasn't transitioned yet. And it keeps sending it until the livepatch finishes. The sleep loop waiting for pid_allocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASK_INTERRUPTIBLE returns immediately. Use a no_notify_signal guard. signal_pending() will ignore TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child exits or free_pid() wakes it. Link: https://patch.msgid.link/[email protected] Fixes: 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") Reviewed-by: Oleg Nesterov <[email protected]> Cc: [email protected] Suggested-by: Oleg Nesterov <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Mon Oct 5 13:01:47 2026 -0500 pinctrl: amd: Clear S4 wake bits when firmware has _AEI commit 1cca81a683da7f0ef2fbaf34442376044cbbad22 upstream. Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") preserves firmware-programmed S4 wake sources because some PCIe devices rely on them for Wake-on-LAN. The system that motivated that change does not expose ACPI GPIO events through _AEI. On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5 wake bit set for GPIO 24. This causes the machine to power back on immediately after shutdown even though Wake-on-LAN is not enabled. GPIO register dumps show that the only relevant difference is bit 15 on GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not itself listed in _AEI, so _AEI is not a per-pin indication of which pins the OS manages; it is a platform level signal of which wake model the firmware follows. Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on every system. Clear S4 bits when firmware exposes _AEI, indicating that the platform hands GPIO events to the OS, but preserve S4 bits when _AEI is absent so that firmware-programmed sources such as PCIe PME that bypass the GPIO IRQ wake API keep working. A platform that exposes _AEI for some pins while routing a wake capable device through a raw GPIO not listed in _AEI would lose that wake source unless firmware re-arms it during the sleep transition. No such system has been reported. Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") Reported-by: Olzhas Marat <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041 Cc: [email protected] Tested-by: Olzhas Marat <[email protected]> Reviewed-by: Shyam Sundar S K <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gilberto Conde <[email protected]> Date: Mon Sep 21 10:34:19 2026 +0100 pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13 [ Upstream commit c6c159fcdb4e9a678eda0831f971e4a3a488ec47 ] GPIO13 supports the PWM3 function at mux select value 4, but the pingroup table leaves that slot empty and gpio13 is not listed in pwm3_groups. Selecting pwm3 on gpio13 is therefore rejected by the pinmux core: ipq5018-tlmm: invalid group "gpio13" for function "pwm3" The GL.iNet GL-X2000 drives its fan from PWM3 on this pin, and the vendor firmware muxes it with select value 4: gpio13 : out low func4 8mA no pull Add pwm3 to the fourth function slot of gpio13 and list gpio13 in pwm3_groups. With this the pin muxes as expected: pin 13 (GPIO_13): device 1941010.pwm function pwm3 group gpio13 Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Signed-off-by: Gilberto Conde <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adriel Santos <[email protected]> Date: Fri Oct 2 13:09:58 2026 -0300 pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12 [ Upstream commit 709ba1c547eaf37da36ded2ecf3ea4e304cdfa9a ] The pingroup table has gcc_plltest at function 5 of gpio12 and does not offer pwm2 on that pin, so the pinmux core rejects a request for pwm2 on gpio12 as an invalid group. On the hardware, function 5 of gpio12 carries the PWM2 output: the Xiaomi AX3000T v2 drives its blue status LED from PWM2 on gpio12. The vendor kernel shipped on that router (Linux 4.4, stock firmware 2.0.28) has pwm2 in this slot. Its pingroup table, as read from the firmware image, lists these functions for gpio12: gpio, blsp0_spi, blsp0_i2c, blsp1_uart0, _, pwm2, qdss_tracedata_a, _, _, _ and has pwm3 at function 4 of gpio13, matching commit c6c159fcdb4e ("pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13"). Measured on the board: with gpio12 set to each of the 16 function values in turn, and PWM2 held at 0% and then at 100% duty, the pad level read back from GPIO_IN follows PWM2 only at function 5. There it does not follow PWM channels 0, 1 or 3, and the LED switches with PWM2. Functions 4 and 7, which the table leaves empty, do not carry PWM2. Put pwm2 in function 5 of gpio12 and list gpio12 in pwm2_groups. Drop gpio12 from gcc_plltest_groups: none of its functions is gcc_plltest any more, and selecting it would trigger the WARN_ON() in msm_pinmux_set_mux(). Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Assisted-by: LLM Signed-off-by: Adriel Santos <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Fri Oct 2 06:17:05 2026 +0000 pipe: preserve existing fasync readers on writer setup failure [ Upstream commit 40bb03d3ea6f6a915218508819ecc4d7a7fa260d ] F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before. Fixes: 76398425bb06 ("Move FASYNC bit handling to f_op->fasync()") Signed-off-by: Kyle Zeng <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xueqin Luo <[email protected]> Date: Tue Sep 1 15:29:54 2026 +0800 power: supply: ds2780: Fix ds2780_get_capacity() returning raw value [ Upstream commit a58cbc8b36ec0cd00d2ba3de7d003de818a27523 ] ds2780_get_capacity() returns the raw register value instead of 0 on success. The capacity is already stored in *capacity, so the function should return 0 to indicate success. Fixes: 275ac74629c4 ("w1: add Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC support") Signed-off-by: Xueqin Luo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karl Mehltretter <[email protected]> Date: Wed Sep 9 08:46:23 2026 +0200 power: supply: Fix maintenance charge table kernel-doc [ Upstream commit 45d4af4e80a25881b6b75e8e34872c555c43a41d ] struct power_supply_maintenance_charge_table contains charge_safety_timer_minutes, but its kernel-doc describes safety_timer_minutes. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: d72ce7d32478 ("power: supply: ab8500: Standardize maintenance charging") Assisted-by: LLM Signed-off-by: Karl Mehltretter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Ryhel <[email protected]> Date: Sat Sep 26 17:29:05 2026 +0300 power: supply: generic-adc-battery: Fix temperature IIO channel conversion [ Upstream commit 6bca94e64255053ab2aa56f2588fda73d399b790 ] Temperature IIO channel data is provided in milli-degrees, while POWER_SUPPLY_PROP_TEMP is expected to be in deci-degrees. Adjust the existing logic to reflect this conversion properly. Fixes: 33088c0513818 ("power: supply: generic-adc-battery: add temperature support") Signed-off-by: Svyatoslav Ryhel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Ogness <[email protected]> Date: Fri Oct 16 11:00:34 2026 +0206 printk: Postpone kthread startup [ Upstream commit 5f339c46f153184570f16c8e789c9709b14cbe8b ] There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. Reported-by: Derek Barbosa <[email protected]> Closes: https://lore.kernel.org/linux-rt-users/[email protected] Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness <[email protected]> Tested-by: Derek Barbosa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Petr Mladek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Sep 21 15:44:58 2026 +0200 ptrace: refuse to change the signal mask of a user worker commit cabc249e6560bee7bdfee9fbcb7ce4e951dcfd41 upstream. A user worker is created with every signal other than SIGKILL and SIGSTOP blocked. It never runs user code and that mask is what keeps get_signal() from dequeuing anything else for it. complete_signal() never picks a thread that blocks the signal, tkill() queues on the worker but nothing dequeues it. ptrace_signal() requeues an injected signal that the tracee blocks. PTRACE_SETSIGMASK is the only way to change that mask from the outside. A tracer that clears it makes the worker eligible for every signal. Whatever the worker then dequeues it can only act on by leaving. Refuse PTRACE_SETSIGMASK for a user worker with -EPERM, the way ptrace_attach() refuses a kernel thread. A worker is guaranteed to only ever dequeue SIGKILL or SIGSTOP and an injected signal stays pending on it, which is what already happens when the mask isn't touched. Taking the request and quietly leaving the mask alone was the other option, the way set_current_blocked() keeps SIGKILL and SIGSTOP unblocked whatever userspace asks for. But then a tracer gets success back with nothing changed and no way to tell that apart from a mask that took effect. Fixes: e8b33b8cfafc ("Revert "kernel: treat PF_IO_WORKER like PF_KTHREAD for ptrace/signals"") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Acked-by: Oleg Nesterov <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Fri Oct 31 09:03:16 2025 +0100 regcache: Add ->populate() callback to separate from ->init() [ Upstream commit 94a3a95f03154d8d4c6206950a7f6ef9a30baec6 ] In the future changes we would like to change the flow of the cache handling. Add ->populate() callback in order to prepare for that. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: abff0a48b110 ("regmap: Drop map lock during cache init and exit") Signed-off-by: Sasha Levin <[email protected]>
Author: Francesco Lavra <[email protected]> Date: Tue Jun 16 13:44:29 2026 +0200 regcache: Do not overwrite error code when finalizing cache after error [ Upstream commit 9108f7fa493b4c88cbc09503e0c164244456bad5 ] During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed. Fixes: 94a3a95f0315 ("regcache: Add ->populate() callback to separate from ->init()") Signed-off-by: Francesco Lavra <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: abff0a48b110 ("regmap: Drop map lock during cache init and exit") Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Reeves <[email protected]> Date: Tue Oct 6 18:03:16 2026 +1100 regmap: Drop map lock during cache init and exit [ Upstream commit abff0a48b110fe52d43999b4cb7c793a510a6bf1 ] On systems with CONFIG_PROVE_RAW_LOCK_NESTING enabled, Apple GPIO probe triggers an "Invalid wait context" lockdep warning. The driver uses a regmap with a raw spinlock and REGCACHE_FLAT. During regcache_init(), regcache_flat_init() allocates memory while holding the raw spinlock. The memory allocator can acquire a non-raw spinlock, which causes an invalid raw-to-non-raw lock nesting error. The abbreviated call chain is: apple_gpio_pinctrl_probe regcache_init regcache_flat_init __kmalloc_noprof __pcs_replace_empty_main refill_objects _raw_spin_lock_irqsave Cache allocation occurs before the regmap is published, cache destruction occurs after users have stopped accessing it, and regmap_reinit_cache() requires callers to prevent concurrent access. Remove the outer map lock from cache initialization and destruction. Keep it for cache population and normal register access. The Maple cache still uses its internal spinlock during teardown. That lock can also be acquired from hard IRQ context during register access. Add Maple-state irqsave helpers and use them during teardown to preserve the lock's IRQ-safe lockdep state. Fixes: fd4ebc07b4df ("regmap: Hold the regmap lock when allocating and freeing the cache") Suggested-by: Mark Brown <[email protected]> Suggested-by: Liam R. Howlett <[email protected]> Signed-off-by: Michael Reeves <[email protected]> Reviewed-by: Peng Fan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Levin <[email protected]> Date: Wed Oct 21 12:13:05 2026 -0400 Revert "s390/mm: Add missing secure storage access fixups for donated memory" This reverts commit 74ccc099f1baa9236b8fb600406457a0870c83a9. Reported-by: kernelci.org bot <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Levin <[email protected]> Date: Mon Oct 26 17:14:21 2026 -0400 Revert "srcu: Use irq_work to start GP in tiny SRCU" This reverts commit 2127e6b79d9d579ea538a350d1bbe859e39814d5. Reported-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: David Carlier <[email protected]> Date: Mon Sep 14 14:35:05 2026 +0100 ring-buffer: Do not show buffer_meta for CPUs without a buffer commit 3f23cae09a4677a3f7c163a68388512cb231ff22 upstream. The per_cpu/cpuN/buffer_meta files are created for every possible CPU, but buffer->buffers[cpu] is only allocated once that CPU comes online. Reading the file of a CPU that never came online dereferences a NULL cpu_buffer in rbm_start(). Fail the open with -ENODEV when the CPU has no buffer, as the other per CPU ring buffer interfaces do. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Reported-by: Sashiko <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: David Carlier <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krystian Kaniewski <[email protected]> Date: Thu Sep 24 10:49:42 2026 +0200 ring-buffer: Fix false warning in ring_buffer_map_get_reader() commit 89bab1dba8a0167ef0d819e0f55b6bafa038e87f upstream. The mmap reader can warn when it catches up with a writer that is still committing events. rb_get_reader_page() returns NULL in this case, but ring_buffer_map_get_reader() treats that result as an error. The initial rb_per_cpu_empty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take reader_lock and can advance commit_page before publishing the committed length on the new page. rb_get_reader_page() can swap to that page, catch up with the writer and return NULL. Handle NULL through the existing no-data exit without warning. Remove the caller's reader_page == commit_page check as well, since the reader-page helper already handles that case. The existing metadata update and return path remain in place. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Assisted-by: Gemini:gemini-3.8-flash syzbot Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=de3d7f9bcc9212f3fae1 Link: https://syzkaller.appspot.com/ai_job?id=488adc18-a10e-42d2-a205-25327c38837f Signed-off-by: Krystian Kaniewski <[email protected]> Reviewed-by: Vincent Donnefort <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donggeun Yoo <[email protected]> Date: Fri Sep 18 16:15:07 2026 +0900 ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() commit 25132363c723afc39aace8b098f547ab4a0ea759 upstream. On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[] shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma() dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader() writes two such indices into meta->buffers[], which rb_cpu_meta_valid() would reject on the next boot, discarding the previous boot's trace. A CPU's sub-buffer array starts after its meta header and the nr_subbufs integers that follow, aligned up to a sub-buffer. rb_meta_subbuf_idx() inverts that calculation but skips only the integers, not the header, so its base is one sub-buffer low whenever the omitted header size crosses the alignment boundary. Invert the calculation with rb_subbufs_from_meta() rather than repeating it. rb_range_buffer() maps an index back to an address through the same helper, so the two directions can no longer disagree. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: b14d032973d4 ("ring-buffer: Add ring_buffer_meta data") Signed-off-by: Donggeun Yoo <[email protected]> Reviewed-by: Vincent Donnefort <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Oct 10 12:57:44 2026 +0200 rose: bring up the link of the preferred route passed over by a connect request For a connect request rose_get_neigh() walks the routes that match the address, from the most specific to the least specific, and takes the first neighbour whose link is restarted. A neighbour whose link is down is only used when no matching route at all has a restarted neighbour. A node that has both an exact route to a neighbouring node and a wide route through a relay therefore never uses the exact route once its link is down: the relay is restarted, it is always found first, and since no frame is ever sent over the direct link nothing brings it up again. The calls keep going through the relay, which may have no route other than back to the calling node and then clears them. Seen on a node whose White Pages daemon calls an adjacent node: every call goes to the relay and comes back as CLEAR REQUEST "not obtainable", for as long as the node runs. Keep sending the call to the restarted neighbour, so that a call never waits for a link that may not answer, but when a neighbour of a more specific route, or an earlier neighbour of the same route, was passed over because its link is down, start the restart procedure on that link. If the other end answers, the next call finds the link restarted and uses it. A link that has just failed is left alone for link_fail_timeout, and nothing is done while a restart is under way. Frames in transit are handled as before. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C where B has an exact route to C over their direct link and a wide route through A, and the link B - A is restarted while B - C is not. Before, every call from B to C goes to A and is cleared there, and the direct link stays down. After, the first call still goes to A, the direct link is restarted within 20 ms and the following calls go through it. With C switched off no call waits: they all go to A at once, the restart is attempted once, and after the AX.25 connection gives up the link is left alone for link_fail_timeout. A call from A to C in transit through B gets the same answer before and after. No lockdep, KASAN or refcount report. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit cdf5a2eba2bc4f79dabb013a3a935f54aedb85e9) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sun May 31 15:41:45 2026 +0200 rose: clear neighbour pointer in rose_kill_by_device() rose_kill_by_device() drops the neighbour reference but leaves rose->neighbour pointing at it, unlike every other rose_neigh_put() site (see "rose: clear neighbour pointer after rose_neigh_put() in state machines"). The heartbeat STATE_0 reaping path then puts the same neighbour a second time, causing a rose_neigh refcount underflow and a use-after-free. Set rose->neighbour = NULL after the put, restoring the invariant. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 606e42d195b467480d4d405f8814c48d1651a76a) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 25 11:10:23 2026 +0200 rose: clear stale N(R)/N(S) before (re)transmitting a data frame rose_kick() transmits a skb_clone() of each data frame and keeps the original on ack_queue. The clone shares its data buffer with the original, so the sequence numbers that rose_send_iframe() ORs into byte 2 of the header are also left in the queued original. After a RESET, rose_requeue_frames() puts those originals back on the write queue and rose_kick() sends them again with vs/vr restarted at zero. rose_send_iframe() only ORs the new values into byte 2, so the retransmitted frame carries the bitwise OR of the old and new N(R) and N(S). The peer rejects the invalid N(R) with a new RESET REQUEST, the frames are requeued again, and the two nodes reset each other forever. This was observed on a live FPAC network: a White Pages circuit between two nodes looping on RESET REQUEST / RESET CONFIRMATION / DATA at about 2000 frames per second, with DATA frames resent as "R3 S7" right after a reset instead of "R0 S0", until the application was restarted. Clear everything but the M bit before setting the sequence numbers, as x25_send_iframe() does for modulo 8 circuits. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit b16b091aeb78faac22cf2b850246826d23f4a335) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Wed Oct 7 15:26:50 2026 +0200 rose: clear the circuits of a neighbour that restarts the link A Restart Request is the X.25 way to say that every virtual circuit of a link is gone. rose_link_rx_restart() only marks the neighbour as restarted and answers with a Restart Confirmation: the sockets and the through routes that used the link are left as they were. That is harmless on a link coming up, nothing is established yet. It is not when the other end restarts its AX.25 and ROSE stack while we keep the link: the first thing it sends is a SABM, which resets our AX.25 connection without bringing it down, then a Restart Request. Its circuits are gone, ours stay in state 3 forever: - a frame for a logical channel that the other end does not know is dropped silently by rose_route_frame(), so no Clear Request ever comes back; - no timer watches the acknowledgement of data in state 3, and the idle timer is off by default; - the through routes stay in /proc/net/rose_routes and the remote ends of those calls are never told. The stale entries are not just a leak. The restarted end allocates its logical channel numbers afresh, so a new circuit can get the number of a stale through route on the same link, and whatever still arrives on the stale half is then relayed into the new circuit. Seen on a live network: a node that restarts its stack from cron left, on each of three neighbours, a data circuit with five unacknowledged frames that never moved again, and five through routes on the node that relays for the others. Clear them when a Restart Request arrives on a link that is already up: send a Clear Request to the other half of each through route and drop the route, and disconnect the local sockets, as rose_link_failed() does when the link goes down. The loop of rose_del_route_by_neigh() is moved to a helper for that, since the caller here already holds rose_route_list_lock. Nothing is sent to the restarting neighbour: it has no circuit left, and a Clear Request could hit a call it has just placed on a reused channel number. A link that is not up yet is left alone: nothing can be established over it, and the sockets found there are calls waiting in neigh->queue for the restart to complete. Tested with three QEMU guests in a line, A - B - C, on a kernel with lockdep and KASAN. A calls C through B and B calls C, both circuits stay open, then C destroys and recreates its AX.25 interface, reloads its routes and calls B. Before: both circuits are still open a minute later, B keeps the through route, nobody is told. After: A and B get the circuit cleared (cause 0x09) within a second of the Restart Request, B has no through route left, and the new call from C goes through at the first attempt. Four runs, no lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 34de1b990c7c690c19594a49ee5b9a74883baf2b) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Wed Sep 30 16:59:45 2026 +0200 rose: clear through routes when a neighbour is removed from the tables When the last route using a neighbour is deleted (SIOCDELRT) or all routes are cleared (SIOCRSCLRRT), rose_del_node() and rose_clear_routes() take the neighbour out of rose_neigh_list, but the through routes in rose_route_list that still use it are left alone. No frame can reach them any more, so they stay in the table for ever, holding their neighbour references, and neither end of the relayed connection is told: the caller and the called station keep a circuit that goes nowhere. rose_clear_routes() even says it keeps neighbours with active connections, which it does not. This shows up on every node that relays traffic when its routing daemon restarts: FPAC clears and reloads the routes, the neighbours are recreated under new numbers, and the old through routes remain listed with neighbours that no longer exist. Clear them when the neighbour is removed, as rose_link_failed() does when a link fails, but send the CLEAR to both halves since the removed neighbour's link may still be up, and cut the local connections using it. rose_route_list_lock is taken under rose_node_list_lock and rose_neigh_list_lock, the order rose_route_frame() and rose_link_failed() already use. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C with A calling C through B: before, the through route stays on B after SIOCDELRT or SIOCRSCLRRT and A is never told; after, the entry is gone and both A and C get a CLEAR (cause 0x09) within a second. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 065ae03f519c147d5ee7b87acb2d21fe93ae0007) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu May 28 17:38:18 2026 +0200 rose: disconnect orphaned STATE_2 sockets when device is gone When ax25stop brings down ROSE interfaces, sockets in ROSE_STATE_2 (awaiting CLEAR CONFIRM) whose device pointer is already NULL are not reached by rose_kill_by_device() and wait for T3 (up to 180s) before self-cleaning via rose_timer_expiry(). This keeps the rose module usecount at 1, blocking rmmod for the full T3 duration. In rose_heartbeat_expiry(), detect ROSE_STATE_2 sockets with no device, cancel T3, release the neighbour reference, and call rose_disconnect() + sock_set_flag(SOCK_DESTROY). The next heartbeat tick (<=5s) then destroys the socket via the existing ROSE_STATE_0/SOCK_DESTROY path, allowing clean module unload within 10s instead of up to 180s. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit d4f4cf9f09a3f5fafa8f09110a7c1b5d10f2f261) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sun May 31 15:41:45 2026 +0200 rose: don't free fd-owned sockets when reaping in the heartbeat The heartbeat reaps orphaned ROSE sockets after their bound device goes down. A socket still attached to a struct socket (sk->sk_socket != NULL -- e.g. an incoming connection an fpad client has accepted and kept open) is owned by that userspace fd: rose_release() frees it on close(). Freeing it from the heartbeat left the fd dangling, so the eventual close() touched freed memory -- slab-use-after-free in rose_release(). Reap only sockets with sk->sk_socket == NULL (unaccepted incoming connections and post-close orphans). For an fd-owned socket whose device went down, disconnect it and fall through to the switch so close() does the teardown. Also release the neighbour reference held by orphaned incoming sockets before tearing them down. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 56576518920edd7b6c3479477d8d490fe2ebdaaa) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sun Jun 14 19:15:27 2026 +0200 rose: don't warn on stray CALL_ACCEPTED/CLEAR_CONFIRMATION in state 3 rose_state3_machine() logs "ROSE: unknown %02X in state 3" at KERN_WARNING for any frame type it does not handle during data transfer. Two of them reach that default arm routinely on real AX.25 links and alarm sysops watching the console, even though they are harmless: - CALL_ACCEPTED (0x0F): a late or duplicated Call Accepted that arrives after the socket has already moved to STATE_3, typically a retransmission on a slow link. - CLEAR_CONFIRMATION (0x17): crossed clearing, or a clear confirmation left over from a previous incarnation of a reused logical channel. In both cases the frame is simply dropped: no state change, no teardown, nothing freed. Only the noise is a problem. Drop these two frame types silently. Keep reporting any other, genuinely unexpected frame type, but through net_warn_ratelimited() so a misbehaving peer cannot flood the kernel log. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 8649e4074ca29a6a8ef0076c2892ebc980b7153f) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Mon Sep 7 14:39:32 2026 +0200 rose: guard rose_transmit_link() against a NULL neighbour rose_kick() and rose_write_internal() call rose_transmit_link(skb, rose->neighbour) without checking that rose->neighbour is still set. Since commit e8eb0c6faa88 ("rose: clear neighbour pointer after rose_neigh_put() in state machines"), the state machines routinely set rose->neighbour to NULL once the underlying AX.25 link is gone, while leaving the socket in ROSE_STATE_3. rose_kick() only checks the state, not the neighbour, so a write() on such a socket reaches rose_transmit_link() with neigh == NULL, which immediately dereferences neigh->loopback and crashes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000036 ... pc : rose_transmit_link+0x14/0x1c8 [rose] lr : rose_kick+0xec/0x198 [rose] Call trace: rose_transmit_link+0x14/0x1c8 [rose] (P) rose_kick+0xec/0x198 [rose] rose_sendmsg+0x260/0x3c8 [rose] Reproduced on f6bvp-8 (a real ROSE/FPAC node) when the BBS daemon wrote to a socket whose neighbour had just been cleared. Confirmed by recompiling rose_link.o with a static_assert on offsetof(struct rose_neigh, loopback), which matches the faulting address (0x36) exactly. Drop the skb and return early when neigh is NULL, matching what rose_transmit_link() already does for other frames it cannot send. Fixes: e8eb0c6faa88 ("rose: clear neighbour pointer after rose_neigh_put() in state machines") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 2aa2cf6eb000bd324c8296a877680186b5df5fe9) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Sep 26 12:38:40 2026 +0200 rose: hold a reference on incoming sockets queued for accept() rose_rx_call_request() creates the socket for an incoming call and queues the call's skb on the listening socket with skb->sk pointing at it, without taking a reference. If the caller clears the call before it is accepted, rose_disconnect() leaves that socket in STATE_0 with SOCK_DEAD set, and since commit "rose: release netdev ref and destroy orphaned incoming sockets" rose_heartbeat_expiry() reaps such orphaned sockets and frees them. The skb stays on the listener's queue, so: - closing the listener makes rose_destroy_socket() walk its queue and set flags and restart the heartbeat on the freed socket; - accept() can hand the freed socket to user space. On a live node running a KASAN kernel, stopping the FPAC daemons shortly after a local (loopback) call had been set up and dropped gave: BUG: KASAN: slab-use-after-free in rose_destroy_socket+0x24a/0x570 [rose] Write of size 8 ... by task fpacwpd rose_destroy_socket rose_release Allocated by task 0: ... rose_rx_call_request <- rose_loopback_timer Freed by task ...: ... sk_free <- rose_heartbeat_expiry refcount_t: addition on 0; use-after-free. rose_start_heartbeat <- rose_destroy_socket <- rose_release followed a few seconds later by a page fault in the re-armed heartbeat and a kernel panic. Make the listener's queue own a reference on each pending socket, taken when the call is queued and dropped by rose_accept() or by the listener's rose_destroy_socket() once the skb is off the queue. Have the heartbeat set SOCK_DESTROY under the socket lock before reaping a dead socket, as the other reaping paths already do, and make both consumers check it under the child's lock: rose_accept() skips a reaped socket and waits for the next call, and rose_destroy_socket() no longer re-arms the heartbeat of a socket that is gone. Fixes: df12be096302 ("rose: release netdev ref and destroy orphaned incoming sockets") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 6b0223a4795f5db52dee038a7a29e9906122b0f7) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 4 16:29:44 2026 +0200 rose: keep the route needed for routing loop detection rose_route_frame() walks the route list before parsing the Call Request facilities. When a CALL REQUEST arrives on a LCI that already belongs to a route, the "Remove an existing unused route" branch deletes that route with rose_remove_route() and breaks out of the walk, so that a new call is able to reuse a stale LCI. The routing loop detection that follows looks for a route recording the same random number and the same pair of callsigns as the incoming call. The route that has just been deleted is exactly the one it would have matched, so a call coming back to us around a routing loop is not detected: it is routed again, a new route is allocated, and the next copy repeats the cycle. Two nodes whose routes point at each other then relay the same call to each other as fast as the CPU allows. This was observed on an AX.25 network where two nodes each believed the route to a third one went through the other. The same CALL REQUEST, carrying the same random number, was re-sent every 400 us, interleaved with CLEAR REQUEST "Not obtainable", diagnostic 120, until the AX.25 link collapsed. Over nine days one node emitted 204 million frames on a link that normally carries a few frames per minute. The outgoing LCI stayed at 001 the whole time, because deleting the route freed it for immediate reuse. Parse the facilities before walking the route list, and in both branches remove the route only when the incoming call differs from the one it records. When it is the same call, keep the route and clear the call with diagnostic 120, which is what the loop detection would have done. The predicate is factored out as rose_same_call() and reused by the loop detection itself. Tested with two ROSE nodes routing a call back to each other. Before this change the kernel relayed 377 CALL REQUEST in ten seconds, never emitted a CLEAR, and the AX.25 link dropped. After it, the first call is relayed once, the next copy is cleared with diagnostic 120, and the link stays up. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit a7e80823ff751d751411f62770bbd61f01be81db) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu Oct 1 14:07:23 2026 +0200 rose: process received frames and send with the socket locked rose_kick() takes frames off the write queue, numbers them from V(S) and moves them to the ack queue. It runs from rose_sendmsg() in process context and from rose_process_rx_frame() in softirq context, and neither holds the socket lock. When a frame for the socket is received on one CPU while a process is sending on another, both read the same V(S) and two different frames go out under the same N(S), or the queues and V(S)/V(A) are updated by one while the other walks them. The peer drops the frames it sees as out of sequence, and since ROSE has no REJ and no retransmission in state 3 the data is lost for good: messages go missing from the stream, or the window fills and the circuit freezes. The timers already take the socket lock and retry when a process owns it. Do the same for the two remaining paths: rose_sendmsg() calls rose_kick() under lock_sock(), and received frames go through rose_rcv_frame(), which takes bh_lock_sock() and queues the frame on the socket backlog when a process owns the socket, as NET/ROM and X.25 do. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, four ROSE circuits each sending 400 numbered messages at the same time (together with the AX.25 fix "ax25: serialise the transmission of I frames on a connection", without which the same happens one layer down): before, 60 to 90 of the 1600 messages are missing from the streams; after, 1600/1600 delivered in order on six runs out of six. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 831b23b977e1fdf14e51dd9652fd27f30965ecb0) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Fri Sep 18 15:38:21 2026 +0200 rose: purge rose_neigh->queue on final teardown rose_transmit_link() queues an outgoing frame on rose_neigh->queue instead of sending it immediately whenever the neighbour isn't "restarted" yet (link not up) -- notably the CLEAR_REQUEST built by rose_write_internal() when a socket is released (e.g. its owning process is killed) while the underlying AX.25 link to that neighbour is still coming up. rose_neigh_put() already tears down both timers and drops the ax25/ digipeat references before freeing the neighbour, but never empties this queue. kfree(rose_neigh) only frees the rose_neigh struct itself (the sk_buff_head embedded in it is just three next/prev/len words), not the skbs still linked into it -- every frame still queued here at that point leaks for good. rose_remove_neigh() (rose_route.c) already purges this same queue, but it is only one of about two dozen call sites that can drop the last reference and trigger the real kfree() in rose_neigh_put() -- every socket releasing its own rose->neighbour reference (af_rose.c, rose_in.c, rose_timer.c) can just as well be the one that does. Doing the purge once, centrally, in rose_neigh_put() itself covers all of them regardless of which call site happens to be last, rather than relying on whichever caller happened to remember it. Matches a leak pattern observed and documented back in May 2026 (mailbbs killed -> rose_release() -> rose_write_internal() -> rose_transmit_link() queues the CLEAR_REQUEST -> skb never freed), never root-caused until now. Deployed and running since 2026-09-13/15 on three independent nodes (f6bvp-12, f6bvp-8, f6bvp-10 -- three different kernel bases, 6.12.94/6.18.46/6.18.34), no regression observed. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit e59e4523182e4f58f4f29b5e4bce44c1ef152d70) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu May 28 19:38:31 2026 +0200 rose: release netdev ref and destroy orphaned incoming sockets Two related cleanup gaps left the module unremovable after a loopback session: 1. rose_destroy_socket() did not release the device reference. When an unaccepted incoming socket (created by rose_rx_call_request()) is destroyed via rose_heartbeat_expiry(), it is removed from rose_list before rose_kill_by_device() can find it, so the netdev_hold() taken in rose_rx_call_request() was never matched by netdev_put(). Add the release at the top of rose_destroy_socket() guarded by a NULL check so that rose_release() and rose_kill_by_device(), which already call netdev_put() and set device = NULL, are not affected. 2. rose_heartbeat_expiry() STATE_0 cleanup required TCP_LISTEN in addition to SOCK_DEAD. Unaccepted incoming sockets are TCP_ESTABLISHED, so the condition was never true and those sockets lingered forever, holding the module use count above zero and blocking rmmod. Drop the TCP_LISTEN restriction: any STATE_0 + SOCK_DEAD socket is orphaned and should be destroyed. Together with the earlier rose_make_new() double-hold fix these three patches allow clean rmmod after loopback sessions. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit df12be096302d2c947388acc25764456c7f18cc1) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Thu Oct 1 12:00:15 2026 +0200 rose: restart the link of a neighbour created over a live AX.25 connection A new neighbour starts with restarted == 0 and waits for the first frame sent to it to start the restart procedure. But when a neighbour is removed from the routing tables and added back (SIOCDELRT then SIOCADDRT, or SIOCRSCLRRT followed by a reload of the routes), the AX.25 connection to it outlives the old entry. The other end has seen nothing: it still regards the link as restarted and will not restart it. On this end rose_get_neigh() only hands out restarted neighbours to through calls, so no frame is ever sent to the new neighbour and nothing starts the restart either. Every call relayed through that neighbour is then refused until one of the two ends happens to originate a call of its own over the link, or the AX.25 connection drops. This happens on a relay node each time its routing daemon restarts: FPAC clears and reloads the routes, the neighbours come back as "restart no" while /proc/net/ax25 still shows their connections established. When rose_add_node() creates a neighbour and an AX.25 connection to it already exists, send the RESTART REQUEST right away and start T0, as rose_transmit_link() does for the first frame. Nothing changes when there is no connection yet: the link is still brought up on demand. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C with A calling C through B, then B removing and re-adding its route to C (or clearing and reloading all its routes): before, the neighbour stays "restart no" on B and A's calls to C are refused for as long as the test runs; after, the neighbour is restarted within three seconds and the first call goes through. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 411b950c8862277a53f4afc6c6c5b3ab00b814be) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Wed May 27 14:11:21 2026 +0200 rose: set SOCK_DESTROY in rose_kill_by_device() for prompt cleanup When rose_kill_by_device() is called (via NETDEV_DOWN on module exit or interface removal), it calls rose_disconnect() which transitions sockets to ROSE_STATE_0 and sets SOCK_DEAD. However, rose_heartbeat_expiry() only calls rose_destroy_socket() at ROSE_STATE_0 if SOCK_DESTROY is set -- the SOCK_DEAD path is reserved for TCP_LISTEN sockets. Without SOCK_DESTROY, orphaned sockets in ROSE_STATE_2 (clearing) loop indefinitely in the heartbeat without ever being freed, keeping the module use-count elevated and blocking modprobe -r rose until the T1 timer (up to 200 s) expires. Set SOCK_DESTROY immediately after rose_disconnect() so the heartbeat destroys the socket at its next tick (within 5 s), allowing clean module unload. Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 741a4863ad570889c75f7a8e404567d8f3e46335) Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Pidoux <[email protected]> Date: Sat Sep 12 12:15:15 2026 +0200 rose: use timer_shutdown_sync() for t0timer teardown rose_t0timer_expiry() re-arms itself via rose_start_t0timer() at its own tail. rose_neigh_put() and rose_remove_neigh() stop it with timer_delete_sync() before freeing (or unlinking) the neighbour, but that only guarantees the callback is not running *at the moment the call returns* -- it does nothing to stop the very invocation that was just waited out from re-arming the timer on its way out. That re-arm races the kfree() in rose_neigh_put(): the timer can fire again on freed memory, and rose_t0timer_expiry() -> rose_transmit_restart_request() -> rose_send_frame() -> ax25_send_frame() dereferences the freed neigh->digipeat, use-after-free. This matches a syzbot report (KASAN slab-use-after-free read in ax25_find_cb()) that stayed open with both cause and fix bisection failing -- consistent with a hole that timer_delete_sync() alone cannot close for a self-rearming timer, a case documented in its own kerneldoc ("there is no way to get this correct with timer_delete_sync()"). Use timer_shutdown_sync() instead in both call sites. Unlike timer_delete_sync(), it also marks the timer so that any further add_timer()/mod_timer() on it is silently ignored, which closes the window regardless of how the self-rearm and the free are interleaved. ftimer's handler is a no-op and never re-arms, but it is switched the same way for consistency: both timers are being torn down for good in both of these call sites. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d Signed-off-by: Bernard Pidoux <[email protected]> (cherry picked from commit 1cc5d2ead3cc0fc370f27728360bf8def008ee18) [ Adjusted context: 6.12 still calls del_timer_sync() in rose_remove_neigh(). ] Signed-off-by: Sasha Levin <[email protected]>
Author: Aswin Karuvally <[email protected]> Date: Thu Aug 27 08:34:08 2026 +0200 s390/ctcm: Prevent XID null dereference commit b264d8422779d69febce914efc47a92a85cc382c upstream. The mpc_validate_xid() function sets grp->saved_xid2->xid2_flag2 to 0x40 to signal XID validation error. If peer XID is NULL or r/w channel pairing mismatch happens, grp->saved_xid2 is never initialized. An attempt to set the flag in such case leads to NULL dereference. Fix this by using the always available priv->xid->xid2_flag2 instead of grp->saved_xid2->xid2_flag2 for validation errors. Fixes: 293d984f0e36 ("ctcm: infrastructure for replaced ctc driver") Cc: [email protected] Signed-off-by: Aswin Karuvally <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Thu Aug 6 11:43:39 2026 +0200 s390/pci: Fix leak of uninitialized kernel data in SCLP report commit 8ac60ae2a307a50b599bf5d300b448d638f3ba29 upstream. While report_error_write() checks that the provided buffer is at least as large as the header struct, but not that it is large enough to contain the report with the length claimed by report->length. If user-space provides a short buffer, meaning a larger report->length than the actually written payload, up to around 4K of kernel data from past the kmalloc(len + 1) sized buffer allocated in kernfs_fop_write_iter() will leak into the SCLP report. However, as the entity processing the SCLP is privileged and able to access at least the page including the report, this does not leak data that entity could not access but it is still an out of bounds read and a malformed error report that should be rejected. Fixes: 368704a65be8 ("s390/pci: add report_error attribute") Cc: [email protected] Signed-off-by: Niklas Schnelle <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sasha Levin <[email protected]> Date: Sun Oct 11 18:33:42 2026 -0400 samples: pidfd: fix userprogs typo [ Upstream commit f1365f97fb7498d805981102eee22d362ae643f2 ] The Makefile adds pidfd-metadata to "usertprogs-always-y", which kbuild does not know, so the sample has not been built since the conversion to userprogs, even with CONFIG_SAMPLE_PIDFD=y. Fix the variable name. pidfd-metadata.c builds without warnings with gcc and clang for x86_64 and arm64. Fixes: 60fb0b1239719 ("samples: pidfd: build sample program for target architecture") Signed-off-by: Sasha Levin <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tejun Heo <[email protected]> Date: Thu Oct 22 10:19:08 2026 -0400 sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ [ Upstream commit 7a9df76679633cf26e0fea882a684012c6ec245a ] With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires. scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds. A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: [email protected] # v6.12+ Reported-by: Xiangyu Bu <[email protected]> Link: https://github.com/sched-ext/scx/pull/3870 Signed-off-by: Tejun Heo <[email protected]> Cc: Dan Schatzberg <[email protected]> [ sashal: Relocated the hunks from separate source and header files into the monolithic sched_ext source file. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Stanley Jhu <[email protected]> Date: Tue Oct 13 21:27:08 2026 +0800 scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies commit ec6b083915e8146e147314a5f4f1285d07b57bfc upstream. bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after the 40-byte header and writes 8 bytes past the end of the buffer. Let each BSG transport pass its reply buffer size to bsg_setup_queue() and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE. Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") Cc: [email protected] Signed-off-by: Stanley Jhu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yehyeong Lee <[email protected]> Date: Wed Oct 7 10:58:40 2026 +0900 scsi: libiscsi: Reject a negative task index from parse_pdu_itt commit 8ee2a09a1dbb257c9e828ad2497f8e4832dfb142 upstream. A transport that implements parse_pdu_itt hands libiscsi an index taken from the PDU, and both lookups bound it from above only: if (i >= session->cmds_max) i and cmds_max are both int, so a negative index passes and session->cmds[i] is read from before the array. be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt; and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also reports the session's own age rather than the one in the tag, which leaves the age comparison in iscsi_verify_itt() with nothing to reject. Bound the index from below in both lookups. Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3") Cc: [email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Yehyeong Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yehyeong Lee <[email protected]> Date: Wed Oct 7 10:58:41 2026 +0900 scsi: libiscsi: Validate the ITT reflected in a Reject PDU commit c5958c770b2a0ee492414e26b07da9164a0d1f5d upstream. A Reject PDU carries a copy of the header it rejects, and iscsi_handle_reject() takes the ITT out of that copy to find the task to clean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt); That value is whatever the target put there. iscsi_itt_to_task() bounds the index against cmds_max and checks nothing else, so any task in the pool can be named, and iscsi_nop_out_rsp() then completes it. An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsi_complete_task() hits its WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning. Validate the reflected ITT the way iscsi_itt_to_ctask() validates a command ITT, and require the task to be in flight and not a SCSI command. [ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] 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 [ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] <IRQ> [ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0 [ 6.256733] iscsi_complete_pdu+0x54/0xa0 [ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250 [ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.258061] __tcp_read_sock+0x1ab/0x810 [ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.259808] tcp_data_queue+0x1f13/0x4cd0 [ 6.260567] tcp_rcv_established+0x8a5/0x3a00 [ 6.261931] tcp_v4_do_rcv+0x449/0x960 [ 6.262269] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 8afa1439fcff ("[SCSI] libiscsi: handle immediate command rejections") Cc: [email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Yehyeong Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yehyeong Lee <[email protected]> Date: Wed Oct 7 10:58:42 2026 +0900 scsi: libiscsi: Validate the task named by a management response commit 11bffcd9cb346732eab2914ef44fe777a3f0b585 upstream. __iscsi_complete_pdu() fetches the task for five response types from one place and checks only that the index resolved: case ISCSI_OP_LOGOUT_RSP: case ISCSI_OP_LOGIN_RSP: case ISCSI_OP_TEXT_RSP: case ISCSI_OP_SCSI_TMFUNC_RSP: case ISCSI_OP_NOOP_IN: task = iscsi_itt_to_task(conn, hdr->itt); if (!task) return ISCSI_ERR_BAD_ITT; iscsi_itt_to_task() bounds the index against cmds_max and looks at nothing else, so a target can name any slot in the pool, including one that has never been used. task->conn is then NULL, and both iscsi_nop_out_rsp() and iscsi_complete_task() dereference it. One unsolicited NOP-In is enough; a Text Response carrying the same ITT crashes in iscsi_complete_task() instead. Require the task to be in flight and not a SCSI command, the way iscsi_itt_to_ctask() does for the command opcodes. [ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.298654] 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 [ 6.298656] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206 [ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020 [ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060 [ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 [ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800 [ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000 [ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0 [ 6.298712] PKRU: 55555554 [ 6.298713] Call Trace: [ 6.298714] <IRQ> [ 6.298714] __iscsi_complete_pdu+0x13a8/0x22a0 [ 6.298758] iscsi_complete_pdu+0x54/0xa0 [ 6.298759] iscsi_tcp_hdr_recv_done+0x870/0x2c80 [ 6.298778] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.298800] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.298804] __tcp_read_sock+0x1ab/0x810 [ 6.298812] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.298814] tcp_rcv_established+0x1f56/0x3a00 [ 6.298842] tcp_v4_do_rcv+0x449/0x960 [ 6.298847] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi") Cc: [email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Yehyeong Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xingui Yang <[email protected]> Date: Mon Sep 28 12:02:34 2026 +0800 scsi: libsas: Fix SMP IO deadlock during HA resume [ Upstream commit 81e097a064b28b4a1f6ca1a8b433e659c1bd64c0 ] smp_execute_task_sg() calls pm_runtime_get_sync() on the host before issuing an SMP command. When that command is itself issued from the HA resume path, the get_sync() deadlocks: it waits for the ongoing resume (the device is RPM_RESUMING), while the resume is blocked in sas_drain_work() waiting for that same SMP IO to complete. The deadlock needs an expander-attached SATA disk. During sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Direct-attached SATA resets through lldd_control_phy() and SSP devices use TMFs, so neither hits this. Replace the get_sync()/put_sync() pair with pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only needs to hold off autosuspend while the SMP is in flight, and it must not try to resume the host: a sync resume issued from the HA resume path itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init has already reinitialized the hardware, so the device is accessible without one. The usage reference is still required. Discovery work normally runs inside an event worker's PM reference, taken at sas_notify_port_event() notify time and held until the handler has flushed the disco queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN from within the revalidation worker itself, and flush_workqueue() does not wait for work items queued during execution, so that chained revalidation runs with no outer PM reference - without the get_noresume(), its SMP could race autosuspend. For the BSG path, sas_smp_handler() is the only caller which may find the host autosuspended: expander SMP requests do not go through any SCSI device request queue, so nothing else in that path holds the host awake. Resume it there with pm_runtime_resume_and_get() and check the result. Fixes: 3dbbbf656b850 ("scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race") Signed-off-by: Xingui Yang <[email protected]> Reviewed-by: John Garry <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurence Oberman <[email protected]> Date: Wed Oct 21 11:55:47 2026 -0400 scsi: st: Fix use-after-free race between st_remove() and st_open() commit 71caf7f84bd62a4bf91cc95abd2de690afb8d15f upstream. st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove() holds it can take the mutex as soon as st_remove() drops it, find the freed tpnt in the idr and call kref_get() on it: BUG: KASAN: slab-use-after-free in st_open Write of size 4 ... st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291) chrdev_open ... Freed by task ...: kfree st_remove (drivers/scsi/st.c:4512) Remove the index from the idr before dropping the reference, all under st_ref_mutex. A concurrent scsi_tape_get() now either runs first and holds a valid reference that keeps the tape alive, or runs afterwards and finds nothing, so st_open() fails with -ENXIO. This restores the ordering st_remove() had before the conversion to st_index_idr, where the tape was unpublished from scsi_tapes[] before the final kref_put(). Fixes: 6c648d95a6af ("[SCSI] st: get rid of scsi_tapes array") Cc: [email protected] Reported-by: Dingisoul <[email protected]> Closes: https://lore.kernel.org/linux-scsi/[email protected]/ Tested-by: Dingisoul <[email protected]> Signed-off-by: Laurence Oberman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> [ loberman: st_remove() still returns int in 6.12; context adjusted ] Signed-off-by: Laurence Oberman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurence Oberman <[email protected]> Date: Tue Oct 6 12:42:50 2026 -0400 scsi: st: Save the visited block for the partition the drive is in [ Upstream commit c9e9f024dd4f61f0f6636c9f2ed0830f87060e11 ] set_location() saves the current tape location before switching partitions, so that switch_partition() can return to it later. It reads the location with READ POSITION but stores it in the st_partstat of STp->partition, ignoring the partition the drive reports. The two differ after a device reset. When the reset is recovered with MTREW, MTSEEK or MTEOM, st_ioctl() sets STp->partition = 0 and calls switch_partition() to return to STp->new_partition. A drive that was in partition 1 is still there, so set_location() files the partition 1 position under partition 0. The next switch to partition 0 locates to that block: if partition 0 holds less data, MTSETPART fails with EIO (BLANK CHECK), otherwise the tape is silently positioned at the wrong block. IBM ULTRIUM-TD5 (LTO-5), LU reset in partition 1 at block 1025: st 12:0:0:0: [st0] Visited block 1025 for partition 0 saved. ... st 12:0:0:0: [st0] Setting block to 1025 and partition to 0. st 12:0:0:0: [st0] Error: 402, cmd: 2b 2 0 0 0 4 st 12:0:0:0: [st0] Sense Key : Blank Check [current] st 12:0:0:0: [st0] Add. Sense: End-of-data detected Store the location in the st_partstat of the partition reported by READ POSITION. With the fix: st 12:0:0:0: [st0] Visited block 1025 for partition 1 saved. This is a pre-existing issue. It was not caught when testing the recent st reset series because the partition test was only run on scsi_debug: on the LTO drive it was skipped, since can-partitions is off in the test harness's stinit.conf, as is normal for LTO. scsi_debug hides the problem because its emulated tape returns to the beginning of partition 0 on an LU reset. It was found while validating a backport of that series to RHEL 9.8, when the partition tests were run on real hardware with can-partitions enabled. The same failure then reproduced on unmodified RHEL 9.8 and on upstream, and the fix makes the test pass on v7.3-rc3 and RHEL 9.8 with an LTO-5. The harness (https://gitlab.com/loberman/tapetest, test X03) now refuses to silently skip the partition tests on hardware. Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset") Assisted-by: Claude Signed-off-by: Laurence Oberman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linfeng Sun <[email protected]> Date: Tue Aug 11 20:48:43 2026 +0800 scsi: target: iscsi: Fix race in discovery auth updates [ Upstream commit e15b81f602edbdee39c335546f25486a1747f3f0 ] Separate configfs opens can concurrently update the discovery AuthMethod parameter. Both callers may free the same value in iscsi_update_param_value(), causing a double-free. Protect the lookup and replacement with the discovery TPG access lock, as used by the other TPG configfs parameter updates. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Linfeng Sun <[email protected]> Reviewed-by: Mike Christie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yehyeong Lee <[email protected]> Date: Mon Oct 5 21:35:54 2026 +0900 scsi: xen/scsifront: Check for a NULL shadow entry on a backend response commit 8c8222c255772713eb36cde695777a1fce224917 upstream. scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NULL pointer. A malicious or buggy backend can thus crash the guest by returning a response whose rqid is in range but not in flight -- for example a spurious response before any command has been issued, or a duplicate of one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots, so before the first command every in-range rqid selects a NULL slot. Reject a response whose shadow slot is not populated. Fixes: 6d1c2f48f3fc ("xen/scsifront: harden driver against malicious backend") Cc: [email protected] Signed-off-by: Yehyeong Lee <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daehyeon Ko <[email protected]> Date: Wed Oct 7 12:57:39 2026 +0900 sctp: revalidate output stream after association connect wait commit b7ad72414c673ce1fa1f463e807cd4f34f8be9bf upstream. When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream can then be in range while its extension remains NULL. The send-buffer wait has the same issue. Factor the range and extension checks into a helper and repeat both after each send-path wait that drops the socket lock. Once the lock is reacquired, the validation remains stable through data creation and queueing. If validation fails after the connect wait, the auto-created association is already established. Return ESRCH so the existing caller path keeps it under state-machine ownership instead of freeing it directly, which would leave protocol, counter and socket state inconsistent. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: [email protected] Assisted-by: LLM Signed-off-by: Daehyeon Ko <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Charles Vosburgh <[email protected]> Date: Thu Aug 27 17:32:53 2026 -0400 sctp: validate chunk length in the inqueue parser commit 6cfc1b90cb86f4aabc69fb8e30128e07e2cdfa3a upstream. SCTP chunks always include a four-byte generic header, but sctp_inq_pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk_end at the current header. When ASCONF is covered by the association's SCTP-AUTH policy, sctp_assoc_bh_rcv() can continue before the state machine performs its normal chunk-length check. sctp_inq_pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up. A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG_IP_SCTP and configured with net.sctp.addip_enable=1 and net.sctp.auth_enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip_noauth_enable=1. On commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation"), one zero-length ASCONF caused repeated watchdog soft-lockup reports in a two-vCPU KVM guest. All 3 pre-trigger health probes succeeded, while 36 of 37 post-trigger probes failed. With this change, all 37 post-trigger probes succeeded and no equivalent soft-lockup signature appeared. Reject chunks shorter than the generic SCTP header at the shared inqueue parser boundary. Mark the packet for discard before either caller can continue processing it, while preserving the four-byte generic minimum. Declared-length 1 through 4 controls and kernel-generated ASCONF traffic remained healthy. The patched sctp_hello selftest passed for IPv4 and IPv6. The complete private reproducer and validation evidence are available directly to maintainers on request. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Cc: [email protected] Signed-off-by: Charles Vosburgh <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Aug 24 14:08:16 2026 +0200 signal: allow taks to temporarily block TIF_NOTIFY_SIGNAL commit 22b7f491be8f93ff72de0a3fe02b8ee9e64d3f21 upstream. TIF_NOTIFY_SIGNAL is used to kick a task in uninterruptible sleep to return to userspace and run task work and then go back to sleep. This mechanism works well but breaks e.g., coredumps. dump_interrupted() only allows fatal signals to interrupt a coredump and the whole regular write path going to actual filesystems is impervious to TIF_NOTIFY_SIGNAL as well. Add PF_NO_NOTIFY_SIGNAL and helpers to raise and restore it. This is the same approach as memalloc_nofs_save(). signal_pending() will not report a fake pending signal via TIF_NOTIFY_SIGNAL if inside a PF_NO_NOTIFY_SIGNAL section. No functional changes. Link: https://patch.msgid.link/[email protected] Reviewed-by: Oleg Nesterov <[email protected]> Cc: [email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Sep 21 15:44:54 2026 +0200 signal: don't retarget shared signals in a dying thread group commit c0e659511d4f49087da095a95799edb5b775a705 upstream. If the calling thread has blocked a signal then retarget_shared_pending() slingshots a shared pending signal to a sibling thread. Today it only skips PF_EXITING threads but not a coredumping thread. But if SIGNAL_GROUP_EXIT is set no thread in the thread-group can dequeue such signals anymore as get_signal() sends SIGKILL to every thread and prepare_signal() drops any other signal. exit_signals() also returns early on SIGNAL_GROUP_EXIT. But neither sigprocmask() nor the mask restore in sigtimedwait() do. Say a thread sleeps in sigtimedwait() and a sibling thread crashes. The sleeping thread gets woken by the zap call. It restores its mask on the way out and retargets a signal that was queued for the coredumping process. That means TIF_SIGPENDING is set on the coredumping task which zap_threads() had cleared. So a blocking write sees TIF_SIGPENDING and truncates the dump. Stop retargeting signals when SIGNAL_GROUP_EXIT is set and avoid needlessly truncating coredumps. Fixes: e6fa16ab9c1e ("signal: sigprocmask() should do retarget_shared_pending()") Cc: [email protected] Acked-by: Oleg Nesterov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Tue Sep 22 15:26:16 2026 +0200 signal: only SIGKILL and the freezers interrupt a coredumping task commit 563d606b93d7a1d23512832fc252d32c68860d87 upstream. For quite a while now coredump has allowed either SIGKILL or freezing to interrupt an ongoing coredump. Since we seem to like it complicated "freezing" can mean a lot of things: (1) Power Management induced freezing (2) cgroup v1 freezer controller induced freezing (3) cgroup v2 freezer controller induced freezing So (1) and (2) are handled by checking freezing() but (3) isn't. (3) uses cgroup_freeze_task() which sets JOBCTL_TRAP_FREEZE and calls signal_wake_up() on every task in the cgroup. The trap isn't handled by the coredump code. Which means the current logic is inconsistent. Power and cgroup v1 freeze and abort the coredump. With cgroup v2 it depends on where the core goes. A dump to a file completes and the cgroup v2 freeze has to wait for it to finish. When dumping to a pipe or socket the dump is interrupted at the next write because of trap's TIF_SIGPENDING. Which is it? Let's be consistent and align (1)-(3): freezing interrupts an ongoing coredump and doesn't make it wait until the dump is done. All three freezers go through signal_wake_up() and so set TIF_SIGPENDING on the dumper. And once zap_threads() has set core_state that flag can't mean anything else anymore. prepare_signal() drops every signal but SIGKILL for the group, the dying threads don't retarget shared signals to the dumper, and zap_process() cleared the pending job control traps. So the flag is the thing to check. Let dump_interrupted() test task_sigpending() and nothing else. That is also what the pipe and socket writes already fail on. TIF_NOTIFY_SIGNAL is left out on purpose, task work must not cut a dump short. A seized tracee that gets PTRACE_INTERRUPT during the dump is cut short the same way. It already was for pipes and sockets. The one freeze that check can miss is one requested before the dump started. zap_threads() clears TIF_SIGPENDING and the cgroup v2 freezer only wakes a task once while its JOBCTL_TRAP_FREEZE isn't part of JOBCTL_PENDING_MASK and survives zap_process(). So refuse to start the dump when freezing() is true or the trap is pending. The task then exits without dumping, which is what happens today when the freeze interrupts the dump at the first write. Fixes: 403bad72b67d ("coredump: only SIGKILL should interrupt the coredumping task") Fixes: 76f969e8948d ("cgroup: cgroup v2 freezer") Cc: [email protected] Suggested-by: Oleg Nesterov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Frank Sorenson <[email protected]> Date: Wed Aug 26 21:13:36 2026 -0500 smb: client: fix heap overflow in cifs_do_set_acl() commit 1dac61e2c29d1a71784604b48cf3b1234a65ec29 upstream. cifs_set_acl() validates ACL size using posix_acl_xattr_size(): 4 + (count * 8) // 4-byte header + 8 bytes per ACE cifs_do_set_acl() then calls posix_acl_to_cifs() to write the CIFS wire format into the same buffer: 6 + (count * 10) // 6-byte header + 10 bytes per ACE An ACL that passes the xattr-based check in cifs_set_acl() can overflow the heap when posix_acl_to_cifs() writes the larger CIFS format. Validate the CIFS format size against the remaining buffer space and USHRT_MAX before converting--data_count is __u16, so sizes above USHRT_MAX truncate the on-wire packet length, causing the server to apply a partial ACL. Replace MaxDataCount = 1000 with min(CIFSMaxBufSize, USHRT_MAX). Fixes: dc1af4c4b4721 ("cifs: implement set acl method") Cc: [email protected] Signed-off-by: Frank Sorenson <[email protected]> Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paulo Alcantara <[email protected]> Date: Mon Aug 24 16:59:12 2026 -0300 smb: client: fix multiuser mount with krb5 commit 69499395867332364ed4ac8b546537eb3bab6ebb upstream. Customer reported that they could no longer mount their SMB shares with multiuser mount option and krb5. Turned out that the client wasn't duplicating username option when creating multiuser connections, therefore failing to retrieve credentials as cifs.upcall(8) couldn't find them in keytab. Fix this by duplicating username option (if set) from original fs context before creating multiuser connections with krb5. Reproducer: ``` $ ktutil ktutil: add_entry -password -p testuser -k 1 -e aes256-cts Password for [email protected]: ktutil: write_kt /etc/krb5.keytab ktutil: quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 [email protected] (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o \ uid=1000,sec=krb5,[email protected],multiuser mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) ``` Reported-by: Jacob Shivers <[email protected]> Fixes: 12b4c5d98cd7 ("smb: client: fix krb5 mount with username option") Cc: Ronnie Sahlberg <[email protected]> Cc: Shyam Prasad N <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Bharath SM <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: [email protected] Reviewed-by: Namjae Jeon <[email protected]> Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinhui Guo <[email protected]> Date: Tue Aug 4 20:19:10 2026 +0800 soc/tegra: fuse: Add missing newline to APBMISC error message [ Upstream commit 2f4a0fb66d313f03832f061bc3ec25b33c8198c9 ] The error message printed by tegra_acpi_init_apbmisc() when failing to get APBMISC memory resources is missing a trailing newline. This can cause the message to be merged with the following kernel log line, making the log harder to read. Add the missing newline to keep the error output properly formatted. Fixes: 7b0c505eb341 ("soc/tegra: fuse: Add tegra_acpi_init_apbmisc()") Signed-off-by: Jinhui Guo <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Jones Jr <[email protected]> Date: Fri Oct 2 16:55:40 2026 +0800 spi: tegra114: assert CS GPIO for every transfer in a message [ Upstream commit 8980bc573ae2d2b9d86d76aeb86c76e1597070bf ] The driver provides its own transfer_one_message() and therefore drives the chip-select GPIO itself rather than through the SPI core. The GPIO is asserted only in the is_first_of_msg path of tegra_spi_setup_transfer_one(), but tegra_spi_transfer_end() deasserts it whenever a transfer has cs_change set. For a multi-transfer message whose earlier transfers request cs_change -- for example a register read that sends the address in one transfer and clocks the data back in the next -- the CS GPIO is released after the first transfer and never re-asserted, so the remaining transfers are clocked with chip-select inactive and the peripheral never drives the bus. This was observed with an ADIS16470 IMU (adis16475 driver), whose register read is a two-transfer, cs_change-framed exchange: a logic analyzer showed the data frame clocked with CS high, and the driver read 0 while the device drove 0x4056 on the wire. Re-assert the CS GPIO for every transfer so that multi-transfer messages keep chip-select active across the whole message. gpiod_set_value() is idempotent and polarity-aware, so this is a no-op for the first transfer and for messages that keep CS asserted throughout. Fixes: 63c1440596ff ("spi: tegra114: add support for gpio based CS") Signed-off-by: Carlos Jones Jr <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Date: Thu Aug 27 19:55:11 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO) commit 385e474086c2e7e29e2dded690be40dc273e20ee upstream. do_tcp_getsockopt() reads icsk->icsk_ca_ops and dereferences the get_info function pointer without rcu_read_lock(). With BPF struct_ops congestion control, ca_ops can point to dynamically allocated memory that is freed concurrently, resulting in a use-after-free when the kernel dereferences or calls through the stale pointer. BUG: KASAN: slab-use-after-free in do_tcp_getsockopt+0x2037/0x23e0 Read of size 8 at addr ffff888013701258 by task exploit/149 do_tcp_getsockopt+0x2037/0x23e0 (net/ipv4/tcp.c:4564) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by wrapping the ca_ops load and get_info call within rcu_read_lock()/rcu_read_unlock(), and using READ_ONCE() to load the icsk_ca_ops pointer. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Reviewed-by: Jiayuan Chen <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/65fd3816ed5d541d9edd4bf4fcf97104a2cf907a.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Date: Thu Aug 27 19:55:10 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) commit 5271b79b7ad68dcb222e893773f92bdabf7750f3 upstream. do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding rcu_read_lock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf"), icsk_ca_ops can point to dynamically allocated BPF struct_ops memory that may be freed concurrently via setsockopt(TCP_CONGESTION), leading to a use-after-free. BUG: KASAN: slab-use-after-free in _copy_to_user+0x37/0x60 Read of size 16 at addr ffff888013505260 by task exploit/149 _copy_to_user+0x37/0x60 do_tcp_getsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by holding rcu_read_lock() around the ca_ops->name access, using READ_ONCE() to load icsk_ca_ops, and copying the name to a stack buffer before releasing the lock. Also annotate the relevant icsk_ca_ops stores with WRITE_ONCE() to fix the accompanying KCSAN data-race issue. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet <[email protected]> Reported-by: Xiang Mei (Microsoft) <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Cc: [email protected] Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) <[email protected]> Reviewed-by: Jiayuan Chen <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/d3f97f1acbf0010898148be6e6406e4b8b4a5c84.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Wed Aug 26 03:01:41 2026 +0800 tipc: protect node reset trace dump with node lock commit dddf197f29ba5e47a476dde82bf542ca2e0d5e5e upstream. The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link tipc_node_write_lock() kfree(l) n->links[0].link = NULL tipc_node_write_unlock() tipc_link_dump(l) tipc_link_dump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock. Fixes: eb18a510b5cd ("tipc: add trace_events for tipc node") Cc: [email protected] Signed-off-by: Chengfeng Ye <[email protected]> Reviewed-by: Tung Nguyen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Len Brown <[email protected]> Date: Sun May 3 14:17:54 2026 -0400 tools/power turbostat: Fix add_counter issue if > 24 counters. [ Upstream commit 154b96dab83fd953b9b82c8bcfa041cd6a9d74d3 ] We allocate space for added counters ahead of time, and we arbitrarily chose 24 added counters of each type. If a future code flow hits this limit and continues, and then removes counters, we do a phantom increment and lose track of the number of added counters. Increment the count only if there is no error. Fixes: 388e9c8134be ("tools/power turbostat: Make extensible via the --add parameter") Assisted-by: Claude: Claude Sonnet 4.6 Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Thu Apr 30 21:28:19 2026 -0400 tools/power turbostat: Fix fd_perf leak on reset [ Upstream commit 767c64414c4c5fffd6cbc3a1cf1fb8138b28645b ] When turbostat notices a topology change, it frees perf file descriptors for each CPU to prepare to re-initialize. Fix an off-by-one error in that per-cpu loop that resulted in a file descriptor leak of the file for the highest numbered CPU in the system. Fixes: 67bab430f4e7 ("tools/power turbostat: Group SMI counter with APERF and MPERF") Assisted-by: GitHub Copilot (claude-sonnet-4.6) Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Levin <[email protected]> Date: Sun Oct 11 18:33:33 2026 -0400 tools: gpio: fix building from the top level with O= commit 52336337f1a01ad803c7f3ddb23f40222e9ad58d upstream. "make O=<dir> tools/gpio" fails: Makefile:27: /tools/build/Makefile.include: No such file or directory tools/Makefile clears srctree, and the gpio Makefile only works it out again when building_out_of_srctree is not set, which the top-level Makefile sets for O= builds. Also work out srctree when it is empty, as tools/bpf/Makefile does since commit a89b2cbf71d64 ("tools, bpf: Fix build for 'make -s tools/bpf O=<dir>'"). Fixes: 4a6a6f5c4aeed ("tools: gpio: Use !building_out_of_srctree to determine srctree") Cc: [email protected] Assisted-by: LLM Signed-off-by: Sasha Levin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lee Jones <[email protected]> Date: Tue Oct 13 11:24:48 2026 +0000 tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields commit a244c241593b5b38a08f0df2cb43c26574efbdcb upstream. In check_synth_field(), when a synthetic event field is a stacktrace (field->is_stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison. Because parse_synth_field() sets a stacktrace field's type to "__data_loc unsigned long[]", its size is sizeof(u64) and synth_field_signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently dereferenced as a kernel stacktrace pointer in get_field_size() and trace_stack(). Furthermore, checking strstr(hist_field->type, "long[") is insufficient because tracepoint fields defined with __bitmask() or __rel_bitmask() also have type "__data_loc unsigned long[]" or "__rel_loc unsigned long[]", whilst create_hist_field() treats them as 4-byte scalar values without HIST_FIELD_FL_STACKTRACE. Propagate HIST_FIELD_FL_STACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HIST_FIELD_FL_STACKTRACE and field->is_stack in check_synth_field(). Cc: [email protected] Fixes: 00cf3d672a9d ("tracing: Allow synthetic events to pass around stacktraces") Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lee Jones <[email protected]> Date: Mon Oct 19 12:07:29 2026 +0000 tracing/histograms: Verify event_call identity when updating synth_event refcount commit 3403d9bb27ebc3572bd048620746b4414e073bf9 upstream. In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref. Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Taeyang Lee <[email protected]> Date: Fri Oct 16 02:19:55 2026 +0900 tracing: Check operator stack capacity before pushing commit c47a7b11bcb3d45e29723afcf6336866476b1d08 upstream. predicate_parse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack. Reject the push when top reaches the last allocated entry. Cc: [email protected] Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/[email protected] Signed-off-by: Taeyang Lee <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amit Machhiwal <[email protected]> Date: Fri Oct 9 22:05:56 2026 +0530 tracing: Do not initialize tracefs work if tracing is disabled commit b3b974008388ab59e44d764ba7a63c988fec2524 upstream. If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash. Cc: [email protected] Fixes: 6621a7004684 ("tracing: make tracer_init_tracefs initcall asynchronous") Link: https://patch.msgid.link/[email protected] Reported-by: Michal Suchánek <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Amit Machhiwal <[email protected]> Tested-by: Michal Suchánek <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donggeun Yoo <[email protected]> Date: Thu Sep 17 10:55:32 2026 +0900 tracing: Fix 64-bit and signed histogram fields on 32-bit kernels commit 443d23176812803d0fa182b8d05ef066a7b8271f upstream. DEFINE_HIST_FIELD_FN() reads a trace event field and widens it to the u64 the histogram uses as a key or a value: type *addr = (type *)(event + hist_field->field->offset); return (u64)(unsigned long)*addr; unsigned long is 32 bits on a 32-bit kernel, so the intermediate cast discards the upper half of a 64-bit field, and widens a signed field by zero extension from 32 bits rather than sign extension from its own width. Five of the eight instantiations are wrong there: s64, u64, s32, s16 and s8. The cast came in with commit 79e577cbce4c ("tracing: Support string type key properly"), which also added hist_field_dynstring() and hist_field_pstring(). Those convert a char * to u64 and do warn without an unsigned long in between on 32-bit. DEFINE_HIST_FIELD_FN() converts an integer and never a pointer, so it gains nothing from the cast and only loses information. Drop the intermediate cast and let the usual arithmetic conversions widen *addr according to its own type. unsigned long is 64 bits on LP64, so the two forms are identical there and 64-bit kernels are unaffected. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 79e577cbce4c ("tracing: Support string type key properly") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Donggeun Yoo <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tengda Wu <[email protected]> Date: Tue Sep 29 10:40:15 2026 +0000 tracing: Fix hist trigger timestamps for buffered events commit 9414ca3b99e5a7f1f3bf51c2a01b383e1b355dd0 upstream. Syzkaller triggered a WARN_ON_ONCE(!nest) warning: WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp Call trace: ring_buffer_event_time_stamp hist_field_timestamp hist_fn_call event_hist_trigger event_triggers_call __event_trigger_test_discard trace_event_buffer_commit do_trace_event_raw_event_sched_switch trace_event_raw_event_sched_switch The warning is probabilistically reproducible and is related to syzkaller executing the following commands: echo 'prev_pid == 999999' > events/sched/sched_switch/filter echo 'hist:keys=common_timestamp' > events/sched/sched_switch/trigger The specific triggering process is as follows: CPU 0 CPU 1 (context switching) (echo 'hist:keys=common_timestamp' > \ events/sched/sched_switch/trigger) do_trace_event_raw_event_##call trace_event_buffer_lock_reserve if (!tr->no_filter_buffering_ref && trace_file->flags & EVENT_FILE_FL_FILTERED) return entry; // return directly event_hist_trigger_parse hist_register_trigger tracing_set_filter_buffering(file->tr, true); tr->no_filter_buffering_ref++; __trace_buffer_lock_reserve rb_start_commit local_inc(&cpu_buffer->committing); // skipped and not executed trace_event_buffer_commit __event_trigger_test_discard event_triggers_call event_hist_trigger hist_fn_call hist_field_timestamp ring_buffer_event_time_stamp nest = local_read(&cpu_buffer->committing); WARN_ON_ONCE(!nest) // trigger warning The root cause is that when an event file has a filter attached and the hist trigger has not yet been attached, trace_event_buffer_lock_reserve() writes the event into the per-CPU trace_buffered_event temp buffer instead of reserving it in the ring buffer, so cpu_buffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, hist_field_timestamp() -> ring_buffer_event_time_stamp() sees a zero committing count, triggering WARN_ON_ONCE(!nest). tracing_event_time_stamp() was added by commit d8279bfc5e959 ("tracing: Add tracing_event_time_stamp() API") for exactly this case: if the event is the per-CPU trace_buffered_event, it returns the current ring buffer timestamp. But it never gained a caller. Use it in hist_field_timestamp(), so that a hist trigger that races onto a buffered event records the current time, which is only marginally later than when the event was recorded, instead of warning and recording a bogus timestamp. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: b94bc80df648 ("tracing: Use a no_filter_buffering_ref to stop using the filter buffer") Signed-off-by: Tengda Wu <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Kandybka <[email protected]> Date: Thu Oct 22 09:42:46 2026 -0400 tracing: Fix ignored return value of resize_buffer_duplicate_size() [ Upstream commit 3110d09bb98e3ac66482a7b257548a1683ec6c1a ] When tr->allocated_snapshot is true, resize_buffer_duplicate_size() is called to update the snapshot buffer size. However, its return value was not checked. In case of a failed resize this could lead next snapshot being incomplete. Add resize_buffer_duplicate_size() result check and return error if resize fails. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 180e4e390978 ("tracing: Add snapshot refcount") Signed-off-by: Dmitry Kandybka <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> [ sashal: Adapted the resize call to use max_buffer instead of snapshot_buffer. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Donggeun Yoo <[email protected]> Date: Wed Sep 16 09:27:35 2026 +0900 tracing: Fix the shift out of bounds in the log2 histogram modifier commit 647c2f97fcb94bc642cefe6db004999974563f06 upstream. The .log2 key modifier files a value under its base-2 order: # echo 'hist:keys=bytes_req.log2' > events/kmem/kmalloc/trigger hist_field_log2() computes that as ilog2(roundup_pow_of_two(val)). The out-of-line form of roundup_pow_of_two() is return 1UL << fls_long(n - 1); which shifts by 64 on a 64-bit kernel both when n is 0, where n - 1 wraps to ULONG_MAX, and when n is above 2^63. Both are ordinary keys, because the field fetch hands every value over as a u64: a syscall argument of 0 reaches the first, and one above 2^63 reaches the second. Keying sys_enter_lseek on offset.log2 and passing 0, 1, 2, 3, 1000, 2^63+1 and U64_MAX gives { offset: ~ 2^1 } hitcount: 1 { offset: ~ 2^10 } hitcount: 1 { offset: ~ 2^2 } hitcount: 1 { offset: ~ 2^0 } hitcount: 4 Keys above 2^63 land in the lowest bucket. With CONFIG_UBSAN_SHIFT=y the shift is also reported: UBSAN: shift-out-of-bounds in include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' __ubsan_handle_shift_out_of_bounds.cold+0xdd/0x1cb hist_fn_call.cold+0x8b/0xd9 event_hist_trigger+0x1cc/0x790 ftrace_syscall_enter+0x197/0x360 do_syscall_64+0x402/0x4b0 Use order_base_2(), which is ilog2(n - 1) + 1 for n > 1 and 0 below that. It returns what the old expression returned on every input the old one was defined for. Where it was not, 0 stays in bucket 0, which is where x86_64 had been putting it, and the keys above 2^63 move into bucket 64. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 4b94f5b7b4a5 ("tracing: Add hist trigger 'log2' modifier") Signed-off-by: Donggeun Yoo <[email protected]> Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Taeyang Lee <[email protected]> Date: Thu Oct 22 09:42:41 2026 -0400 tracing: Keep the predicate limit separate from program capacity [ Upstream commit 803aa6fc2dbea25ab9d3ed19eca1c96d0ab17445 ] predicate_parse() adds two to nr_preds to reserve the terminal TRUE and FALSE entries. It also uses that increased value as the limit for parsed predicates. If the initial count is smaller than the number actually parsed, the program can fill the allocation and subsequent accesses can go past its end. Keep nr_preds as the predicate limit and use a separate value for the allocation size. This leaves space for both terminal entries and a zeroed entry when parsing stops at the limit. Cc: [email protected] Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/[email protected] Signed-off-by: Taeyang Lee <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> [ sashal: adapted the allocation change to use kcalloc() instead of kzalloc_objs(). ] Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Wed Oct 14 10:37:40 2026 +0200 tracing: probes: error if BTF is required but unavailable [ Upstream commit 66c658033d842bb75f81f20aaa4a378fe47be1a1 ] traceprobe_expand_meta_args expands probe arguments based on BTF info. Return an error if we have arguments that need expanding but BTF is not supported. The params variable is now unused, it can be removed. Link: https://lore.kernel.org/all/[email protected]/ Fixes: d157d7694460 ("tracing/probes: Support BTF field access from $retval") Signed-off-by: Martin Kaiser <[email protected]> Reviewed-by: Steven Rostedt <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Fri Oct 23 10:46:20 2026 -0700 tracing: Reject incomplete event filter expressions commit 1fdc4164e488916402badddbb1f51e9380dabb91 upstream. A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations. Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Assisted-by: Codex:gpt-6-astra Acked-by: Masami Hiramatsu (Google) <[email protected]> Tested-by: JongHyuk Kim(MalHyuk) <[email protected]> Signed-off-by: Kyle Zeng <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donggeun Yoo <[email protected]> Date: Tue Sep 15 08:47:54 2026 +0900 tracing: Save the event file instead of the compatible histogram commit d5c42664fc094899af9aae5300b27fe8fdb658ef upstream. create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger. Cc: [email protected] Reported-by: Sashiko <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Link: https://patch.msgid.link/[email protected] Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo <[email protected]> Assisted-by: Claude:claude-fable-5 Acked-by: Tom Zanussi <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Carlier <[email protected]> Date: Mon Sep 14 14:35:04 2026 +0100 tracing: Take trace_types_lock when dropping the buffer_meta reference commit 2afe7575fb24b9d0476ae4a3a9862f7997216aa4 upstream. tracing_buffer_meta_open() drops the trace_array reference with __trace_array_put() when ring_buffer_meta_seq_init() fails, without holding trace_types_lock. Use trace_array_put() like every other open error path. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Signed-off-by: David Carlier <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donggeun Yoo <[email protected]> Date: Mon Sep 14 19:40:36 2026 +0900 tracing: Unregister field variable histograms when the command fails commit 91c14d6c13096091c56304120aaa26e479130b8b upstream. An action that names a field on another event needs that field as a variable, so create_field_var_hist() registers a second hist trigger on that event to provide it, and records it in target_hist_data->field_var_hists[]. If a later part of the same command fails, create_actions() returns an error and event_hist_trigger_parse() jumps to out_free. The write fails with -EINVAL and sched_switch gets no trigger, but: # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int a; int b' >> synthetic_events # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)'\ >> events/sched/sched_switch/trigger # cat events/sched/sched_waking/trigger hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global [active] hist:keys=pid:vals=hitcount:synthetic_prio=prio:sort=hitcount:size=2048 [active] The second histogram is the one created for 'prio'. It is still active and still counting. out_free reaches destroy_field_var_hists(), which frees the field_var_hists[] entries, but never unregister_field_var_hists(), which is what removes the triggers and runs only from event_hist_trigger_free(). The entry is freed and the trigger is left with nothing tracking it. Unregister the field variable histograms in out_free as well, and record each one as soon as its trigger is registered rather than after the lookup that follows it, so no exit can leave a registered trigger untracked. The entry then belongs to field_var_hists[] and is released by destroy_field_var_hists(), so freeing it on that exit would be a double free. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Donggeun Yoo <[email protected]> Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Fri Oct 9 23:51:56 2026 +0200 unicode: free the map after a grace period commit a96c5299bd7305eb984377681eb3222a57376405 upstream. generic_ci_d_hash() and generic_ci_d_compare() read sb->s_encoding and dereference the unicode map while a pathwalk in rcu mode holds nothing but rcu_read_lock(). The filesystems that use them, ext4, f2fs and tmpfs, drop the map with utf8_unload() from ->put_super(), which runs when the last reference to the mount goes away. A lookup that is still inside such a filesystem at that point reads a freed map. With a pathwalk held up in utf8_casefold_hash() while the last reference to a casefolded tmpfs goes away: BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950 Read of size 8 at addr ff110001030fe658 by task walker/98 Call Trace: <TASK> utf8nlookup+0x74c/0x950 utf8byte+0x160/0x1560 utf8_casefold_hash+0x167/0x230 generic_ci_d_hash+0xdd/0x1c0 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 94: __kmalloc_cache_noprof+0x249/0x560 utf8_load+0x4e/0x570 shmem_parse_opt_casefold.isra.0+0x92/0x270 [...] Freed by task 97: kfree+0x1db/0x5b0 shmem_put_super+0x72/0x170 generic_shutdown_super+0x14c/0x530 kill_anon_super+0x3a/0x60 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. So it is reachable. Delay the free until a grace period has passed. The map and the data table it holds a reference to then outlive any pathwalk that found the superblock before the mount went away. The reference on the data table module is dropped from the rcu callback as well. utf8-core is built in whenever CONFIG_UNICODE is set, so there is no module exit that would have to wait for the callbacks. Overlayfs points the s_encoding of an overlay at the map of its first layer without taking a reference of its own. That stays correct. The layer is held by the overlay, so its map is dropped only after the overlay is gone. Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bobby Eshleman <[email protected]> Date: Thu Oct 22 13:11:38 2026 -0400 virtio: set skb owner of virtio_transport_reset_no_sock() reply [ Upstream commit a6ae12a599e0f16bc01a38bcfe8d0278a26b5ee0 ] Associate reply packets with the sending socket. When vsock must reply with an RST packet and there exists a sending socket (e.g., for loopback), setting the skb owner to the socket correctly handles reference counting between the skb and sk (i.e., the sk stays alive until the skb is freed). This allows the net namespace to be used for socket lookups for the duration of the reply skb's lifetime, preventing race conditions between the namespace lifecycle and vsock socket search using the namespace pointer. Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Bobby Eshleman <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Stable-dep-of: dee44f41f206 ("vsock/virtio: validate packet source for connected sockets") Signed-off-by: Sasha Levin <[email protected]>
Author: Daehyeon Ko <[email protected]> Date: Thu Oct 22 13:11:39 2026 -0400 vsock/virtio: validate packet source for connected sockets [ Upstream commit dee44f41f206becb41c492899c1996cfd7f82a1b ] virtio_transport_recv_pkt() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback is needed for listening and connecting sockets, but sockets remain in the bound table after connect(), so it can also return a non-listening socket. The fallback does not validate the source address. In TCP_SYN_SENT, a RESPONSE from an unrelated source can transition the victim socket to TCP_ESTABLISHED while its stored remote address remains unchanged. Subsequent RW packets from that source are delivered through the same destination-only fallback. This was reproduced with capability-empty processes under different UIDs. The attacker discovered the target tuple through unprivileged AF_VSOCK sock_diag and caused the victim socket to read 16 attacker-chosen bytes; the intended peer-side socket read 0 of those 16 bytes. Add vsock_check_source() to validate the transport, source port and source CID against the peer stored in a non-listening socket. The local transport is the CID exception because its packets are generated internally with VMADDR_CID_LOCAL as their source, including connections using CID aliases. Use the helper after lock_sock() in the virtio receive path. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Closes: https://lore.kernel.org/netdev/[email protected]/ Cc: [email protected] Suggested-by: Stefano Garzarella <[email protected]> Reviewed-by: Bobby Eshleman <[email protected]> Signed-off-by: Daehyeon Ko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ sashal: adjusted context for socket lookup and reset helpers without network namespace parameters ] Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Luczaj <[email protected]> Date: Mon Oct 5 02:26:22 2026 +0200 vsock: treat TCP_CLOSING as once-established [ Upstream commit 4f6ac74fa594a918d41255c941256e1d51592d3b ] Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending(). Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table. list_add double add: new=, prev=, next=. kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:__list_add_valid_or_report+0x11f/0x130 Call Trace: vsock_insert_connected.cold+0xe/0x13 virtio_transport_recv_pkt+0x10e9/0x1460 vsock_loopback_work+0x305/0x480 process_one_work+0xe4c/0x1560 worker_thread+0x4f1/0xd60 kthread+0x36e/0x470 ret_from_fork+0x47b/0x6b0 ret_from_fork_asm+0x1a/0x30 This fix is supplementary to commit 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established"). Details under Link. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Hyunwoo Kim <[email protected]> Link: https://lore.kernel.org/netdev/anzT1fREOSyHT99k@v4bel/ Signed-off-by: Michal Luczaj <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang (Microsoft) <[email protected]> Date: Wed Oct 21 11:29:45 2026 -0400 watch_queue: Fix note pool publication race in watch_queue_set_size() [ Upstream commit 5e531d62f1f8834faf7a4eed0d41105cf6570a8f ] There is a race between watch_queue_set_size() and post_one_notification(). watch_queue_set_size() publishes wqueue->notes, notes_bitmap, nr_pages and nr_notes with plain stores, and post_one_notification() reads them with plain loads under a different lock, so nothing orders the four stores against the poster's loads: depending on the build, notes can be stored last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch attach to a queue before it is sized, post_one_notification() can already be running on another CPU at that moment: it reads nr_notes > 0, passes its bounds check, and then reads notes while it is still NULL, dereferencing notes[0]. An unprivileged user triggers this reliably by watching one of its own keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE) on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU, triggering: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt Fix this by publishing nr_notes last with smp_store_release(), and by reading it once with smp_load_acquire() in post_one_notification() before the bitmap and the page array are touched. A poster that observes a non-zero nr_notes then also observes the pool behind it; one that observes zero drops the notification as before. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: Dae R. Jeong <[email protected]> Closes: https://lore.kernel.org/all/ZT-S8Q7tyutcvu_q@dragonet/ Reported-by: [email protected] Suggested-by: Dae R. Jeong <[email protected]> Signed-off-by: Cen Zhang (Microsoft) <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Bradley Morgan <[email protected]> Cc: <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heyang Tan <[email protected]> Date: Fri Sep 18 16:33:49 2026 +0800 wifi: p54: validate firmware record lengths commit db7b86bd97b380ece8fa39cfdd7502a9fd35e56f upstream. The p54 firmware parser accesses component ID and component version records without checking that their lengths cover the fields being read. A malformed record can therefore make the parser read past the record. Validate the component ID and component version record lengths before accessing their data. The descriptor record is also checked against the shortest descriptor length found in the supported firmware images. Reject descriptor values that underflow the RX offset or produce an empty RX range before updating the driver state. Assisted-by: LLM Codex Signed-off-by: Heyang Tan <[email protected]> Tested-by: Christian Lamparter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yao Kai <[email protected]> Date: Thu Oct 22 12:15:09 2026 -0400 workqueue: Fix unbound pool lifetime for pending pwqs [ Upstream commit cf9c8aaea0d47410df8708bec195889f3a85cd3c ] KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq(): BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318 CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450 Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610 Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790 Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock. Remove the pwq from pending_pwqs before putting the pool. Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues") Cc: [email protected] Signed-off-by: Yao Kai <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Oct 22 12:15:08 2026 -0400 workqueue: release pwq pools by pool type [ Upstream commit 3180ee71b676845603274c66f6bb5528939cf470 ] Add is_percpu_pool() and test the pool directly for per cpu. Convert the other open-coded pool->cpu checks -- in put_unbound_pool(), pool_allowed_cpus() and the workqueue watchdog -- to the same helper. No functional change. Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Use a single-evaluation macro for is_percpu_pool() so the predicate conversion does not add a function. Keep the existing watchdog stall accounting; only its pool-type check needs to change. This preserves the release-path context needed by the pending-pwq lifetime fix. Stable-dep-of: cf9c8aaea0d4 ("workqueue: Fix unbound pool lifetime for pending pwqs") Signed-off-by: Sasha Levin <[email protected]>
Author: Zqiang <[email protected]> Date: Thu Jul 16 17:56:37 2026 +0800 workqueue: Use raise_softirq() to trigger softirq in irq_work handler commit 7e2f2a377ac9f50296ad60bd331f0d4def7aee51 upstream. bh_pool_kick_normal() and bh_pool_kick_highpri() are registered via init_irq_work() without the IRQ_WORK_HARD_IRQ flag. On PREEMPT_RT, such irq_work items are processed by the per-CPU irq_workd kthread in preemptible task context with IRQs enabled. However, raise_softirq_irqoff() requires IRQs to be disabled. Calling it from irq_workd trips the lockdep assertion in __raise_softirq_irqoff() and the non-atomic update of the softirq pending mask can lose bits raised by an interrupt on the same CPU. Replace raise_softirq_irqoff() with raise_softirq() in the irq_work handlers. Fixes: 2f34d7337d98 ("workqueue: Fix queue_work_on() with BH workqueues") Cc: [email protected] # v6.9+ Signed-off-by: Zqiang <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Kelley <[email protected]> Date: Tue Sep 1 20:01:27 2026 -0700 x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() [ Upstream commit 7b74c117e2aac78e0f723e1c9c3644451c56b0d9 ] hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts. Fixes: 86c48271e0d6 ("x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()") Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Tianyu Lan <[email protected]> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: EJ Campbell <[email protected]> Date: Tue Sep 29 11:12:32 2026 -0700 x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context commit 81d99abe2bd81379abfb595e403bbbee6fbfc624 upstream. An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apf_reason.flags until __kvm_handle_async_pf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics: Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: <NMI> panic+0x52/0x60 __kvm_handle_async_pf+0xb0/0xb0 exc_page_fault+0x71/0xb0 asm_exc_page_fault+0x27/0x30 RIP: 0010:__get_user_nocheck_8+0x6/0x20 perf_callchain_user+0x147/0x1a0 get_perf_callchain+0x12d/0x1c0 ... perf_event_nmi_handler+0x26/0x50 exc_nmi+0xe8/0x110 RIP: 0010:asm_exc_page_fault+0x0/0x30 </NMI> The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with __get_user(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after a #PF VM-exit. The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged. Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact. Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvm_async_pf_not_present events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it. Link: https://lore.kernel.org/all/ed71d0967113a35f670a9625a058b8e6e0b2f104.1583547991.git.luto@kernel.org/ [1] Link: https://lore.kernel.org/all/[email protected]/ [2] Cc: [email protected] # v5.9+ Signed-off-by: EJ Campbell <[email protected]> Link: https://patch.msgid.link/CADkxfh-uQTca_6jB1JPDq1MsKffF_UKGQR339oQSJNcoV75GNQ@mail.gmail.com Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yun Zhou <[email protected]> Date: Thu Oct 22 10:34:33 2026 -0400 xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf [ Upstream commit 41a28c865d1d5843f8cb9e0af17a8f4d9e2961ff ] xfs_sync_sb_buf() holds sb/rtsb buffer locks across a synchronous xfs_trans_commit(), which flushes the CIL push workqueue internally. If shutdown occurs during the CIL push, xfs_buf_item_unpin() needs to lock these buffers to fail them, causing a deadlock: setlabel: holds buf lock -> flush_workqueue(xfs-cil) CIL push worker: xfs_buf_item_unpin -> xfs_buf_lock(same buf) Remove the xfs_trans_bhold() calls so that commit releases the buffer locks normally. After the sync commit, re-acquire the buffers via mp->m_sb_bp / mp->m_rtsb_bp for the on-disk writeback. Fixes: f7664b31975b ("xfs: implement online get/set fs label") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=837bcd54843dd6262f2f Cc: [email protected] Signed-off-by: Yun Zhou <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> [ sashal: Omitted realtime-superblock changes because the corresponding support is absent. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Maiolino <[email protected]> Date: Tue Aug 4 11:45:51 2026 +0200 xfs: fix capability check in xfs commit e2f62a9744ebad3bcb6347a648e615026e9efeff upstream. An user reported a bug where he managed to evade group's quota by changing a file's gid to a different group id the same user belonged to, even though quotas were enforced on both gids and the file's size was big enough to exceed the quota's hardlimit. Commit eba0549bc7d1 replaced a capable() call by a has_capability_noaudit() to prevent unnecessary selinux audit messages. Turns out that both calls have slightly different semantics even though their documentation seems similar. Where in a nutshell: capable() - Tests the task's effective credentials has_ns_capability_noaudit() - Tests the task's real credentials This most of the time has no practical difference but in some cases like changing attrs (specifically group id in this case) through a NFS client this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively bypassing quota accounting checks. Using instead ns_capable_noaudit() should fix this issue and prevent selinux audit messages. This also fix the remaining calls to has_capability_noaudit() Fixes: eba0549bc7d1 ("xfs: don't generate selinux audit messages for capability testing") Cc: [email protected] # v5.18 Reported-by: Dr. Thomas Orgis <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Serge Hallyn <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>