Author: Haoxiang Li <[email protected]> Date: Mon Jun 1 01:08:04 2026 +0200 accessibility: speakup: unregister tty ldisc on later init failures commit a76acbaec9b8fd74413646984d2e3626d0543e39 upstream. The ldisc registration is intentionally non-fatal, since some synth drivers do not use tty/ldisc. However, once speakup_init() continues past the registration point and later fails, the init unwind path should mirror speakup_exit() and call spk_ttyio_unregister_ldisc(). Add the missing unregister call to the error path after synth_release(), matching the normal module exit cleanup order. Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Samuel Thibault <[email protected]> Fixes: e23a9b439ce9 ("staging: speakup: safely register and unregister ldisc") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Will Porter <[email protected]> Date: Mon Aug 24 17:57:57 2026 -0500 ALSA: usb-audio: Complete cleanup after system-resume errors commit 1739a976312e110c93a8dee66a1cdf893a1b187e upstream. A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") introduced err_out past the D0 restore. Commit 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection. Assisted-by: Claude:claude-opus-5 Assisted-by: Antigravity:gemini-3.1-pro-high Assisted-by: Codex:gpt-5.6-sol Fixes: 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") Fixes: 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") Cc: <[email protected]> Signed-off-by: Will Porter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marouane El Moufid <[email protected]> Date: Sun Aug 23 13:55:48 2026 +0000 ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() commit 1035a8f63bae28e498b0e7b5ac91d749844a7158 upstream. snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): count = snd_rawmidi_transmit(ep->ports[0].substream, &transfer_buffer[2], ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where "if (count1 > count) count1 = count" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb ("ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Marouane El Moufid <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Trevor Vorhees <[email protected]> Date: Tue Aug 11 20:44:10 2026 -0400 ALSA: usb-audio: Fix sample rates for PreSonus AudioBox USB commit 21e958c4fd92d63139039430c246613505480689 upstream. The fixed audio formats for the PreSonus AudioBox USB specify a discrete rate mask but leave nr_rates at zero and rate_table unset. find_format() therefore rejects every requested rate, preventing the playback and capture streams from being opened. Add the advertised 44100 and 48000 Hz rates to both streams and report their 24 significant bits. Fixes: 34fe4a9df247 ("ALSA: usb-audio: Add quirk for PreSonus AudioBox USB") Cc: [email protected] Signed-off-by: Trevor Vorhees <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Mon Aug 17 08:49:54 2026 +0000 batman-adv: reject unrepresentable multicast TVLV offsets commit f12c2de4f542e3220e17e0606f492110064f04cb upstream. The network and transport header fields in struct sk_buff are 16-bit offsets from skb->head, and U16_MAX is reserved as the unset transport header value. batadv_tvlv_call_handler() sets both fields from a received multicast TVLV without checking whether the TVLV end is representable. If the end offset exceeds the field's range, skb_set_transport_header() truncates it so that the transport header precedes the network header. The negative difference is then returned by skb_network_header_len() as a large u32. batadv_mcast_forw_packet() consequently accepts an oversized multicast tracker and accesses memory beyond the skb data. Add skb_set_transport_header_careful(), an offset-aware counterpart to skb_reset_transport_header_careful(), which validates the final head-relative offset before assigning it. Use the new helper in batadv_tvlv_call_handler() and reject unrepresentable TVLVs before setting the network header. Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding") Cc: [email protected] Signed-off-by: Kyle Zeng <[email protected]> Co-developed-by: David Lee <[email protected]> Signed-off-by: David Lee <[email protected]> Acked-by: Sven Eckelmann <[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: Taegu Ha <[email protected]> Date: Tue Aug 25 23:24:32 2026 +0900 bpf: reject overlarge global subprog argument sizes [ Upstream commit de36adca634634c205a9eb8b56a28175ab7abf5f ] Global subprogram argument checking derives generic pointer sizes from BTF and passes the resolved size to check_mem_reg() as a u32. The access-size validation path then uses a signed int, and stack pointers negate the value before calling check_helper_mem_access(). This creates a wrap when BTF describes a pointee size larger than S32_MAX. For example, a global subprogram argument of type: int (*p)[0x3fffffff] has a BTF-resolved pointee size of 0xfffffffc bytes. At a call site the caller can pass a pointer to a 4-byte stack slot at fp-4. The current PTR_TO_STACK path computes: size = -(int)mem_size so 0xfffffffc becomes -4 as a signed int and the negation validates only a 4-byte stack range. That range is covered by the caller's stack slot, so the call is accepted. The callee is then verified independently with R1 as PTR_TO_MEM and mem_size 0xfffffffc. A small instruction such as: r0 = *(u32 *)(r1 + 4) is accepted as being inside that BTF-described memory region. At run time, however, the actual argument value is still fp-4, so r1 + 4 addresses fp+0, outside the 4-byte object that the caller provided. Reject sizes that cannot be represented by the verifier's signed access-size API before the stack-specific negation. Add a verifier regression test for the oversized BTF argument. [ taegu: Backport to 7.1.y: check_mem_reg() still takes a register number and reg_arg_name() is not available. Emit the equivalent R%d diagnostic using regno. The patched v7.1.10 kernel builds and the targeted verifier_global_subprogs/anon_user_mem_huge_size_invalid selftest passes after booting the kernel on x86_64 under QEMU. ] Fixes: 2cb27158adb3 ("bpf: poison dead stack slots") Signed-off-by: Taegu Ha <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Thu Jun 11 12:36:35 2026 +0200 crypto: atmel-tdes - use scatterlist length before DMA mapping commit ba199bdaa80b09a7dd92f28751de7f3dbb06c510 upstream. Using sg_dma_len() is only valid after mapping the scatterlist with dma_map_sg(). However, atmel_tdes_crypt_start() uses it before mapping to compare input/output lengths and to compute the transfer count. Use the original scatterlist lengths before DMA mapping to avoid reading stale or uninitialized DMA lengths when CONFIG_NEED_SG_DMA_LENGTH=y. Drop the output scatterlist length in the fast path since it is equal to ->in_sg->length and does not change the transfer count. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Wed Aug 5 14:19:23 2026 -0700 crypto: iaa - fall back to software for multi-entry scatterlists commit c7fdfd2bee1cf1448e5244da1a734e680f634b02 upstream. IAA cannot process source or destination scatterlists with more than one entry directly. Instead of failing these requests, route them through a separate deflate acomp transform and keep the request alive in software. The IAA driver has never handled multi-entry scatterlists, but the limitation was latent until commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") made zswap pass the raw zsmalloc SG list directly to crypto drivers, so objects spanning multiple pages now reach IAA as multi-entry sources and would otherwise fail decompression. Fallback to the generic DEFLATE implementation for scatterlists with more than one entry. After the multi-entry cases fall back early, simplify the DMA mapping path to a single scatterlist entry and fall back on mapping failure as well. Add counters to track the number of requests processed by the software implementation on the compression direction. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") Cc: [email protected] Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Sebastian Götte <[email protected]> Date: Mon Aug 3 21:26:21 2026 +0200 crypto: krb5 - use kfree_sensitive() for derived key buffers commit f7d53dd3f267e46a784f219a75072f2f400d42b9 upstream. crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() free the buffer holding the freshly derived keys with plain kfree(), leaving the key material behind in the freed slab object. Fixes: 3936f02bf2d3 ("crypto/krb5: Implement Kerberos crypto core") Cc: [email protected] Signed-off-by: Jan Sebastian Götte <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Sun Jun 21 21:26:16 2026 +0200 crypto: mxs-dcp - fix source scatterlist length access commit c5bcb084a9871e5b62afb5f48b60adfa13b5d9f8 upstream. mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead. Fixes: 15b59e7c3733 ("crypto: mxs - Add Freescale MXS DCP driver") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Md Sadre Alam <[email protected]> Date: Fri Aug 7 12:24:54 2026 +0530 crypto: qce - fix CCM AAD buffer underallocation commit 7f2345f47dd189625f657cd72437179ab4170ee1 upstream. The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes. Cc: [email protected] Fixes: 9363efb4181c ("crypto: qce - Add support for AEAD algorithms") Signed-off-by: Md Sadre Alam <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Mon Jun 22 15:18:09 2026 +0200 crypto: qce - Remove unsafe/deprecated algorithms commit 7e28b0a5c4b7d075b98ce6d8f5290a9d3deb5b92 upstream. Remove algorithms that are either unsafe or deprecated and have no in-kernel users that cannot be served by the ARM CE implementations. AES-ECB reveals plaintext patterns (identical plaintext blocks produce identical ciphertext blocks) and should not be exposed as a hardware- accelerated primitive. DES, Triple DES and HMAC-SHA1 have been deprecated for years. Remove sha1, ecb(aes), ecb(des), cbc(des), ecb(des3_ede), cbc(des3_ede), hmac(sha1) and all AEAD variants built on these primitives as well as authenc(hmac(sha256),cbc(des)). Also clean up the - now dead - code, flags and constants. Cc: [email protected] Acked-by: Eric Biggers <[email protected]> Tested-by: Kuldeep Singh <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Jun 8 17:58:46 2026 +0000 crypto: qcom-rng - Allow zero as a random number commit 4ef04bdc0c9f98836d1638be516f6bf1bad55f69 upstream. Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random. Fixes: f29cd5bb64c2 ("crypto: qcom-rng - Add hw_random interface support") Cc: [email protected] Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Jun 8 17:58:45 2026 +0000 crypto: qcom-rng - Enable clock in hwrng case commit 0fd97bbda2842d7dcccee599ac2c0e9554bdddbc upstream. Fix qcom-rng.c to enable the clock before accessing the hardware. Fixes: f29cd5bb64c2 ("crypto: qcom-rng - Add hw_random interface support") Cc: [email protected] Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Jun 8 17:58:47 2026 +0000 crypto: qcom-rng - Remove crypto_rng interface commit 2ecdf5c9910e20f73639bc322f0518a3439d17c0 upstream. qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the "rng" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters. Fixes: f29cd5bb64c2 ("crypto: qcom-rng - Add hw_random interface support") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Mon Jun 22 01:52:15 2026 -0500 crypto: virtio - bound the akcipher result length commit f77a956f6a19f9463ef1527c9d0cda50dded6b92 upstream. virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected. Fixes: a36bd0ad9fbf ("virtio-crypto: adjust dst_len at ops callback") Cc: [email protected] Signed-off-by: Bryam Vargas <[email protected]> Message-ID: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 20:49:38 2026 -0400 ext4: export converted block count from ext4_convert_unwritten_extents() [ Upstream commit 5b3dcb924a38ecd2c0d828ff30c357357eda1da8 ] ext4_convert_unwritten_extents() currently returns only a success or a failure indication. A zero return means all requested blocks were converted, and a negative value means the conversion failed. However, some blocks may have already been converted when the function fails partway through, and callers have no way to learn how many were done. The WRITE_ZEROES caller in ext4_alloc_file_blocks() needs this information to decide whether to add the inode to the orphan list before updating i_disksize to cover the already-converted written extents, so that a crash before i_disksize catches up can be recovered via orphan truncation. Switch the function to pass out the number of converted blocks through the new output parameter @converted, which will be used by later patches. Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Stable-dep-of: f7237a775c8f ("ext4: protect WRITE_ZEROES written extents with orphan list") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 21:17:53 2026 -0400 ext4: move partial block zeroing earlier in ext4_zero_range() [ Upstream commit b16e9d27a643a3cf8907c994d25ed52717f36418 ] In ext4_zero_range(), move the ext4_zero_partial_blocks() call, which handles unaligned edges, into the same branch where the unaligned range is preallocated, immediately after ext4_alloc_file_blocks(). This is safe because there is no dependency between partial block handling and the subsequent full block handling. This change will be used by later patches that handle unaligned FALLOC_FL_WRITE_ZEROES operations, which will need to check the partial zeroed result. Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Stable-dep-of: d19d239ada9b ("ext4: write back partial-zeroed edges in WRITE_ZEROES") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 20:49:39 2026 -0400 ext4: protect WRITE_ZEROES written extents with orphan list [ Upstream commit f7237a775c8f3e99e0e77b7c10fb626815fb2877 ] In ext4_alloc_file_blocks(), the WRITE_ZEROES path converts unwritten extents to written in one transaction, while i_disksize is updated to cover them only in a later transaction. A crash in between leaves written extents beyond i_disksize on disk, which fsck will complain about. To fix this, add the inode to the orphan list in the same handle that does the conversion, and remove it once i_disksize has caught up. Also add a sanity check to ensure conversion does not extend beyond EOF. Since ext4_alloc_file_blocks() is called from the fallocate() path, partial allocation is safe. On partial conversion failure, advance i_disksize only up to the boundary of successfully converted blocks, so that orphan cleanup sees a consistent state. Document this behavior in the function comment. Reported-by: Jan Kara <[email protected]> Closes: https://lore.kernel.org/linux-ext4/3f6ao5amv7glbgigndtegcucgo3n34ij3lau6l3da3hgdxgn3v@ev66wv3r5umt/ Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: [email protected] Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 21:17:58 2026 -0400 ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks() [ Upstream commit 4c1f6931395ad026415cbdb924ffc240f86eb557 ] Replace the single bool did_zero output of ext4_zero_partial_blocks() with a bitmask that records which edge (start, end, or both in the single-block case) was actually partial-zeroed. This allows callers to distinguish which edges have been zeroed, preparing for unaligned FALLOC_FL_WRITE_ZEROES handling in later patches. Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Stable-dep-of: a5179156ac1d ("ext4: zero out whole block for clean edges in WRITE_ZEROES") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 21:17:54 2026 -0400 ext4: write back partial-zeroed edges in WRITE_ZEROES [ Upstream commit d19d239ada9b7c92d086a1f051b7566538ee0089 ] FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were partial-zeroed in dirty unwritten or delalloc state, the buffer is left dirty while the underlying extent may not yet be converted to written. As a result, a subsequent SYNC write to this range would still trigger metadata changes, which violates the semantics of WRITE_ZEROES. Fix this by calling filemap_write_and_wait_range() for partial-zeroed edges to flush out the zeroed data and ensure the extent conversion is complete. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: [email protected] Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Aug 25 21:17:59 2026 -0400 ext4: zero out whole block for clean edges in WRITE_ZEROES [ Upstream commit a5179156ac1d9a6646da42254e4c461e1fc20096 ] FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were already allocated, ext4_zero_partial_blocks() zeros them directly. However, for unaligned edges whose underlying extent is a clean unwritten extent or a hole, the extent type remains unwritten after partial zeroing, which does not align with the semantics of WRITE_ZEROES. Therefore, when ext4_zero_partial_blocks() skips partial zeroing, it indicates that the corresponding edges are clean unwritten extents or holes. In this case, we need to expand the aligned allocation range outward to cover such edges, so that ext4_alloc_file_blocks() can correctly allocate blocks for the unaligned range. Edges that were partial-zeroed (i.e., written or dirty) are left untouched. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: [email protected] Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Griffin Kroah-Hartman <[email protected]> Date: Mon Jul 6 16:58:21 2026 +0200 fpga: dfl: fme: add error handling commit b5ba63e247075087ab8a6a087622c762dc4172e9 upstream. Add error handling to devm_kasprint in fme_perf_pmu_register(). Assisted-by: gkh_clanker_2000 Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support") Cc: [email protected] Cc: Xu Yilun <[email protected]> Cc: Tom Rix <[email protected]> Cc: Moritz Fischer <[email protected]> Signed-off-by: Griffin Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [ Yilun: Fix stable tag, add Fixes tag ] Reviewed-by: Xu Yilun <[email protected]> Link: https://lore.kernel.org/r/2026070620-unwired-clay-f6cc@gregkh Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baokun Li <[email protected]> Date: Mon Aug 17 23:18:01 2026 +0800 fuse: fix invalidate lock leak on open O_TRUNC DAX failure commit a927f1867e61b78f39f9da0bbba3c98c2ca151fe upstream. fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock. Fixes: 2fdbb8dd0155 ("fuse: fix deadlock between atomic O_TRUNC and page invalidation") Cc: [email protected] # v6.0+ Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baokun Li <[email protected]> Date: Mon Aug 17 23:18:00 2026 +0800 fuse: fix invalidate lock leak on setattr writeback failure commit 9afeca0d569c9fc89d758fe7a9339d1e8afb1546 upstream. fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well. Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault path") Cc: [email protected] # v5.10+ Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qing Ming <[email protected]> Date: Tue Aug 18 23:00:00 2026 +0800 gtp: serialize PDP context updates commit 498386b6d402737db1e2eeed4c385acbf0ef9e34 upstream. PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Cc: [email protected] Signed-off-by: Qing Ming <[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: Kyle Zeng <[email protected]> Date: Mon Aug 17 08:58:38 2026 +0000 ipv6: seg6: clear IPv4 control block on IPIP decapsulation commit 44930446dde45a7a90fe1446fa38eb0e2c561646 upstream. End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress. Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions") Cc: [email protected] Suggested-by: Andrea Mayer <[email protected]> Signed-off-by: Kyle Zeng <[email protected]> Co-developed-by: David Lee <[email protected]> Signed-off-by: David Lee <[email protected]> Reviewed-by: Andrea Mayer <[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: Eric Biggers <[email protected]> Date: Mon Aug 3 11:18:41 2026 -0700 kunit: irq: Continue increasing hrtimer interval for longer commit faa6c4c4e4ac69926564688a926105621295d613 upstream. Currently, kunit_irq_test_timer_func() stops increasing the hrtimer interval as soon as some forward progress is made in each of softirq and task context. Update it to use a more aggressive strategy: increase the interval as long as the hrtimer is running significantly faster than either context. This resolves an occasional hang in the CRC and crypto library tests under qemu-system-s390x. It was exposed by the change in the default preemption model on s390 from NONE to LAZY. That seems to have exposed the issue by allowing some forward progress to be made while the actual system timer tick is still starved, preventing jiffies from increasing or the task context from making much progress towards max_iterations. Fixes: 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently") Cc: [email protected] Reviewed-by: David Gow <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Borntraeger <[email protected]> Date: Tue Aug 11 17:37:36 2026 +0200 KVM: s390: vsie: zero stale crypto bits commit 34d5b5b646c91cfb9338d7a12c955a70ffb8c66b upstream. When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits. Fixes: 6b79de4b056e ("KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2") Cc: [email protected] Signed-off-by: Christian Borntraeger <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Signed-off-by: Claudio Imbrenda <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pankaj Gupta <[email protected]> Date: Wed Jul 15 01:36:26 2026 -0500 KVM: SEV: Drop FOLL_WRITE for encrypted region registration commit ee1a586dd1fa2f245b3b753a3e44d9263a49240b upstream. When pinning SEV guest memory, drop FOLL_WRITE and rely on FOLL_LONGTERM to break CoW, as *KVM* doesn't actually to the memory using the GUP'd pages. Omitting FOLL_WRITE fixes a regression when using file-backed guest memory that was introduced when KVM (correctly) added FOLL_LONG (e.g. to ensure anonymous memory is migrated out of MIGRATE_CMA/ZONE_MOVABLE before a long term pin). Unfortunately, as of commits: 8ac268436e6d ("mm/gup: disallow FOLL_LONGTERM GUP-nonfast writing to file-backed mappings") a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings") GUP uses FOLL_LONGTERM as a canary of sorts to detect pins that are likely to be problematic, and disallows WRITE+LONGTERM pins for file-backed memory. As a result, backing SEV+ guests with file-backed memory, e.g. virtio-pmem, fails due to the disallowed FOLL_LONGTERM+FOLL_WRITE combination. Note, in the past, FOLL_WRITE was required to trigger CoW unsharing, to prevent replacing the page in the (primary MMU's) page tables during a later write fault after already having pinned a (shared) page in MAP_PRIVATE mappings. FOLL_LONGTERM does that nowadays, even without FOLL_WRITE (see gup_must_unshare()). Fixes: 7e066cb9b71a ("KVM: SEV: Use long-term pin when registering encrypted memory regions") Cc: [email protected] Suggested-by: "David Hildenbrand (Arm)" <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Pankaj Gupta <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Acked-by: Lorenzo Stoakes (ARM) <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: massage changelog, add comment about CoW unsharing] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Jul 9 13:49:32 2026 -0700 KVM: SEV: Extract loading of guest-provided VMSA to a separate helper commit 0060569e4f18a7dee2dd8728595e909f19a23c24 upstream. Extract the loading/retrieval of a guest-provided VMSA to a separate helper so that KVM can reuse the core logic when refreshing the VMSA after an MMU invalidation from guest_memfd. No functional change intended. Cc: [email protected] # 6.12.x Reviewed-by: Michael Roth <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Jul 9 13:49:33 2026 -0700 KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable commit 98ade8c48c28c227fe2e80e545ff0c57cd4712a3 upstream. Always mark the vCPU as RUNNABLE after responding to AP_CREATE, even if the guest-specified VMSA is unusable, e.g. isn't backed by a memslot or doesn't have a backing guest_memfd page. If the VMSA is unusable, leaving the vCPU in a non-running state will effectively hang the vCPU instead of reporting an error to userspace. This will also allow retrying the VMSA load in the future, to fix a bug where KVM doesn't honor guest_memfd invalidation events, e.g. if AP_CREATION races with PUNCH_HOLE. Cc: [email protected] # 6.12.x Reviewed-by: Michael Roth <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Jul 9 13:49:31 2026 -0700 KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests commit 42a39ad5d592aec87a70527a4e694f6210694482 upstream. Track the GPA of the guest-provided VMSA used after AP_CREATION events when running SNP guests, instead of simply tracking whether or not the vCPU is using a guest-provided VMSA. KVM needs to know the GPA of the VMSA that's actively being used so that it can react to MMU invalidation events, i.e. so that KVM can drop the VMSA if its backing guest_memfd page is punched out of existence. Opportunistically rename snp_vmsa_gpa to clarify that it tracks the pending VMSA GPA, whereas snp_guest_vmsa_gpa now tracks the in-use VMSA GPA. Note! Take care to track the GPA, not the GFN, as VALID_PAGE() won't behave correctly if an invalid GFN is converted to a GPA for checking. Note #2! Keep snp_has_guest_vmsa so that switching to a guest-provided VMSA is sticky, even if the guest-provided VMSA becomes invalid. No functional change intended. Cc: [email protected] # 6.12.x Reviewed-by: Michael Roth <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Jul 9 13:49:34 2026 -0700 KVM: SEV: Wire up kvm_x86_ops.gmem_xxx() if and only if CONFIG_KVM_AMD_SEV=y commit 01a96ff30dde5127c37497f1e098e639e7ae152f upstream. Wire up the SEV-SNP guest_memfd kvm_x86_ops hooks if and only if SEV is actually enabled, and drop the now-unnecessary stubs. Leaving the hooks NULL allows the static call infrastructure to elide the CALL+RET, and more importantly, referencing the hooks if and only if SEV support is enabled will allow conditionally definining the hooks using their corresponding HAVE_KVM_ARCH_GMEM_XXX Kconfig. No functional change intended. Cc: [email protected] # 6.12.x Reviewed-by: Ackerley Tng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinu Kim <[email protected]> Date: Tue Jul 21 19:35:11 2026 +0900 KVM: x86/mmu: Check write tracking in all address spaces [ Upstream commit 0f38453cdb2e17566ccb7c0f3dabd5bd21caca26 ] kvm_gfn_is_write_tracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other. Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and eventually triggering the BUG in pte_list_remove(). Fixes: 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Assisted-by: Codex:GPT-5 Signed-off-by: Jinu Kim <[email protected]> Message-ID: <[email protected]> [invert direction of the conditional. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Sep 2 14:32:39 2026 +0200 Linux 7.1.13 Link: https://lore.kernel.org/r/[email protected] Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Barry K. Nathan <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Aug 3 11:04:26 2026 -0700 mm/swap: reject swapon() on filesystem-level encrypted files commit c310a8932a3107c9bc8f01d473e9d085f8aa9c98 upstream. ext4 and f2fs don't prevent filesystem-level encrypted files from being set up directly as swap files. In this case, encryption is bypassed. No one should be doing this, vs. the methods of encrypted swap that actually do work (such as swapping to a dm-crypt device, or swapping to a loopback device on top of a filesystem-level encrypted file). Nevertheless, to prevent user error, make swapon() explicitly reject this case. Document this behavior in fscrypt.rst as well. Link: https://lore.kernel.org/[email protected] Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support") Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support") Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Baoquan He <[email protected]> Reviewed-by: Muhammad Usama Anjum <[email protected]> Reviewed-by: "Darrick J. Wong" <[email protected]> Cc: Barry Song <[email protected]> Cc: Chris Li <[email protected]> Cc: Kairui Song <[email protected]> Cc: Kemeng Shi <[email protected]> Cc: Nhat Pham <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Sun Aug 16 16:56:46 2026 -0700 net/packet: defer vmalloc TX_RING free until skbs finish commit 992cc9f94ca924089a506ba9b327caa9af797529 upstream. AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path. Fixes: b013840810c2 ("packet: use percpu mmap tx frame pending refcount") Cc: [email protected] Link: https://lore.kernel.org/netdev/[email protected]/ Suggested-by: Eric Dumazet <[email protected]> Suggested-by: Willem de Bruijn <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: Kyle Zeng <[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: Hyunwoo Kim <[email protected]> Date: Mon Aug 17 06:28:42 2026 +0900 net/tcp-ao: fix use-after-free of current_key on reconnect to another peer commit da4471557f279d0f56605158a625bb6e49ef7d41 upstream. tcp_inbound_ao_hash() is called before bh_lock_sock_nested() is taken, with only rcu_read_lock() held. On the fast path for established sockets, if the rnext_keyid sent by the peer differs from current_key->sndid, the key the peer asked for is looked up and stored in current_key. The lookup is inside the RCU read side, but current_key outlives it. When the socket is disconnected and connect() is called again for another peer, tcp_ao_connect_init() unlinks every key that does not match the new peer and frees it with call_rcu(). If current_key points at such a key, it is cleared to NULL. The fast path reads sk_state only once on entry, so a softirq that got into it while the socket was still established can update current_key after that loop has already run. The update is inside the RCU read side, so it comes before the call_rcu() callback, and once the callback frees the key, current_key is left pointing at freed memory. The next transmission picks that pointer up in tcp_get_current_key(). tcp_ao_transmit_skb() then reads the traffic key from the freed object, which is the use-after-free. Wait for one grace period before unlinking, and only if a key is going to be removed. By the time tcp_connect() runs the socket is already in TCP_SYN_SENT, and TCP_AO_ESTABLISHED does not contain TCPF_SYN_SENT, so a softirq entering after the wait cannot reach the fast path, and the ones already in it have finished. The existing NULL handling in the loop is then enough. Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments") Cc: [email protected] Signed-off-by: Hyunwoo Kim <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Paolo Abeni <[email protected]> Link: https://patch.msgid.link/aoIriv3pHDgII2YR@v4bel Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rastislav Szabo <[email protected]> Date: Sat Aug 22 22:11:18 2026 +0200 net/tcp: fix TCP-AO key deletion in VRFs commit 94ad9e114a1c7b16ea418c1456ac3835e038ab3f upstream. TCP-AO keys with TCP_AO_KEYF_IFINDEX store the VRF L3 interface index in l3index. tcp_ao_del_cmd() validates the supplied ifindex, but does not assign it to its local l3index before matching keys. As a result, deleting a key scoped to a non-default VRF always fails with ENOENT because it is matched against l3index 0. Fixes: 248411b8cb89 ("net/tcp: Wire up l3index to TCP-AO") Cc: [email protected] Signed-off-by: Rastislav Szabo <[email protected]> Reviewed-by: David Ahern <[email protected]> Acked-by: Dmitry Safonov <[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: Jiayuan Chen <[email protected]> Date: Sat Aug 15 15:03:36 2026 +0800 net: advertise TCP MSS from the configured MTU, not the learned PMTU commit 2640e64195948a601430d230c9864f5426574cde upstream. The MSS a host puts in its SYN tells the peer how big a segment it may send us. Right now we can shrink it with a PMTU we learned on our own send path, which is the wrong direction entirely. On asymmetric paths this bites - think DSR load balancers, where the request side goes through a smaller-MTU overlay. We learn a small PMTU going out, then advertise a small MSS, and the peer stays capped for the whole connection even though its path back to us is wide. MSS only shows up in the SYN and never grows back. On symmetric paths we lose nothing by dropping it either: the peer runs its own PMTU discovery and usually already knows the real path MTU. So work out the advertised MSS from the configured route or device MTU and ignore the learned PMTU. Our send side is unchanged, still clamped by tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured() and use them from the two default_advmss() paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu") Cc: [email protected] Signed-off-by: Jiayuan Chen <[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: Norbert Szetei <[email protected]> Date: Wed Aug 26 11:12:27 2026 +0200 net: bridge: mcast: fix use-after-free of a master VLAN's multicast context commit 50e5c6605cc9c2dd57bd2d1b3459674d19738983 upstream. br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context. Fixes: 7b54aaaf53cb ("net: bridge: multicast: add vlan state initialization and control") Cc: [email protected] Signed-off-by: Norbert Szetei <[email protected]> Acked-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: Fourie Zhang <[email protected]> Date: Mon Aug 10 19:35:01 2026 +0800 netfilter: nf_tables: don't queue packet path object notifications commit 7904b94768e983bcb2be34a8d6d1f3450f5b838b upstream. All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply. nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting packet, holding no mutex. Since commit 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple notifications into one skbuff") that notification is no longer sent immediately. __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with commit_mutex held. Sending packets through a chain that references a depleted quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been freed: BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: <IRQ> __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by task 77: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain Freed by task 79: nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg The buggy address belongs to the cache skbuff_head_cache of size 232 Queueing from the packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does. The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are still coalesced. Fixes: 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple notifications into one skbuff") Cc: [email protected] Reported-by: TencentOS Corvus AI <[email protected]> Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Fourie Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sat Aug 15 13:57:50 2026 -0700 netfilter: nft_set_pipapo_avx2: add missing vzeroupper commit 55dd20f0f4b1be5c9c8a0275d8d763c86563eac2 upstream. Since pipapo_get_avx2() uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Bogdanov <[email protected]> Date: Thu Aug 27 15:20:24 2026 -0700 nvme-tcp: fix usage of page_frag_cache commit 36ac05f7cfd59d90c597071304b14e98090d5dd1 upstream. nvme uses page_frag_cache to preallocate PDU for each preallocated request of block device. Block devices are created in parallel threads, consequently page_frag_cache is used in not thread-safe manner. That leads to incorrect refcounting of backstore pages and premature free. That can be catched by !sendpage_ok inside network stack: WARNING: CPU: 7 PID: 467 at ../net/core/skbuff.c:6931 skb_splice_from_iter+0xfa/0x310. tcp_sendmsg_locked+0x782/0xce0 tcp_sendmsg+0x27/0x40 sock_sendmsg+0x8b/0xa0 nvme_tcp_try_send_cmd_pdu+0x149/0x2a0 Then random panic may occur. Fix that by serializing the usage of page_frag_cache. Fixes: 4e893ca81170 ("nvme_core: scan namespaces asynchronously") Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Signed-off-by: Keith Busch <[email protected]> [carlos.bilbao: adjust context in nvme_tcp_free_queue; branch predates 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance")] Signed-off-by: Carlos Bilbao (Lambda) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peiyang He <[email protected]> Date: Thu Jul 30 10:28:27 2026 +0800 RDMA/rxe: Fix OOB in free_rd_atomic_resources() [ Upstream commit de329533792a373186d79dca1ca120f8fa0afd05 ] free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) 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 lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 </TASK> Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88802b8ddd80 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 56-byte region [ffff88802b8ddd80, ffff88802b8dddb8) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2b8dd flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 00fff00000000000 ffff888015c418c0 dead000000000100 dead000000000122 raw: 0000000000000000 0000000800200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4651, tgid 4651 ((udev-worker)), ts 123427165316, free_ts 123425874255 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0xfc/0x120 mm/page_alloc.c:1853 prep_new_page mm/page_alloc.c:1861 [inline] get_page_from_freelist+0x75b/0x3220 mm/page_alloc.c:3941 __alloc_frozen_pages_noprof+0x27e/0x2b00 mm/page_alloc.c:5221 alloc_slab_page mm/slub.c:3278 [inline] allocate_slab mm/slub.c:3467 [inline] new_slab+0xa6/0x670 mm/slub.c:3525 refill_objects+0x278/0x420 mm/slub.c:7272 refill_sheaf mm/slub.c:2816 [inline] __pcs_replace_empty_main+0x2ed/0x640 mm/slub.c:4652 alloc_from_pcs mm/slub.c:4750 [inline] slab_alloc_node mm/slub.c:4884 [inline] __do_kmalloc_node mm/slub.c:5295 [inline] __kmalloc_noprof+0x68d/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] tomoyo_encode2+0x100/0x3e0 security/tomoyo/realpath.c:45 tomoyo_encode+0x29/0x50 security/tomoyo/realpath.c:80 tomoyo_realpath_from_path+0x18c/0x690 security/tomoyo/realpath.c:283 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_check_open_permission+0x2ab/0x3c0 security/tomoyo/file.c:776 tomoyo_file_open+0x6b/0x90 security/tomoyo/tomoyo.c:334 security_file_open+0x7a/0x1b0 security/security.c:2739 do_dentry_open+0x57e/0x1690 fs/open.c:924 vfs_open+0x82/0x3f0 fs/open.c:1079 do_open fs/namei.c:4699 [inline] path_openat+0x218a/0x3190 fs/namei.c:4858 page last free pid 1 tgid 1 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] __free_pages_prepare mm/page_alloc.c:1397 [inline] __free_frozen_pages+0x763/0xfc0 mm/page_alloc.c:2938 selinux_genfs_get_sid security/selinux/hooks.c:1364 [inline] inode_doinit_with_dentry+0x903/0x1320 security/selinux/hooks.c:1563 selinux_d_instantiate+0x26/0x30 security/selinux/hooks.c:6658 security_d_instantiate+0x123/0x190 security/security.c:3704 d_splice_alias_ops+0x92/0x850 fs/dcache.c:3141 kernfs_iop_lookup+0x23f/0x2d0 fs/kernfs/dir.c:1289 lookup_open.isra.0+0x659/0x1080 fs/namei.c:4484 open_last_lookups fs/namei.c:4611 [inline] path_openat+0x17dd/0x3190 fs/namei.c:4855 do_file_open+0x20c/0x430 fs/namei.c:4887 do_sys_openat2+0x101/0x1d0 fs/open.c:1364 do_sys_open fs/open.c:1370 [inline] __do_sys_openat fs/open.c:1386 [inline] __se_sys_openat fs/open.c:1381 [inline] __x64_sys_openat+0x141/0x200 fs/open.c:1381 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff88802b8ddc80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ffff88802b8ddd00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff88802b8ddd80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ^ ffff88802b8dde00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ffff88802b8dde80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc Fix the OOB by moving the assignment after free_rd_atomic_resources() so the old array is freed using the old bound. This matches the original ordering in commit 8700e3e7c485 ("Soft RoCE driver"). Closes: https://lore.kernel.org/all/365C68B4923F8214+30195a67-0b90-4b92-ab96-2ce41517793c@smail.nju.edu.cn/ Fixes: b6bbee0d2438 ("IB/rxe: Properly honor max IRD value for rd/atomic.") Cc: [email protected] Signed-off-by: Peiyang He <[email protected]> Reviewed-by: Zhu Yanjun <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ibrahim Hashimov <[email protected]> Date: Sun Jul 12 14:17:20 2026 +0200 RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp [ Upstream commit 6f7014237405e7f032b5c53a82d9eccf6161c291 ] rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS). Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths. Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone. Fixes: 8700e3e7c485 ("Soft RoCE driver") Reviewed-by: Zhu Yanjun <[email protected]> Signed-off-by: Ibrahim Hashimov <[email protected]> Link: https://patch.msgid.link/[email protected] Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Guan <[email protected]> Date: Fri Aug 28 01:51:41 2026 +0800 Revert "selinux: reject a permission value exceeding the class permission count" This reverts commit d81bda85d95f3a2b9eb906c7a818d88645413bb4. The stable pick applied the nprim bound after symtab_insert() because the upstream context (the SEL_VEC_MAX check from commit 18fa21f10d00 "selinux: more strict policy parsing") does not exist in this tree. On that error path perm_destroy() frees a key/datum pair that is already linked into the symtab, leading to a double free when the failed policydb is torn down. Drop it here; it is re-applied later in this series in its upstream form, after its strict-parsing prerequisite. Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Göttsche <[email protected]> Date: Fri Aug 28 01:51:45 2026 +0800 selinux: more strict policy parsing [ Upstream commit 18fa21f10d008a0fc22565109c7d38f304295912 ] Be more strict during parsing of policies and reject invalid values. Add some error messages in the case of policy parse failures, to enhance debugging, either on a malformed policy or a too strict check. Signed-off-by: Christian Göttsche <[email protected]> Acked-by: Stephen Smalley <[email protected]> [PM: fixed checkpatch.pl warnings, style problems] Signed-off-by: Paul Moore <[email protected]> (cherry picked from commit 18fa21f10d008a0fc22565109c7d38f304295912) Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Aug 28 01:51:47 2026 +0800 selinux: reject a permission value exceeding the class permission count [ Upstream commit d14b5d0e97fccd27974fedc03b903408872907fd ] perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. Cc: [email protected] Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> [PM: tweak comment for line length] Signed-off-by: Paul Moore <[email protected]> (cherry picked from commit d14b5d0e97fccd27974fedc03b903408872907fd) Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Aug 28 01:51:49 2026 +0800 selinux: require a class's permission values to cover its permission count [ Upstream commit b98a8ac50775540f3804397ed08f61ef9910bcab ] security_get_permissions() sizes an array by the class's permissions.nprim and fills it at value - 1, from the inherited common's permission table and then the class's own. A value no permission defines leaves a NULL that sel_make_perm_files() passes to d_alloc_name(), an oops inside sel_write_load() that strands selinux_state.policy_mutex and leaves every later load in uninterruptible sleep; two permissions sharing a value overwrite the first kstrdup(). Bounding each value by nprim catches neither, and neither would a count: the symbol table is keyed on the permission name, so duplicates pass. Track the values each permission table claims and require them to cover exactly what its count declares, rejecting a count no value can reach. Conforming policies are unaffected. Cc: [email protected] Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> (cherry picked from commit b98a8ac50775540f3804397ed08f61ef9910bcab) Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephen Smalley <[email protected]> Date: Wed Apr 29 15:18:40 2026 -0400 selinux: switch two allocations to use kzalloc_objs() [ Upstream commit cf6a513f1937581eb012a217b29817e025a1a0ef ] These were the only two allocations in the policy loading logic that were not already using kzalloc_objs() for the policy data structures. Fix these to be consistent with the rest and to protect against ill-formed policy. Signed-off-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Göttsche <[email protected]> Date: Fri Aug 28 01:51:43 2026 +0800 selinux: use u16 for security classes [ Upstream commit fa79a596848fe38c55ccab8832ac35dac07fb00c ] Security class identifiers are limited to 2^16, thus use the appropriate type u16 consistently. Signed-off-by: Christian Göttsche <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> (cherry picked from commit fa79a596848fe38c55ccab8832ac35dac07fb00c) Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yong Wang <[email protected]> Date: Wed Aug 19 23:22:04 2026 +0800 tcp: clamp route advmss to TCP_MIN_MSS commit 870a9e42ecc6fe1b8c25d87af043cb0d9c178fe1 upstream. tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reported-by: Vega <[email protected]> Signed-off-by: Yong Wang <[email protected]> Signed-off-by: Ren Wei <[email protected]> Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qing Ming <[email protected]> Date: Tue Aug 25 15:20:33 2026 +0800 tcp: fix AO info use-after-free in tcp_ao_connect_init() commit ea30dc5267e367b8a5e1e06cc074f813bcbf18b2 upstream. tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling tcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that a key matches the peer and the bound device's current L3 master. tcp_ao_connect_init() later resolves the L3 master again and removes keys which do not match it. The socket lock does not stabilize the bound device's VRF membership. Detaching the device from its VRF between the initial validation and the L3-master calculation in tcp_ao_connect_init() can therefore make the validation succeed while initialization observes the default L3 domain and removes the only key. The subsequent AO lookup then fails, so the no-key path clears tp->ao_info and frees it directly. The receive path can find the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. A reader which loaded the old pointer can thus continue into tcp_inbound_ao_hash() after the direct free. The issue was found during a static audit of TCP-AO object lifetime. An unprivileged reproducer in self-created user and network namespaces raced connect() with detaching a veth from its VRF while sending TCP-AO segments. It triggered the same KASAN report on two fresh boots: BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232 Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0 Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640 Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720 The bad address is 40 bytes inside the freed 128-byte object, matching the tcp_ao_info counters.key_not_found field. The two runs used 1000 attempts each, reached the no-key path 366 and 411 times, and produced one and two KASAN reports respectively. With this change, the same reproducer reached the no-key path 366 times in 1000 attempts without a KASAN report or oops. Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info, updates the socket memory and static-key accounting, and defers the free until after an RCU grace period. Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race makes the no-key state reachable during normal operation, so it is a handled condition rather than an impossible assertion. On panic_on_warn kernels the WARN would turn this handled race into a kernel panic. Fixes: 248411b8cb89 ("net/tcp: Wire up l3index to TCP-AO") Cc: [email protected] Assisted-by: Codex:gpt-5 Signed-off-by: Qing Ming <[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: Greg Kroah-Hartman <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Sun Aug 23 16:47:56 2026 +0800 tls: device: fix out-of-bounds write in tls_append_frag() commit b17cf742eaad70ae29ac558cefb3aa9bbeea03d4 upstream. Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK> and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: <TASK> worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK> Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Cc: [email protected] Signed-off-by: Jiayuan Chen <[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: Shuangpeng Bai <[email protected]> Date: Wed Aug 5 21:35:02 2026 -0400 USB: c67x00: fix use-after-free in c67x00_add_iso_urb() commit b1e24de475bf2d66fffc9103f3444b783527d55a upstream. When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data. Fixes: e9b29ffc519b ("USB: add Cypress c67x00 OTG controller HCD driver") Cc: [email protected] Signed-off-by: Shuangpeng Bai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Griffin Kroah-Hartman <[email protected]> Date: Mon Jul 13 17:43:53 2026 +0200 usb: core: Add lock to usb_wakeup_notification() commit e263e18a9e7b1ff3e7301f0801c6ff87c31adfb6 upstream. Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device. Assisted-by: gkh_clanker_t1000 Signed-off-by: Griffin Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Griffin Kroah-Hartman <[email protected]> Date: Wed Jul 22 10:17:39 2026 +0200 usb: core: Strengthen error handling in hub_hub_status() commit a29496745aa335d97f617385809583241e118610 upstream. Add additional error handling after the call to get_hub_status() in hub_hub_status(). get_hub_status() uses usb_control_msg() which does not verify that the message is the correct length, substituting it for usb_control_msg_recv() would also solve this issue but increase memory allocations. Instead, error handling is copied from the method used in hub_ext_port_status(), which shares the same flow of logic as hub_hub_status(). Assisted-by: gkh_clanker_t1000 Signed-off-by: Griffin Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuangpeng Bai <[email protected]> Date: Fri Aug 7 02:07:33 2026 -0400 usb: gadget: f_tcm: keep port count until LUN teardown completes commit c39d0916da47d94909391876c9e5bd429ea7b1b9 upstream. tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS "free active" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion. Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: [email protected] Signed-off-by: Shuangpeng Bai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiale Yao <[email protected]> Date: Sun Jul 26 00:27:51 2026 +0800 USB: serial: option: fix slab OOB read in interrupt URB callback commit 885d802f544ca7bfa8f3984d94233cce715bb6b3 upstream. The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. Assisted-by: Claude:deepseek-v4-pro Signed-off-by: Jiale Yao <[email protected]> Fixes: 58cfe9113e48 ("[PATCH] USB: add Option Card driver") Cc: [email protected] # v2.6.12 [ johan: use dev_err(); split signals declaration and initialisation ] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Aug 6 15:52:48 2026 +0200 USB: serial: spcp8x5: drop broken carrier detect support commit d37186bd95a07e334447f47274a38a311dad2172 upstream. The driver does not support modem status notifications and instead used to fetch the modem status once at open() and subsequently operate on and report stale state. As part of fixing this, a call to fetch the status was added to carrier_raised(), which does not work as that callback must not sleep (e.g. unlike tiocmget()). Drop the broken carrier detect support. Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") Cc: [email protected] # 3.10 Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miguel Peñaranda <[email protected]> Date: Mon Aug 10 14:12:09 2026 +0200 usb: usbfs: fix use-after-free of usb_device in usbdev_release() commit 0dd68b5d01d022fc9c5e71c82a82b0a94d3d0671 upstream. usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped. Fixes: f7d34b445abc ("USB: Add support for usbfs zerocopy.") Cc: [email protected] Assisted-by: Claude:claude-opus-5 Signed-off-by: Miguel Peñaranda <[email protected]> Reviewed-by: Alan Stern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksandr Nogikh <[email protected]> Date: Thu Aug 6 15:26:51 2026 +0000 usb: usbtest: disable dynamic ID support commit 00e2071f6d5621a5ddea311a5e6b143ae6e474af upstream. The usbtest driver relies on the driver_info field of struct usb_device_id to point to a valid struct usbtest_info descriptor. This structure contains essential test configurations, such as endpoint addresses and test modes, which are required during probe. When a user dynamically adds a new device ID via the sysfs new_id interface without specifying a reference device, the USB core initializes driver_info to 0 (NULL). When a matching device is subsequently probed, usbtest_probe() unconditionally casts driver_info to a struct usbtest_info pointer and dereferences it, leading to a NULL pointer dereference crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:usbtest_probe+0x3b9/0x1280 drivers/usb/misc/usbtest.c:2822 Because usbtest strictly requires pre-defined usbtest_info descriptors to function, dynamic ID binding via sysfs is fundamentally unsupported for this driver. Fix this by setting .no_dynamic_id = 1 on usbtest_driver. This instructs the USB core to skip creating the new_id and remove_id sysfs interfaces for usbtest, preventing invalid dynamic ID entries from being created. Cc: [email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=7e1e5911f9eac50bedc7 Signed-off-by: Aleksandr Nogikh <[email protected]> Tested-by: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Aug 6 17:21:06 2026 +0300 usb: xhci: bail out of setup if the controller is inaccessible commit 78203d5b54a40f0e36196ebf31c9c7a380fc8811 upstream. xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.") Cc: [email protected] Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michal Pecio <[email protected]> Date: Thu Aug 6 17:21:13 2026 +0300 usb: xhci: Handle bogus TRB pointers in Missed Service Error events commit 3d9eeb336131bc5a174367c384fa00c15c8744fd upstream. xHCI 1.0 allowed these pointers to be zero. Some Intel chipsets from the era usually set it to zero, but sometimes (apparently) to the next TRB after the one referenced by the previous transfer event on the endpoint. Usually that's indeed the missed TD, but it may also be the last TRB of a two-TRB TD already completed with Short Packet on its first TRB. Then the driver skips all pending TDs, failing to find a match. When handling Missed Service Error, scan TD list twice and only really skip TDs in the second pass if the first pass found a match. This won't catch bogus pointers to wrong TDs, but such a bug would be practically impossible to detect automatically and isn't known to exist. Reported-by: Bart Nagel <[email protected]> Closes: https://lore.kernel.org/linux-usb/al_hchyOdPoPWKEo@spiral/ Suggested-by: Mathias Nyman <[email protected]> Fixes: d0b619599e52 ("usb: xhci: Expedite skipping missed isoch TDs on modern HCs") Cc: [email protected] Signed-off-by: Michal Pecio <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Semih Baskan <[email protected]> Date: Thu Aug 6 17:21:12 2026 +0300 usb: xhci: Handle USB3 port events when there is one roothub commit 3e91ec3e7d80a327fb558207613c80415d3bf756 upstream. handle_port_status() drops every USB3 port event when xhci->shared_hcd is NULL. The check dates from a time when xhci-plat always created a shared hcd, so a NULL one could only mean the hcd had been removed. Since commit 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") that is no longer true. A controller whose USB2 root hub has no ports gets a single roothub, the USB3 rhub is served by the main hcd, and shared_hcd stays NULL for the lifetime of the device. Every SuperSpeed port event is then thrown away as bogus behind a debug message, so devices never enumerate even though the port sees the device and its change bits stay set: 0x006a1203 Powered Connected Enabled Link:U0 PortSpeed:4 Change: CSC WRC PRC PLC Broadcom Northstar is such a controller. USB3 works there up to 5.15 and stops working from 5.19 onwards. Ask xhci_get_usb3_hcd() instead. It returns the shared hcd when there is one, the main hcd when the USB2 root hub has no ports, and NULL once the shared hcd is gone, which keeps the original meaning of the check. Tested on an Asus RT-N18U (BCM47081), which has a single roothub. Before the change nothing enumerates on the USB3 port; after it SuperSpeed devices enumerate normally over repeated connect and disconnect cycles, the change bits shown above clear, and USB2 is unaffected on both ports. Fixes: 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") Cc: [email protected] Signed-off-by: Semih Baskan <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Mon Aug 10 14:41:14 2026 +0000 vxlan: keep the last remote linked during FDB flush commit d5d4a7b538b52db63927773a8905fcd9f78a42e2 upstream. A non-nexthop FDB entry is expected to have at least one remote while it remains reachable through the FDB hash table. A filtered bulk flush violates this invariant when every remote matches: It unlinks the last remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush() to destroy the parent FDB entry. An RCU reader can find the parent during this interval. first_remote_rcu() then applies list_entry_rcu() to the empty list head, producing an invalid remote pointer that the receive learning path can read from and write to. When a matching remote is the sole remaining remote, leave it linked and ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures. Fixes: c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI") Cc: [email protected] Signed-off-by: Kyle Zeng <[email protected]> Co-developed-by: David Lee <[email protected]> Signed-off-by: David Lee <[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: Devin Wittmayer <[email protected]> Date: Tue Jul 14 19:33:48 2026 -0700 wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb commit ef3e34874d2332d0f63e72c2c35ce5c93568c125 upstream. mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extra_tx_headroom, but forwarded frames are sent through ieee80211_8023_xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel: skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path. The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers"), but mt7925 was copied from mt7921 without the fix. Add the same guard here. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Cc: [email protected] Link: https://github.com/morrownr/mt76/issues/52 Signed-off-by: Devin Wittmayer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Asim Viladi Oglu Manizada <[email protected]> Date: Thu Jul 23 09:35:48 2026 +0000 xfrm: ah6: validate routing header segments_left commit 7bad4bda74dc4713f398d3b7624ff05478e3a568 upstream. AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix Signed-off-by: Asim Viladi Oglu Manizada <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zihan Xi <[email protected]> Date: Tue Jul 21 23:25:42 2026 +0800 xfrm: avoid lock inversion in nat keepalive work commit 763fe700b7c58ad64fe5202c5638848244dd4127 upstream. nat_keepalive_work() walks the state table while xfrm_state_walk() holds net->xfrm.xfrm_state_lock. Its callback then acquires x->lock, which conflicts with the delete path taking the same locks in reverse order via xfrm_state_delete() and __xfrm_state_delete(). This creates an AB-BA deadlock that is reported by lockdep when a NAT keepalive worker races with SA deletion. Fix this by splitting the keepalive walk into two phases. First, collect the candidate states while the walk holds xfrm_state_lock and take a reference on each state. Then, after the walk completes, process each collected state and acquire x->lock without nesting it under xfrm_state_lock. Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states") Cc: [email protected] Reported-by: Vega <[email protected]> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi <[email protected]> Signed-off-by: Ren Wei <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zihan Xi <[email protected]> Date: Mon Aug 17 19:09:56 2026 +0000 xfrm: bound nat keepalive state collection commit 4e9442ce551ebd84b52ad649df721e2dc28af95a upstream. The v1 nat keepalive fix allocates a GFP_ATOMIC object for every state while collecting references for phase two. This makes the worker's temporary memory use depend on the number of states and lets -ENOMEM abort the scan. Replace the allocated list with a fixed-size batch. When the batch is full, return a private walk status so xfrm_state_walk() leaves a cursor; drain the references after the walk releases xfrm_state_lock and resume from the cursor. This bounds temporary memory use and avoids the allocation failure path. The v1 fix also moved nat_keepalive_send() out of the walk callback. Keep the phase-two drain BH-disabled, as required by local_lock_nested_bh() used by the keepalive sockets. Fixes: 763fe700b7c5 ("xfrm: avoid lock inversion in nat keepalive work") Cc: [email protected] Cc: Eyal Birger <[email protected]> Reported-by: Vega <[email protected]> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhiling Zou <[email protected]> Date: Sat Jul 18 15:12:50 2026 +0800 xfrm: drop ESP-in-TCP packets with no ingress device commit e1d7c5ac1c246ce5775f604515de0a59fbf2116e upstream. ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: [email protected] Reported-by: Vega <[email protected]> Signed-off-by: Zhiling Zou <[email protected]> Assisted-by: Codex:gpt-5.4 Reviewed-by: Ren Wei <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sabrina Dubroca <[email protected]> Date: Thu Jul 16 22:54:59 2026 +0200 xfrm: espintcp: fix UAF during close commit deb232e884877bf10b4ce2580909eedec986c284 upstream. ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed. Cc: [email protected] Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Reported-by: [email protected] Signed-off-by: Sabrina Dubroca <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zihan Xi <[email protected]> Date: Tue Jul 28 01:30:32 2026 +0800 xfrm: fix xfrm_state_construct() auth-trunc leak commit c12cbf56320fb633484ee0ca1fb7d68d6b64b213 upstream. attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as "no auth algorithm attached yet" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo. Fixes: 4447bb33f094 ("xfrm: Store aalg in xfrm_state with a user specified truncation length") Cc: [email protected] Reported-by: Vega <[email protected]> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi <[email protected]> Signed-off-by: Ren Wei <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lucas De Marchi <[email protected]> Date: Thu Aug 6 17:21:04 2026 +0300 xhci: dbgtty: Fix unregister on tty_alloc_driver() failure commit 25b8dfc13495a6c1cf4abacc8ef20196c7f20e5c upstream. Make sure to set dbc_tty_driver to NULL to match the check in dbc_tty_exit(). For that, make detached error handling path common to the other branch in the same function. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: [email protected] # v5.10 Cc: Mathias Nyman <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lucas De Marchi <[email protected]> Date: Thu Aug 6 17:21:03 2026 +0300 xhci: dbgtty: Fix unregister on tty_register_driver() failure commit a916fa66a43e10f63198b6ce978badffc678821a upstream. If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: [email protected] # v5.10 Cc: Mathias Nyman <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>