summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-24KVM: arm64: Fix FEAT_Debugv8p9 to check DebugVer, not PMUVerFuad Tabba
FEAT_Debugv8p9 is incorrectly defined against ID_AA64DFR0_EL1.PMUVer instead of ID_AA64DFR0_EL1.DebugVer. All three consumers of the macro gate features that are architecturally tied to FEAT_Debugv8p9 (DebugVer = 0b1011, DDI0487 M.b A2.2.10): - HDFGRTR2_EL2.nMDSELR_EL1, HDFGWTR2_EL2.nMDSELR_EL1: MDSELR_EL1 is present only when FEAT_Debugv8p9 is implemented (D24.3.21). - MDCR_EL2.EBWE: the Extended Breakpoint and Watchpoint Enable bit is RES0 unless FEAT_Debugv8p9 is implemented (D24.3.17). Neither register has any dependency on PMUVer. FEAT_Debugv8p9 and FEAT_PMUv3p9 are independent. Per DDI0487 M.b A2.2.10, FEAT_Debugv8p9 is unconditionally mandatory from Armv8.9, whereas FEAT_PMUv3p9 is mandatory only when FEAT_PMUv3 is implemented. An Armv8.9 CPU without a PMU has DebugVer = 0b1011 but PMUVer = 0b0000, so the wrong field check would cause KVM to incorrectly treat EBWE and MDSELR_EL1 as RES0 on such hardware. Fixes: 4bc0fe089840 ("KVM: arm64: Add sanitisation for FEAT_FGT2 registers") Signed-off-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260424084908.370776-2-tabba@google.com Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-04-24KVM: arm64: Reject non compliant SMCCC function calls in pKVMSebastian Ene
Prevent the propagation of a function-id that has the top bits set since this is not compliant with the SMCCC spec and can overlap with the already known function-id decoders. (eg. if we invoke an smc with 0xffffffffc4000012 it will be decoded as a PSCI reset call). Instead, make it clear that we don't support it and return an error. Signed-off-by: Sebastian Ene <sebastianene@google.com> Link: https://patch.msgid.link/20260408114118.422604-1-sebastianene@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-24KVM: arm64: vgic: Fix IIDR revision field extracted from wrong valueDavid Woodhouse
The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3 extract the revision field from 'reg' (the current IIDR value read back from the emulated distributor) instead of 'val' (the value userspace is trying to write). This means userspace can never actually change the implementation revision — the extracted value is always the current one. Fix the FIELD_GET to use 'val' so that userspace can select a different revision for migration compatibility. Fixes: 49a1a2c70a7f ("KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Link: https://patch.msgid.link/20260407210949.2076251-2-dwmw2@infradead.org Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-04-24drm/i915/dmc: use display instead of dereferencing dmc in ↵Desnes Nunes
intel_dmc_update_dc6_allowed_count() There is no need for dereferencing the dmc pointer if the display is already in the scope of intel_dmc_update_dc6_allowed_count function. No functional change. Signed-off-by: Desnes Nunes <desnesn@redhat.com> Link: https://patch.msgid.link/20260423201020.506908-1-desnesn@redhat.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-24drm/i915/ddi: add wrapper for calling ->get_buf_trans() hookJani Nikula
Add intel_ddi_buf_trans_get() wrapper for calling the encoder->get_buf_trans() hooks, allowing for a centralized place to e.g. check for VBT overrides for the buf translations. Cc: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260415115104.1721008-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-24gpio: qcom: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260423173553.92364-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-04-24Merge tag 'drm-misc-fixes-2026-04-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes This week in drm-misc-fixes, we have: - A patch to raise the vblank timeout to avoid it on virtual drivers - a state check fix for stm_lvds - a use-after-free fix for dma-buf - a mapping fix for panthor - a device_node reference leak fix for arcgpu - a bridge reference leak fix for dw-mipi-dsi - a sparse warning fix for dma-fence - a kconfig fix for hv - a memory leak fix for nouveau - a fix to duplicate colorop when duplicating states - a panel initialisation order fix for visionox-rm69299 - a fix to prevent an infinite loop for v3d - an overflow fix for nouveau Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260423-realistic-eager-reindeer-4dacf7@houat
2026-04-23bpf: Fix NULL pointer dereference in bpf_skb_fib_lookup()Weiming Shi
When tot_len is not provided by the user, bpf_skb_fib_lookup() resolves the FIB result's output device via dev_get_by_index_rcu() to check skb forwardability and fill in mtu_result. The returned pointer is dereferenced without a NULL check. If the device is concurrently unregistered, dev_get_by_index_rcu() returns NULL and is_skb_forwardable() crashes at dev->flags: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: is_skb_forwardable (include/linux/netdevice.h:4365) bpf_skb_fib_lookup (net/core/filter.c:6446) bpf_prog_test_run_skb (net/bpf/test_run.c) __sys_bpf (kernel/bpf/syscall.c) Add the missing NULL check, returning -ENODEV to be consistent with how bpf_ipv4_fib_lookup() and bpf_ipv6_fib_lookup() handle the same condition. Fixes: 4f74fede40df ("bpf: Add mtu checking to FIB forwarding helper") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://patch.msgid.link/20260423183831.1325480-2-bestswngs@gmail.com
2026-04-23sockmap: Fix sk_psock_drop() race vs sock_map_{unhash,close,destroy}().Kuniyuki Iwashima
syzbot reported a splat in sock_map_destroy() [0], where psock was NULL even though sk->sk_prot still pointed to tcp_bpf_prots[][]. The stack trace shows how badly the path was excercised, see inet_release() calls tcp_close(), not sock_map_close() yet, but finally reaching sock_map_destroy(). The root cause is a lack of synchronisation. Even if sk_psock_get() fails to bump psock->refcnt, it does not guarantee that sk_psock_drop() has finished, and thus sk->sk_prot might not have been restored to the original one. Commit 4b4647add7d3 ("sock_map: avoid race between sock_map_close and sk_psock_put") attempted to address this, but it was insufficient for two reasons. It did not cover sock_map_unhash() and sock_map_destroy(), and it missed the corner case where sk_psock() is NULL. On non-x86 platforms, sk_psock_restore_proto(sk, psock) and rcu_assign_sk_user_data(sk, NULL) can be reordered because there is no address dependency between sk->sk_prot and sk->sk_user_data. sk_psock_get() returning NULL implies nothing about sk->sk_prot. Let's simply retry sk_psock_get() in the unlikely case. Note that we cannot avoid loop even if we added memory barrier in sk_psock_drop() and sock_map_psock_get_checked(). Also note that sock_map_destroy() cannot be called from softirq while sock_map_close() has also been running. It is because sock_map_destroy() requires SOCK_DEAD, so sock_map_destroy() cannot happen until sock_map_close() has finished the saved_close() (which is tcp_close()). [0]: WARNING: CPU: 1 PID: 8459 at net/core/sock_map.c:1667 sock_map_destroy+0x28b/0x2b0 net/core/sock_map.c:1667 Modules linked in: CPU: 1 UID: 0 PID: 8459 Comm: syz.0.1109 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:sock_map_destroy+0x28b/0x2b0 net/core/sock_map.c:1667 Code: 8b 36 49 83 c6 38 4c 89 f0 48 c1 e8 03 42 80 3c 38 00 74 08 4c 89 f7 e8 93 62 22 f9 4d 8b 3e e9 79 ff ff ff e8 a6 2b c3 f8 90 <0f> 0b 90 eb 9c e8 9b 2b c3 f8 4c 89 e7 be 03 00 00 00 e8 0e 4e bc RSP: 0018:ffffc9000d067be8 EFLAGS: 00010293 RAX: ffffffff88fb30aa RBX: ffff888024832000 RCX: ffff888024283b80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffed100862e946 R12: dffffc0000000000 R13: ffff888024832000 R14: ffffffff995b2208 R15: ffffffff88fb2e20 FS: 0000555579a7d500(0000) GS:ffff8881269c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00002000000048c0 CR3: 000000003713a000 CR4: 00000000003526f0 Call Trace: <TASK> inet_csk_destroy_sock+0x166/0x3a0 net/ipv4/inet_connection_sock.c:1294 __tcp_close+0xcc1/0xfd0 net/ipv4/tcp.c:3262 tcp_close+0x28/0x110 net/ipv4/tcp.c:3274 inet_release+0x144/0x190 net/ipv4/af_inet.c:435 __sock_release net/socket.c:649 [inline] sock_close+0xc0/0x240 net/socket.c:1439 __fput+0x45b/0xa80 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f265847ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd158dfbd8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 000000000002ddb0 RCX: 00007f265847ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f26586a7da0 R08: 0000000000000001 R09: 0000000e158dfecf R10: 0000001b30a20000 R11: 0000000000000246 R12: 00007f26586a5fac R13: 00007f26586a5fa0 R14: ffffffffffffffff R15: 00007ffd158dfcf0 </TASK> Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks") Fixes: b05545e15e1f ("bpf: sockmap, fix transition through disconnect without close") Fixes: d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") Reported-by: syzbot+b0842d38af58376d1fdc@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/69cec5ef.050a0220.2dbe29.0009.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260420194846.1089595-1-kuniyu@google.com
2026-04-23bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag pathsWeiming Shi
bpf_selem_unlink_nofail() sets SDATA(selem)->smap to NULL before removing the selem from the storage hlist. A concurrent RCU reader in bpf_sk_storage_clone() can observe the selem still on the list with smap already NULL, causing a NULL pointer dereference. general protection fault, probably for non-canonical address 0xdffffc000000000a: KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057] RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174 Call Trace: <IRQ> sk_clone+0xfed/0x1980 net/core/sock.c:2591 inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222 tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571 tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729 tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855 tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347 Add a NULL check for smap in bpf_sk_storage_clone(). bpf_sk_storage_diag_put_all() has the same issue. Add a NULL check and pass the validated smap directly to diag_get(), which is refactored to take smap as a parameter instead of reading it internally. bpf_sk_storage_diag_put() uses diag->maps[i] which is always valid under its refcount, so diag->maps[i] is passed directly to diag_get(). Fixes: 5d800f87d0a5 ("bpf: Support lockless unlink when freeing map or local storage") Reported-by: Xiang Mei <xmei5@asu.edu> Acked-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20260422065411.1007737-2-bestswngs@gmail.com
2026-04-23Merge tag 'vfs-7.1-rc1.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - eventpoll: fix ep_remove() UAF and follow-up cleanup - fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error - writeback: Fix use after free in inode_switch_wbs_work_fn() - fuse: reject oversized dirents in page cache - fs: aio: reject partial mremap to avoid Null-pointer-dereference error - nstree: fix func. parameter kernel-doc warnings - fs: Handle multiply claimed blocks more gracefully with mmb * tag 'vfs-7.1-rc1.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: eventpoll: drop vestigial epi->dying flag eventpoll: drop dead bool return from ep_remove_epi() eventpoll: refresh eventpoll_release() fast-path comment eventpoll: move f_lock acquisition into ep_remove_file() eventpoll: fix ep_remove struct eventpoll / struct file UAF eventpoll: move epi_fget() up eventpoll: rename ep_remove_safe() back to ep_remove() eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}() eventpoll: kill __ep_remove() eventpoll: split __ep_remove() eventpoll: use hlist_is_singular_node() in __ep_remove() fs: Handle multiply claimed blocks more gracefully with mmb nstree: fix func. parameter kernel-doc warnings fs: aio: reject partial mremap to avoid Null-pointer-dereference error fuse: reject oversized dirents in page cache writeback: Fix use after free in inode_switch_wbs_work_fn() fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error
2026-04-23Merge tag 'v7.1-rc-part2-ksmbd-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull more smb server updates from Steve French: - move fs/smb/common/smbdirect to fs/smb/smbdirect - change signature calc to use AES-CMAC library, simpler and faster - invalid signature fix - multichannel fix - open create options fix - fix durable handle leak - cap maximum lock count to avoid potential denial of service - four connection fixes: connection free and session destroy IDA fixes, refcount fix, connection leak fix, max_connections off by one fix - IPC validation fix - fix out of bounds write in getting xattrs - fix use after free in durable handle reconnect - three ACL fixes: fix potential ACL overflow, harden num_aces check, and fix minimum ACE size check * tag 'v7.1-rc-part2-ksmbd-fixes' of git://git.samba.org/ksmbd: smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ smb: server: stop sending fake security descriptors ksmbd: scope conn->binding slowpath to bound sessions only ksmbd: fix CreateOptions sanitization clobbering the whole field ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open ksmbd: fix O(N^2) DoS in smb2_lock via unbounded LockCount ksmbd: destroy async_ida in ksmbd_conn_free() ksmbd: destroy tree_conn_ida in ksmbd_session_destroy() ksmbd: Use AES-CMAC library for SMB3 signature calculation ksmbd: reset rcount per connection in ksmbd_conn_wait_idle_sess_id() ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment ksmbd: use check_add_overflow() to prevent u16 DACL size overflow ksmbd: fix use-after-free in smb2_open during durable reconnect ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb: server: fix max_connections off-by-one in tcp accept path ksmbd: require minimum ACE size in smb_check_perm_dacl() ksmbd: validate response sizes in ipc_validate_msg() smb: server: fix active_num_conn leak on transport allocation failure
2026-04-23Merge tag 'v7.1-rc1-part3-smb3-client-fixes' of ↵Linus Torvalds
git://git.samba.org/sfrench/cifs-2.6 Pull smb client fixes from Steve French: - Four bug fixes: OOB read in ioctl query info, 3 ACL fixes - SMB1 Unix extensions mount fix - Four crypto improvements: move to AES-CMAC library, simpler and faster - Remove drop_dir_cache to avoid potential crash, and move to /procfs - Seven SMB3.1.1 compression fixes * tag 'v7.1-rc1-part3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb: client: Drop 'allocate_crypto' arg from smb*_calc_signature() smb: client: Make generate_key() return void smb: client: Remove obsolete cmac(aes) allocation smb: client: Use AES-CMAC library for SMB3 signature calculation smb: common: add SMB3_COMPRESS_MAX_ALGS smb: client: compress: add code docs to lz77.c smb: client: compress: LZ77 optimizations smb: client: compress: increase LZ77_MATCH_MAX_DIST smb: client: compress: fix counting in LZ77 match finding smb: client: compress: fix buffer overrun in lz77_compress() smb: client: scope end_of_dacl to CIFS_DEBUG2 use in parse_dacl smb: client: fix (remove) drop_dir_cache module parameter smb: client: require a full NFS mode SID before reading mode bits smb: client: validate the whole DACL before rewriting it in cifsacl smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path cifs: update internal module version number smb: client: compress: fix bad encoding on last LZ77 flag smb: client: fix dir separator in SMB1 UNIX mounts
2026-04-23Merge tag 'net-7.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Netfilter. Steady stream of fixes. Last two weeks feel comparable to the two weeks before the merge window. Lots of AI-aided bug discovery. A newer big source is Sashiko/Gemini (Roman Gushchin's system), which points out issues in existing code during patch review (maybe 25% of fixes here likely originating from Sashiko). Nice thing is these are often fixed by the respective maintainers, not drive-bys. Current release - new code bugs: - kconfig: MDIO_PIC64HPSC should depend on ARCH_MICROCHIP Previous releases - regressions: - add async ndo_set_rx_mode and switch drivers which we promised to be called under the per-netdev mutex to it - dsa: remove duplicate netdev_lock_ops() for conduit ethtool ops - hv_sock: report EOF instead of -EIO for FIN - vsock/virtio: fix MSG_PEEK calculation on bytes to copy Previous releases - always broken: - ipv6: fix possible UAF in icmpv6_rcv() - icmp: validate reply type before using icmp_pointers - af_unix: drop all SCM attributes for SOCKMAP - netfilter: fix a number of bugs in the osf (OS fingerprinting) - eth: intel: fix timestamp interrupt configuration for E825C Misc: - bunch of data-race annotations" * tag 'net-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (148 commits) rxrpc: Fix error handling in rxgk_extract_token() rxrpc: Fix re-decryption of RESPONSE packets rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets rxrpc: Fix missing validation of ticket length in non-XDR key preparsing rxgk: Fix potential integer overflow in length check rxrpc: Fix conn-level packet handling to unshare RESPONSE packets rxrpc: Fix potential UAF after skb_unshare() failure rxrpc: Fix rxkad crypto unalignment handling rxrpc: Fix memory leaks in rxkad_verify_response() net: rds: fix MR cleanup on copy error m68k: mvme147: Make me the maintainer net: txgbe: fix firmware version check selftests/bpf: check epoll readiness during reuseport migration tcp: call sk_data_ready() after listener migration vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll() ipv6: Cap TLV scan in ip6_tnl_parse_tlv_enc_lim tipc: fix double-free in tipc_buf_append() llc: Return -EINPROGRESS from llc_ui_connect() ipv4: icmp: validate reply type before using icmp_pointers selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both edges ...
2026-04-23Merge tag 'i2c-for-7.1-rc1-part2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull more i2c updates from Wolfram Sang: - cx92755: convert I2C bindings to DT schema - mediatek: add optional bus power management during transfers - pxa: handle early bus busy condition - MAINTAINERS: update I2C RUST entry * tag 'i2c-for-7.1-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: add Rust I2C tree and update Igor Korotin's email i2c: mediatek: add bus regulator control for power saving dt-bindings: i2c: cnxt,cx92755-i2c: Convert to DT schema i2c: pxa: handle 'Early Bus Busy' condition on Armada 3700
2026-04-23Merge tag 'xtensa-20260422' of https://github.com/jcmvbkbc/linux-xtensaLinus Torvalds
Pull Xtensa updates from Max Filippov: - use register_sys_off_handler(SYS_OFF_MODE_RESTART) instead of the deprecated register_restart_handler() - drop custom ucontext.h and reuse asm-generic ucontext.h * tag 'xtensa-20260422' of https://github.com/jcmvbkbc/linux-xtensa: xtensa: uapi: Reuse asm-generic ucontext.h xtensa: xtfpga: Use register_sys_off_handler(SYS_OFF_MODE_RESTART) xtensa: xt2000: Use register_sys_off_handler(SYS_OFF_MODE_RESTART) xtensa: ISS: Use register_sys_off_handler(SYS_OFF_MODE_RESTART)
2026-04-24Merge tag 'amd-drm-fixes-7.1-2026-04-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-7.1-2026-04-23: amdgpu: - DC idle state manager fix - ASPM fix - GPUVM SVM fix - DCE 6 fix amdkfd: - num_of_nodes bounds check fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260423170129.2345978-1-alexander.deucher@amd.com
2026-04-24Merge tag 'drm-misc-next-fixes-2026-04-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Short summary of fixes pull: rcar-du: - fix NULL-ptr crash Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260423130852.GA114622@linux.fritz.box
2026-04-23Merge branch 'remove-a-number-of-isa-and-pcmcia-ethernet-drivers'Jakub Kicinski
Andrew Lunn says: ==================== Remove a number of ISA and PCMCIA Ethernet drivers These old drivers have not been much of a Maintenance burden until recently. Now there are more newbies using AI and fuzzers finding issues, resulting in more work for Maintainers. Fixing these old drivers make little sense, if it is not clear they have users. These mostly ISA and PCMCIA Ethernet devices, mostly from the last century, a couple from 2001 or 2002. It seems unlikely they are still used. However, remove them one patch at a time so they can be brought back if somebody still has the hardware, runs modern kernels and wants to take up the roll of driver Maintainer. ==================== Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-0-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 8390: wd80x3: Remove this driverAndrew Lunn
The wd80x3 was written by Donald Becker 1993 to 1994. It is an ISA device, so unlikely to be used with modern kernels. Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-15-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 8390: ultra: Remove this driverAndrew Lunn
The ultra was written by Donald Becker 1993 to 1998. It is an ISA device, so unlikely to be used with modern kernels. Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-14-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 8390: AX88190: Remove this driverAndrew Lunn
The ax88190 was written by David A. Hinds in 2001. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-12-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: fujitsu: fmvj18x: Remove this driverAndrew Lunn
The fmvj18x was written by Shingo Fujimoto in 2002. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-11-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: smsc: smc91c92: Remove this driverAndrew Lunn
The smc91c92 was written by David A Hinds in 1999. It is an PCMCIA device, so unlikely to be used with modern kernels. Remove the Documentation as well, since it refers to kernel versions 1.2.13 until 1.3.71 and FTP sites which no longer exist. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-8-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: smsc: smc9194: Remove this driverAndrew Lunn
The smc9194 was written by Erik Stahlman in 1996. It is an ISA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-7-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: amd: nmclan: Remove this driverAndrew Lunn
The nmclan was written by Roger C Pao in 1995. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-6-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: amd: lance: Remove this driverAndrew Lunn
The lance was written by Donald Becker between 1993-1998. It is an ISA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-5-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 3com: 3c589: Remove this driverAndrew Lunn
The 3c589 was written by David A. Hinds 2001. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-4-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 3com: 3c574: Remove this driverAndrew Lunn
The 3c574 was written by Donald Becker between 1993-1998. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-3-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 3com: 3c515: Remove this driverAndrew Lunn
The 3c515 was written by Donald Becker between 1997-1998. It is an ISA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-2-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-23drivers: net: 3com: 3c509: Remove this driverAndrew Lunn
The 3c509 was written by Donald Becker between 1993-2000. It is an ISA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-1-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-24Merge patch series "eventpoll: fix ep_remove() UAF and follow-up cleanup"Christian Brauner
Christian Brauner <brauner@kernel.org> says: ep_remove() (via __ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file in the same critical section: is_file_epoll(), hlist_del_rcu() through the head, spin_unlock. A concurrent __fput() on the watched eventpoll caught the transient NULL in eventpoll_release()'s lockless fast path, skipped eventpoll_release_file() entirely, and ran to ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(). That kfree()s the struct eventpoll whose embedded ->refs hlist_head is exactly where epi->fllink.pprev points and the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory, which is the slab-use-after-free KASAN caught. struct file is SLAB_TYPESAFE_BY_RCU on top of that so the same window also lets the slot recycle while ep_remove() is still nominally inside file->f_lock. The upshot is an attacker-influencable kmem_cache_free() against the wrong slab cache. The comment on eventpoll_release()'s fast path - "False positives simply cannot happen because the file in on the way to be removed and nobody ( but eventpoll ) has still a reference to this file" - was itself the wrong invariant this race exploits. The fix pins @file via epi_fget() at the top of ep_remove() and gates the f_ep clear / hlist_del_rcu() on the pin succeeding. With the pin held __fput() cannot start which transitively keeps the watched struct eventpoll alive across the critical section and also prevents the struct file slot from recycling. Both UAFs are closed. If the pin fails __fput() is already in flight on @file. Because we bail before clearing f_ep that path takes eventpoll_release()'s slow path into eventpoll_release_file() which blocks on ep->mtx until ep_clear_and_put() drops it and then cleans up the orphaned epi. The bailed epi's share of ep->refcount stays intact so ep_clear_and_put()'s trailing ep_refcount_dec_and_test() cannot free the eventpoll out from under eventpoll_release_file(). With epi_fget() now gating every ep_remove() call the epi->dying flag becomes vestigial. epi->dying == true always coincides with file_ref_get() == false because __fput() is reachable only once the refcount hits zero and the refcount is monotone there. The last patch drops the flag and leaves a single coordination mechanism instead of two. * patches from https://patch.msgid.link/20260423-work-epoll-uaf-v1-0-2470f9eec0f5@kernel.org: eventpoll: drop vestigial epi->dying flag eventpoll: drop dead bool return from __ep_remove_epi() eventpoll: refresh eventpoll_release() fast-path comment eventpoll: move f_lock acquisition into __ep_remove_file() eventpoll: fix ep_remove struct eventpoll / struct file UAF eventpoll: move epi_fget() up eventpoll: rename ep_remove_safe() back to ep_remove() eventpoll: kill __ep_remove() eventpoll: split __ep_remove() eventpoll: use hlist_is_singular_node() in __ep_remove() Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-0-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24eventpoll: drop vestigial epi->dying flagChristian Brauner
With ep_remove() now pinning @file via epi_fget() across the f_ep clear and hlist_del_rcu(), the dying flag no longer orchestrates anything: it was set in eventpoll_release_file() (which only runs from __fput(), i.e. after @file's refcount has reached zero) and read in __ep_remove() / ep_remove() as a cheap bail before attempting the same synchronization epi_fget() now provides unconditionally. The implication is simple: epi->dying == true always coincides with file_ref_get(&file->f_ref) == false, because __fput() is reachable only once the refcount hits zero and the refcount is monotone in that state. The READ_ONCE(epi->dying) in ep_remove() therefore selects exactly the same callers that epi_fget() would reject, just one atomic cheaper. That's not worth a struct field, a second coordination mechanism, and the comments on both. Refresh the eventpoll_release_file() comment to describe what actually makes the path race-free now (the pin in ep_remove()). No functional change: the correctness argument is unchanged, only the mechanism is now a single one instead of two. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-10-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: drop dead bool return from ep_remove_epi()Christian Brauner
ep_remove_epi() always returns true -- the "can be disposed" answer was meaningful back when the dying-check lived inside the pre-split __ep_remove(), but after that check moved to ep_remove() the return value is just noise. Both callers gate on it unconditionally: if (ep_remove_epi(ep, epi)) WARN_ON_ONCE(ep_refcount_dec_and_test(ep)); dispose = ep_remove_epi(ep, epi); ... if (dispose && ep_refcount_dec_and_test(ep)) ep_free(ep); Make ep_remove_epi() return void, drop the dispose local in eventpoll_release_file(), and the useless conditionals at both callers. No functional change. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-9-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: refresh eventpoll_release() fast-path commentChristian Brauner
The old comment justified the lockless READ_ONCE(file->f_ep) check with "False positives simply cannot happen because the file is on the way to be removed and nobody ( but eventpoll ) has still a reference to this file." That reasoning was the root of the UAF fixed in "eventpoll: fix ep_remove struct eventpoll / struct file UAF": __ep_remove() could clear f_ep while another close raced past the fast path and freed the watched eventpoll / recycled the struct file slot. With ep_remove() now pinning @file via epi_fget() across the f_ep clear and hlist_del_rcu(), the invariant is re-established for the right reason: anyone who might clear f_ep holds @file alive for the duration, so a NULL observation really does mean no concurrent eventpoll path has work left on this file. Refresh the comment accordingly so the next reader doesn't inherit the broken model. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-8-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: move f_lock acquisition into ep_remove_file()Christian Brauner
Let the helper own its critical section end-to-end: take &file->f_lock at the top, read file->f_ep inside the lock, release on exit. Callers (ep_remove() and eventpoll_release_file()) no longer need to wrap the call, and the function-comment lock-handoff contract is gone. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-7-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: fix ep_remove struct eventpoll / struct file UAFChristian Brauner
ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. Fixes: 58c9b016e128 ("epoll: use refcount to reduce ep_mutex contention") Reported-by: Jaeyoung Chung <jjy600901@snu.ac.kr> Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-6-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: move epi_fget() upChristian Brauner
We'll need it when removing files so move it up. No functional change. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-5-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: rename ep_remove_safe() back to ep_remove()Christian Brauner
The current name is just confusing and doesn't clarify anything. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-4-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}()Christian Brauner
With __ep_remove() gone, the double-underscore on __ep_remove_file() and __ep_remove_epi() no longer contrasts with a __-less parent and just reads as noise. Rename both to ep_remove_file() and ep_remove_epi(). No functional change. Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: kill __ep_remove()Christian Brauner
Remove the boolean conditional in __ep_remove() and restructure the code so the check for racing with eventpoll_release_file() are only done in the ep_remove_safe() path where they belong. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-3-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: split __ep_remove()Christian Brauner
Split __ep_remove() to delineate file removal from epoll item removal. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-2-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24eventpoll: use hlist_is_singular_node() in __ep_remove()Christian Brauner
Replace the open-coded "epi is the only entry in file->f_ep" check with hlist_is_singular_node(). Same semantics, and the helper avoids the head-cacheline access in the common false case. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-1-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-04-24fs: Handle multiply claimed blocks more gracefully with mmbJan Kara
When a metadata block is referenced by multiple inodes and tracked by metadata bh infrastructure (which is forbidden and generally indicates filesystem corruption), it can happen that mmb_mark_buffer_dirty() is called for two different mmb structures in parallel. This can lead to a corruption of mmb linked list. Handle that situation gracefully (at least from mmb POV) by serializing on setting bh->b_mmb. Reported-by: Ruikai Peng <ruikai@pwno.io> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260423090311.10955-2-jack@suse.cz Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24nstree: fix func. parameter kernel-doc warningsRandy Dunlap
Use the correct parameter name ("__ns") for function parameter kernel-doc to avoid 3 warnings: Warning: include/linux/nstree.h:68 function parameter '__ns' not described in 'ns_tree_add_raw' Warning: include/linux/nstree.h:77 function parameter '__ns' not described in 'ns_tree_add' Warning: include/linux/nstree.h:88 function parameter '__ns' not described in 'ns_tree_remove' Fixes: 885fc8ac0a4d ("nstree: make iterator generic") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260416215429.948898-1-rdunlap@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24fs: aio: reject partial mremap to avoid Null-pointer-dereference errorZizhi Wo
[BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 ... Crash analysis showed the file involved was an AIO ring file. The phenomenon triggered is the same as the issue described in [1]. [CAUSE] Consider the following scenario: userspace sets up an AIO context via io_setup(), which creates a VMA covering the entire ring buffer. Then userspace calls mremap() with the AIO ring address as the source, a smaller old_len (less than the full ring size), MREMAP_MAYMOVE set, and without MREMAP_DONTUNMAP. The kernel will relocate the requested portion to a new destination address. During this move, __split_vma() splits the original AIO ring VMA. The requested portion is unmapped from the source and re-established at the destination, while the remainder stays at the original source address as an orphan VMA. The aio_ring_mremap() callback fires on the new destination VMA, updating ctx->mmap_base to the destination address. But the callback is unaware that only a partial region was moved and that an orphan VMA still exists at the source: source(AIO): +-------------------+---------------------+ | moved to dest | orphan VMA (AIO) | +-------------------+---------------------+ A A+partial_len A+ctx->mmap_size dest: +-------------------+ | moved VMA (AIO) | +-------------------+ B B+partial_len Later, io_destroy() calls vm_munmap(ctx->mmap_base, ctx->mmap_size), which unmaps the destination. This not only fails to unmap the orphan VMA at the source, but also overshoots the destination VMA and may unmap unrelated mappings adjacent to it! After put_aio_ring_file() calls truncate_setsize() to remove all pages from the pagecache, any subsequent access to the orphan VMA triggers filemap_fault(), which calls a_ops->read_folio(). Since aio does not implement read_folio, this results in a NULL pointer dereference. [FIX] Note that expanding mremap (new_len > old_len) is already rejected because AIO ring VMAs are created with VM_DONTEXPAND. The only problematic case is a partial move where "old_len == new_len" but both are smaller than the full ring size. Fix this by checking in aio_ring_mremap() that the new VMA covers the entire ring. This ensures the AIO ring is always moved as a whole, preventing orphan VMAs and the subsequent crash. [1]: https://lore.kernel.org/all/20260413010814.548568-1-wozizhi@huawei.com/ Signed-off-by: Zizhi Wo <wozizhi@huaweicloud.com> Link: https://patch.msgid.link/20260418060634.3713620-1-wozizhi@huaweicloud.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24fuse: reject oversized dirents in page cacheSamuel Page
fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable@vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam@bynar.io> Reported-by: Qi Tang <tpluszz77@gmail.com> Reported-by: Zijun Hu <nightu@northwestern.edu> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24writeback: Fix use after free in inode_switch_wbs_work_fn()Jan Kara
inode_switch_wbs_work_fn() has a loop like: wb_get(new_wb); while (1) { list = llist_del_all(&new_wb->switch_wbs_ctxs); /* Nothing to do? */ if (!list) break; ... process the items ... } Now adding of items to the list looks like: wb_queue_isw() if (llist_add(&isw->list, &wb->switch_wbs_ctxs)) queue_work(isw_wq, &wb->switch_work); Because inode_switch_wbs_work_fn() loops when processing isw items, it can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is empty. This is a problem because in that case wb can get freed (no isw items -> no wb reference) while the work is still pending causing use-after-free issues. We cannot just fix this by cancelling work when freeing wb because that could still trigger problematic 0 -> 1 transitions on wb refcount due to wb_get() in inode_switch_wbs_work_fn(). It could be all handled with more careful code but that seems unnecessarily complex so let's avoid that until it is proven that the looping actually brings practical benefit. Just remove the loop from inode_switch_wbs_work_fn() instead. That way when wb_queue_isw() queues work, we are guaranteed we have added the first item to wb->switch_wbs_ctxs and nobody is going to remove it (and drop the wb reference it holds) until the queued work runs. Fixes: e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes") CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260413093618.17244-2-jack@suse.cz Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-24fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference errorZizhi Wo
[BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 [ 51.115408] handle_mm_fault+0x24c/0x570 [ 51.115958] do_user_addr_fault+0x226/0xa50 ... Crash analysis showed the file involved was an AIO ring file. [CAUSE] PARENT process CHILD process t=0 io_setup(1, &ctx) [access ctx addr] fork() io_destroy vm_munmap // not affect child vma percpu_ref_put ... put_aio_ring_file t=1 [access ctx addr] // pagefault ... __do_fault filemap_fault max_idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE) t=2 truncate_setsize truncate_pagecache t=3 filemap_get_folio // no folio, create folio __filemap_get_folio(..., FGP_CREAT, ...) // page_not_uptodate filemap_read_folio(file, mapping->a_ops->read_folio, folio) // oops! At t=0, the parent process calls io_setup and then fork. The child process gets its own VMA but without any PTEs. The parent then calls io_destroy. Before i_size is truncated to 0, at t=1 the child process accesses this AIO ctx address and triggers a pagefault. After the max_idx check passes, at t=2 the parent calls truncate_setsize and truncate_pagecache. At t=3 the child fails to obtain the folio, falls into the "page_not_uptodate" path, and hits this problem because AIO does not implement "read_folio". [Fix] Fix this by marking the AIO ring buffer VMA with VM_DONTCOPY so that fork()'s dup_mmap() skips it entirely. This is the correct semantic because: 1) The child's ioctx_table is already reset to NULL by mm_init_aio() during fork(), so the child has no AIO context and no way to perform any AIO operations on this mapping. 2) The AIO ring VMA is only meaningful in conjunction with its associated kioctx, which is never inherited across fork(). So child process with no AIO context has no legitimate reason to access the ring buffer. Delivering SIGSEGV on such an erroneous access is preferable to a kernel crash. Signed-off-by: Zizhi Wo <wozizhi@huaweicloud.com> Link: https://patch.msgid.link/20260413010814.548568-1-wozizhi@huawei.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-23Merge branch 'net-packetengines-remove-obsolete-pci-drivers'Jakub Kicinski
Mingyu Wang says: ==================== net: packetengines: remove obsolete PCI drivers As discussed with Andrew Lunn, this patch series removes the obsolete hamachi and yellowfin PCI drivers. Both drivers support hardware that is over two decades old and no longer in active use. Removing them eliminates dead code and reduces the overall maintenance burden on the netdev subsystem. ==================== Jakub: trim defconfigs appropriately Link: https://patch.msgid.link/20260422044820.485660-1-25181214217@stu.xidian.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 11:19:38 +0000