summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-07selftests/lsm: Fix memory leak in attr_lsm_countWang Yan
The calloc-allocated buffer in attr_lsm_count() is never released on any exit path, including both the normal return path and the early return when read_sysfs_lsms fails, resulting in a heap memory leak. Add free() for the buffer on all return branches to fix the leak. Fixes: d3d929a8b0cd ("LSM: selftests for Linux Security Module syscalls") Signed-off-by: Wang Yan <wangyan01@kylinos.cn> Reviewed-by: William Roberts <bill.c.roberts@gmail.com> Tested-by: William Roberts <bill.c.roberts@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07cred: delete task_euid()Alice Ryhl
task_euid() is a very weird operation. You can see how weird it is by grepping for task_euid() - binder is its only user. task_euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). Since usage in Binder has now been removed, get rid of the resulting dead code. Changes to the zh_CN translation was carried out with the help of Gemini and Google Translate, and since adjusted as per Alex Shi's feedback. Suggested-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07rust: task: clarify comments on task UID accessorsJann Horn
Linux has separate subjective and objective task credentials, see the comment above `struct cred`. Clarify which accessor functions operate on which set of credentials. Also document that Task::euid() is a very weird operation. You can see how weird it is by grepping for task_euid() in the history - binder was its only user. Task::euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). For context: Arguably, binder's use of task_euid() is a theoretical security problem, which only has no impact on Android because Android has no setuid binaries executable by apps. commit 29bc22ac5e5b ("binder: use euid from cred instead of using task") originally fixed that by removing that only user of task_euid(), but the fix got reverted in commit c21a80ca0684 ("binder: fix test regression due to sender_euid change") because some Android test started failing. It was since fixed again by commit 65b672152289 ("binder: use current_euid() for transaction sender identity"), which uses current_euid() instead. Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07selftests/bpf: Fix memory leak in msg_alloc_iovFeng Yang
In the msg_alloc_iov function, the iov pointer is only assigned to msg->msg_iov after all memory allocations complete successfully. Therefore, when a calloc failure triggers the unwind_iov cleanup branch, we should use the local variable iov instead of msg->msg_iov. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Feng Yang <yangfeng@kylinos.cn> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260707081434.539327-1-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Drop tc/xdp/flow_dissector/socket_filter sockmap mutation testsSechang Lim
tc, xdp, socket_filter and flow_dissector programs can no longer update or delete a sockmap. Adjust the tests: - verifier_sockmap_mutate: the tc, xdp, socket_filter and flow_dissector cases now expect __failure with "cannot update sockmap in this context". - sockmap_basic: drop "sockmap update" / "sockhash update", which load a SEC("tc") program that copies a sock between maps. - fexit_bpf2bpf: drop "func_sockmap_update", whose freplace program updates a sockmap in the tc cls_redirect context. Remove the now-unused test_sockmap_update.c and freplace_cls_redirect.c. Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260630145410.3648099-3-rhkrqnwk98@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07bpf, sockmap: Disallow update and delete from tc, xdp, socket_filter and ↵Sechang Lim
flow_dissector sock_map_update_common() and __sock_map_delete() hold stab->lock and call sock_map_unref() -> sock_map_del_link(), which takes sk_callback_lock for write. That gives the order stab->lock -> sk_callback_lock. The reverse order comes from the SK_SKB stream parser. sk_psock_strp_data_ready() holds sk_callback_lock for read, and after the verdict tcp_bpf_strp_read_sock() acks the consumed data inline via __tcp_cleanup_rbuf(). The ACK goes out egress, where a sched_cls program deletes from the sockmap and takes stab->lock: WARNING: possible circular locking dependency detected ------------------------------------------------------ syz.9.8824 is trying to acquire lock: (&stab->lock){+.-.}-{3:3}, at: __sock_map_delete net/core/sock_map.c:421 but task is already holding lock: (clock-AF_INET){++.-}-{3:3}, at: sk_psock_strp_data_ready net/core/skmsg.c:1173 -> #1 (clock-AF_INET){++.-}-{3:3}: _raw_write_lock_bh sock_map_del_link net/core/sock_map.c:167 sock_map_unref net/core/sock_map.c:184 sock_map_update_common net/core/sock_map.c:509 sock_map_update_elem_sys net/core/sock_map.c:588 map_update_elem kernel/bpf/syscall.c:1805 -> #0 (&stab->lock){+.-.}-{3:3}: _raw_spin_lock_bh __sock_map_delete net/core/sock_map.c:421 sock_map_delete_elem net/core/sock_map.c:452 bpf_prog_06044d24140080b6 tcx_run net/core/dev.c:4451 sch_handle_egress net/core/dev.c:4541 __dev_queue_xmit net/core/dev.c:4808 ... tcp_bpf_strp_read_sock net/ipv4/tcp_bpf.c:701 strp_data_ready net/strparser/strparser.c:402 sk_psock_strp_data_ready net/core/skmsg.c:1174 tcp_data_queue net/ipv4/tcp_input.c:5661 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(clock-AF_INET); lock(&stab->lock); lock(clock-AF_INET); lock(&stab->lock); *** DEADLOCK *** A tc, xdp, socket_filter or flow_dissector program has no reason to update or delete a sockmap, and redirect does not go through here. Drop them from may_update_sockmap() so the verifier rejects it. It also closes the matching sockhash inversion. Suggested-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260630145410.3648099-2-rhkrqnwk98@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07KVM: selftests: Add xAPIC support in eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-x' flag to let the user run the test in xAPIC mode instead of the default x2APIC mode. When using xAPIC mode, sanity check user input to ensure the test is being run with at most 255 vCPUs, as xAPIC can only address IDs 0-254 (255, i.e. 0xff, broadcasts to all CPUs). Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: add sanity check on number of vCPUs] Link: https://patch.msgid.link/20260626213534.3866178-21-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Make number of vCPUs configurable in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-v' flag to allow the user to configure the number of vCPUs to create and run (versus only ever using a single vCPU). Update the routing logic to play nice with 32 bit IDs, enable x2APIC format in KVM (to enable 32-bit ID routing), and disable KVM's x2APIC broadcast quirk so that targeting vCPU 255 doesn't blast the interrupt to all vCPUs when in x2APIC mode. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260626213534.3866178-20-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify vCPU migration during IRQ delivery in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-m' flag to have the test migrate the target vCPU to a random physical CPU before triggering its interrupt, e.g. to validate KVM's ability to update device posted IRQ routing. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: pin one vCPU at a time to simplify things, use main()'s affinity] Link: https://patch.msgid.link/20260626213534.3866178-19-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add a utility to pin a task to a random CPU, given a CPU setJosh Hilke
Add a helper function, pin_task_to_random_cpu(), to pin a task to a random CPU from a given cpu_set_t. This helper will be used eventfd IRQ test to migrate vCPUs to random pCPUs, to stress host-side interrupt routing and delivery. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add kvm_sched_getaffinity() wrapper and convert usersJosh Hilke
Add and use a KVM wrapper for the sched_getaffinity() syscall so that selftests don't need to manually assert that the syscall succeeded. Note, some tests didn't actually assert success, but they all obviously rely on the syscall to succeed. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add kvm_gettid() wrapper and convert usersJosh Hilke
Add a KVM wrapper for the gettid() syscall so that tests don't have to open code the syscall() themselves. Unfortunately, not all flavors of libc that KVM selftests support provide gettid(). Convert all existing users of the syscall to the new wrapper. Note, per the gettid() manpage[1], "This call is always successful", i.e. prefixing kvm_ to the syscall name is aligned with the goal of providing syscall wrappers that guarantee success. No functional changes intended. Link: https://man7.org/linux/man-pages/man2/gettid.2.html [1] Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-16-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify non-postable IRQ remapping in IRQ testSean Christopherson
Extend the eventfd IRQ test with an '-n' flag to route a subset of device interrupts as NMIs (Non-Maskable Interrupts) into the guest using an alternating pattern of 4 NMIs followed by 4 regular interrupts. While this adds coverage for NMI injection, the primary goal is to validate KVM's handling of non-postable interrupt delivery (AMD and Intel IOMMUs only support posting fixed IRQs targeting a single vCPU). KVM has historically bungled handling transitions between posted and remapped modes. Use NMIs to stress the transitions, because they are a reliable, architectural way to force these code paths. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: add GUEST_RECEIVED_INTERRUPT(), massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Make number of IRQs configurable in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-i' flag to let the user specify the the number of IRQs to generate (instead of hardcoding the test to always generate 1000 interrupts). Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add option to set empty routing between IRQs in eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with an '-e' flag to set empty GSI routing between interrupts. Clobbering the GSI routing table verifies that KVM correctly handles CPUx => NULL => CPUy transitions, not just CPUx => CPUy transitions, and verifies that KVM can "rebuild" an entire routing setup. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: '-e' for "empty" instead of '-c' for "clear", massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify interrupts are received when IRQ affinity changes in ↵David Matlack
IRQ test Extent the eventfd IRQ test with a '-a' flag to randomly affinitize the device's host IRQ to different physical CPUs throughout the test. This stresses the kernel's ability to maintain correct interrupt routing and delivery even as the underlying hardware IRQ affinity is changed dynamically via /proc/<irq>/smp_affinity{,_list}. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add a helper to set proc IRQ affinity for IRQ testJosh Hilke
Add a utility, proc_irq_set_smp_affinity(), to set the CPU affinity of a Linux host IRQ via the proc filesystem. Use smp_affinity_list instead of smp_affinity to avoid having to convert the single CPU to a bitmask. The helper will be used by the eventfd IRQ test to verify delivery of IRQs when the affinity is randomized/modified. Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: make the utility self-contained, drop "list", massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add VFIO device support to eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-d' argument that takes a BDF (in the format segment:bus:device.function) of an interrupt-capable PCI(e) device bound to VFIO, and use said device to trigger interrupts instead of always synthesizing interrupts via direct writes to the eventfd. Using a VFIO device to trigger interrupts validates the end-to-end delivery of IRQs for "real" devices, and when supported by hardware (and KVM), also validates interrupt delivery via IRQ bypass, i.e. via device posted IRQs. Now that IOMMUFD is a thing, auto-probe IOMMUFD vs. "legacy" VFIO by temporarily opening /dev/iommufd, and skip the test if neither IOMMUFD nor legacy VFIO is available. Add a '-t' option to the user override the probe logic, e.g. in case IOMMUFD is available but the system is configured for legacy usage. Note, the device must have a VFIO selftest driver in order to work with the test. A helper script to list supported devices will hopefully be available in the near future at tools/testing/selftests/vfio/scripts/list_supported_devices.sh[1]. Example: $ ./tools/testing/selftests/kvm/irq_test -d 0000:06:0a.1 Link: https://lore.kernel.org/all/20260602222941.3133236-1-jrhilke%40google.com [1] Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260626213534.3866178-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add helper to get host IRQ from device MSI-X for IRQ bypass testDavid Matlack
Introduce proc_util.c and proc_util.h to house utility functions for interacting with the proc filesystem. Add vfio_msix_to_host_irq(), which parses /proc/interrupts, to get the host Linux IRQ for a given VFIO device BDF and MSI-X vector. This helper will be used by the eventfd IRQ test to print the host IRQ number when triggering IRQs via VFIO device, e.g. to aid in debugging if the test fails. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add an irqfd send+receive (and later IRQ bypass) testDavid Matlack
Add a new test, irq_test to verify that KVM correctly delivers interrupts to a running vCPU, when triggered via an eventfd bound to a KVM GSI using KVM's irqfd mechanism. This test is intentionally simple, for now. Support for sending interrupts via VFIO devices, for IRQ bypass, and for other features will be added in the near future. Add the test in common code, even though it currently will only build and run on x86, as the concept and the bulk of the host-side code isn't specific to x86. Suggested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/kvm/20250404193923.1413163-68-seanjc@google.com Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: use while() and TEST_ASSERT() instead of if-statement => TEST_FAIL()] Link: https://patch.msgid.link/20260626213534.3866178-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add helper to generate random u64 in range [min,max]Josh Hilke
Introduce kvm_random_u64_in_range(state, min, max). This function returns a random u64 in the inclusive range of [min, max] using a struct kvm_random_state. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Link: https://patch.msgid.link/20260626213534.3866178-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Seed libc's RNG before using it to generate a seed for KVM's ↵Sean Christopherson
pRNG Seed the RNG used by random() using the de facto standard method of srand(time(0)), so that a different seed is actually used in each test run. E.g. without seeding the RNG, literally every test on x86 will use 0x6b8b4567 to seed the KVM RNG. Link: https://patch.msgid.link/20260626213534.3866178-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Initialize the default/global pRNG during kvm_selftest_init()Sean Christopherson
Initialize the default kvm_rng during selftest initialization so that the pRNG can be used by tests before creating a VM. As pointed out by Sashiko, failure to actually initialize the generate makes it decidedly not random. Link: https://patch.msgid.link/20260626213534.3866178-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Rename guest_rng to kvm_rngJosh Hilke
Rename functions prefixed with 'guest_random_' to 'kvm_random_' and the global random state variable 'guest_rng' to 'kvm_rng', as the pRNG isn't strictly limited to guest code. This will allow using the pRNG in host code without creating confusing/misleading function calls. No functional changes are intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add macros to read/write+sync to/from guest memoryDavid Matlack
Add SYNC_FROM_GUEST_AND_READ(vm, variable), to read a variable value from the guest. Add WRITE_AND_SYNC_TO_GUEST(vm, variable, value) to write a value to a guest variable. These macros improve the readability of code which reads and writes data between host and guest in tests. Use the new macro in existing tests that do back-to-back write+sync. No functional changes are intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Build and link selftests/vfio/lib into KVM selftestsDavid Matlack
Include libvfio.mk into the KVM selftests Makefile and link it into all KVM selftests by adding it to LIBKVM_OBJS. This lays the groundwork for future changes to utilize VFIO devices to verify IRQ bypass in KVM selftests. Note that KVM selftests build their own copy of selftests/vfio/lib and the resulting object files are placed in $(OUTPUT)/lib. This allows the KVM and VFIO selftests to apply different CFLAGS when building without conflicting with each other. Signed-off-by: David Matlack <dmatlack@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Link: https://patch.msgid.link/20260626213534.3866178-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07nilfs2: handle corrupted checkpoint count gracefully during deletionIgor Putko
Syzkaller reported a kernel warning in nilfs_cpfile_delete_checkpoints() due to a corrupted checkpoint count on the storage medium where le32_to_cpu(cp->cp_checkpoints_count) is less than the number of checkpoints being deleted. Triggering a WARN_ON() for disk image corruption is suboptimal. Fix this by returning -EIO and reporting a filesystem error via nilfs_error() instead of interrupting execution with a kernel warning. Reported-by: syzbot+79b815da3aec0a6a4d02@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=79b815da3aec0a6a4d02 Signed-off-by: Igor Putko <igorpetindev@gmail.com> Fixes: 1f5abe7e7dbc ("nilfs2: replace BUG_ON and BUG calls triggerable from ioctl") Cc: stable+noautosel@kernel.org # Warning suppression primarily; will request backport individually if needed Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-07tracing/synthetic: Free type string on error pathYu Peng
parse_synth_field() builds a "__data_loc ..." type string before assigning it to field->type. If the seq_buf check fails, the common cleanup cannot free the temporary string. Free it before leaving. Link: https://patch.msgid.link/20260603062533.1096320-2-pengyu@kylinos.cn Signed-off-by: Yu Peng <pengyu@kylinos.cn> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07tracing/user_events: Fix use-after-free in user_event_mm_dup()Michael Bommarito
user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated. Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707165912.2560537-2-michael.bommarito@gmail.com Reported-by: XIAO WU <xiaowu.417@qq.com> Closes: https://lore.kernel.org/all/tencent_89647CE40DC452B891C65C94D1B271DE8E07@qq.com/ Suggested-by: Beau Belgrave <beaub@linux.microsoft.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07platform/x86: amd-pmc: Use correct IP block table for AMD 1Ah M80H SoCShyam Sundar S K
PMFW reports the S0i3 subsystem accounting per SoC, and the set of IP blocks and their bit ordering differ across SoC generations. Family 1Ah, Model 80h accounts for a distinct set of 19 IP blocks, which does not match the ordering in soc15_ip_blk[]. Commit 043af31c8d30 ("platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoC") wired amd_1ah_m80_cpu_info to soc15_ip_blk[], so M80H has been reporting incorrect S0i3 accounting via debugfs. Add soc15_ip_blk_v3[] with the correct ordering and point amd_1ah_m80_cpu_info at it. Fixes: 043af31c8d30 ("platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoC") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260707122852.2066987-1-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-07platform/x86: asus-armoury: update power limits for G614PRMarco Scardovi
The previously integrated power limits for the ASUS ROG Strix G16 G614PR laptop model were incorrect and too low compared to the windows counterparts. Update the power limits to the correct specifications based on the platform's hardware capabilities: - Increase AC PL1/SPL max limit from 90W to 120W. - Increase AC PL2/SPPT default/max from 110W/125W to 140W/145W. - Increase AC PL3/FPPT default/max from 110W/125W to 140W/145W. Fixes: 6b3bbe770f4ca0439710b7c42f88b9f6eeebabd0 (platform/x86: asus-armoury: add support for G614PR) Fixes: https://lore.kernel.org/platform-driver-x86/20260610152130.25892-1-scardracs@disroot.org/ Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260630142957.7751-1-scardracs@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-07accel/amdxdna: Fix hardware context race in amdxdna_update_heap()Lizhi Hou
amdxdna_update_heap() iterates over hardware contexts while holding xdna->dev_lock. During the iteration, amdxdna_pm_resume_get_locked() may temporarily release and reacquire the lock, allowing hardware contexts to be modified concurrently. Fix the race by calling amdxdna_pm_resume_get_locked() before iterating over hardware contexts. Fixes: dbc8fd7a03cb ("accel/amdxdna: Add expandable device heap support") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055818.479165-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Fix deadlock on debug BO command timeoutLizhi Hou
Both amdxdna_hwctx_sync_debug_bo() and amdxdna_drm_config_hwctx_ioctl() hold xdna->dev_lock while invoking backend operations. If the hardware hangs, aie2_cmd_wait() blocks waiting for a firmware response. When the DRM scheduler timeout expires, aie2_sched_job_timedout() is invoked to reset the hardware. However, the timeout handler also attempts to acquire dev_lock, resulting in a deadlock. Avoid this by releasing dev_lock before waiting for the firmware response and reacquiring it after the wait completes. This allows the timeout handler to proceed with device recovery when a debug BO command times out. Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055732.479103-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: fix open_ref leak and stale client pointer on dma map failureLizhi Hou
amdxdna_gem_obj_open() increments open_ref before attempting to set up the DMA address mapping. When amdxdna_dma_map_bo() fails, the function returned immediately without rolling back either change made on the first open (open_ref == 1 path). Fix it by decrementing open_ref and clearing abo->client on the error path. Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055658.479049-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Fix potential amdxdna_umap lifetime raceLizhi Hou
amdxdna_umap_release() calls the blocking mmu_interval_notifier_remove() before removing the object from abo->mem.umap_list. If aie2_populate_range() runs concurrently, it may obtain a reference to an amdxdna_umap that is being released, leading to a potential use-after-free. Use kref_get_unless_zero() in aie2_populate_range() when acquiring a reference. If the reference count has already dropped to zero, release is in progress and the entry is skipped. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260706221228.434099-1-lizhi.hou@amd.com
2026-07-07KVM: arm64: Fix propagation of TLBI level in kvm_pgtable_stage2_relax_perms()Marc Zyngier
Assigning the invalidation level (an s8 value) with TLBI_TTL_UNKNOWN (a 32bit signed value) is not ideal, to say the least. Instead of this, only pass TLBI_TTL_UNKNOWN to __kvm_tlb_flush_vmid_ipa_nsh() when we know for sure that we don't have a provided level. Fixes: 100baf0184896 ("KVM: arm64: Ensure level is always initialized when relaxing perms") Reported-by: Mark Brown <broonie@kernel.org> Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://lore.kernel.org/r/akztC7H2IsEKaq4i@sirena.org.uk Link: https://patch.msgid.link/20260707162935.1900874-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-07x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"Tycho Andersen (AMD)
Revert 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"). Section 8.8 of the SNP spec says: Before invoking SNP_INIT_EX with INIT_RMP set to 1, software must ensure that no CPUs contain dirty cache lines for the memory containing the RMP. Cachelines can be moved from cache to cache in a dirty state. The wbinvd_on_all_cpus() before SNP_INIT_EX flushes the caches for each CPU, but if the IPIs for WBINVD race with this dirty cacheline movement, it is possible that they may not get flushed, violating the firmware requirement. Doing wbinvd_on_all_cpus() before setting SNPEn is safer since the RMP table is not yet in use. [ Heroically bisected by Srikanth. ] [ bp: Massage commit message. ] Fixes: 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN") Reported-by: Srikanth Aithal <Srikanth.Aithal@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Srikanth Aithal <Srikanth.Aithal@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20260707150033.2364758-1-tycho@kernel.org
2026-07-07selftests/bpf: Add test for bpf_get_smp_processor_idMaxim Khmelevskii
Add a test which checks on each CPU that the bpf_get_smp_processor_id BPF helper is returning the correct CPU number. Signed-off-by: Maxim Khmelevskii <max@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/bpf/20260703125648.919196-6-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07s390/bpf: Replace ly instruction with llgfMaxim Khmelevskii
cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does. Fixes: 9012cf2491e3 ("s390/bpf: Inline smp_processor_id and current_task") Signed-off-by: Maxim Khmelevskii <max@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://sashiko.dev/#/patchset/20260414142930.528751-1-max%40linux.ibm.com Link: https://lore.kernel.org/bpf/20260703125648.919196-5-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07docs/bpf: Document BPF_STRICT_BUILD=0 to tolerate test build failuresRicardo B. Marlière
When the kernel config does not fully match the BPF selftest config fragment, some tests may fail to compile. BPF_STRICT_BUILD (defaulting to 1) makes any such failure fatal. Mention the option so that developers are aware they can set it to 0 to skip broken tests and keep the build going, which is particularly useful during bringup or when testing on constrained (e.g. distribution) configurations. Signed-off-by: Ricardo B. Marlière <rbm@suse.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706-b4-bpf_strict_build_docs-v1-1-5324d605c7b0@suse.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07Merge branch 'bpf-reject-mem_alloc-btf-accesses-past-bounds'Kumar Kartikeya Dwivedi
Yiyang Chen says: ==================== bpf: Reject MEM_ALLOC BTF accesses past bounds BTF struct walks can relax the top-level struct-size check for trailing flexible arrays. That relaxation must not let a PTR_TO_BTF_ID | MEM_ALLOC access escape the bytes allocated by bpf_obj_new() or bpf_percpu_obj_new(). Patch 1 rejects MEM_ALLOC BTF walks whose access range reaches past the current struct size before applying the flexible-array relaxation. This now also applies to struct ID matching used by kfunc and kptr type checks. Patch 2 adds a linked_list negative loader case for this path. Changes in v3: - Pass the flexible-array walk policy through btf_struct_ids_match() callers, so MEM_ALLOC kfunc/kptr type checks use the same bounds rule. - Rename the btf_struct_walk() parameter to walk_flex_arrays. - Rebase onto current bpf-next. v2: https://lore.kernel.org/bpf/cover.1782197377.git.chenyy23@mails.tsinghua.edu.cn/ v1: https://lore.kernel.org/bpf/cover.1782100805.git.chenyy23@mails.tsinghua.edu.cn/ ==================== Link: https://patch.msgid.link/cover.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Cover MEM_ALLOC access past object boundsYiyang Chen
Add a linked_list negative loader case for a program-BTF type whose last member is a zero-length flexible array. The program writes through the first flexible-array element of an object allocated by bpf_obj_new(). The verifier should reject the access when the BTF walk reaches beyond the static size of the allocated object. Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/e36fd5d2f4047809f0e5da46a7077083297e64db.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07bpf: Reject MEM_ALLOC BTF accesses past object boundsYiyang Chen
BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Fix memory leak in msg_alloc_iov error pathMalaya Kumar Rout
In msg_alloc_iov(), when calloc() fails for an individual iov_base allocation, the error path frees all previously allocated iov_base entries but fails to free the iov array itself that was allocated with calloc() at the beginning of the function. This results in a memory leak of the iov array. Add free(iov) in the unwind_iov error path to ensure proper cleanup of all allocated memory. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Malaya Kumar Rout <malayarout91@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260704122936.102394-1-malayarout91@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07Merge branch 'selftests-bpf-libarena-cleanup-and-bitmap-struct'Kumar Kartikeya Dwivedi
Emil Tsalapatis says: ==================== selftests/bpf: libarena cleanup and bitmap struct Cleanup patches for libarena, along with a new bitmap data type that is in use by sched-ext. Patch 1 is an NFC that properly renames the buddy selftests for consistency. Patch 2 fixes the zero variable used in libarena for can_loop based looping, and afterwrds removes all bpf_for() instances from the code. Patch 3 fixes an (untriggered) edge case that could cause spurious selftest failures. Finally, patches 4 to 6 introduce the bitmap data structure along with selftests. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> CHANGELOG ========= v3 was resent as the first submission was missing the first patch. v2 -> v3: (https://lore.kernel.org/bpf/20260701185235.4516-1-emil@etsalapatis.com) - Remove unused macros and fix typo in commit message (AI) v1 -> v2: (https://lore.kernel.org/bpf/20260618085626.19633-1-emil@etsalapatis.com) - Added acks by Ihor and Eduard - Fix missing commit message (Ihor) - Enforce 64 bits per cell with BITS_TO_LONG_LONG (Sashiko) - Add test for bmp_copy (Ihor) - Add atomic versions of _set() and _clear() (Ihor) and add a parallel selftest for them. ==================== Link: https://patch.msgid.link/20260706181730.21731-1-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Add parallel bitmap selftestEmil Tsalapatis
Add a selftest for testing the atomic bitmap set/clear/ test_and_set/test_and_clear operations. The selftest checks atomicity by spawning two threads, each of which either only works on even bits or with odd bits. The test checks that threads do not affect each other's bits. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-7-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Add bitmap selftestsEmil Tsalapatis
Add testing for the new arena bitmap data structure. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/bpf/20260706181730.21731-6-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Add arena-based bitmap data structureEmil Tsalapatis
Add an arena-based word-aligned bitmap data struture. The structure is useful as a building block, e.g., sched-ext uses it to represent cpumask structures. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-5-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Clean up allocation state before buddy testsEmil Tsalapatis
Summary: The buddy allocator requires the global BPF buddy allocator to not be already initialized. However, the test currently merely resets the allocator before the buddy tests instead of destroying it, and the test worked because the buddy test happened to run first. Properly destroy the allocator instead of resetting it. Fixes: b1487dc1b181 ("selftests/bpf: Add selftests for libarena buddy allocator") Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/bpf/20260706181730.21731-4-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Fix can-loop zero variable definitionEmil Tsalapatis
BPF can_loop based loops require the index variable to stay imprecise. This means we must initialize them from a currently imprecise variable instead of directly assigning 0 to them, like so: static volatile u32 zero = 0; for (i = zero; i < NUM_LOOPS; i++) { /* loop body */ } The libarena implementation of this technique is currently faulty. For the technique to work, the variable must not be in a map. This includes the .rodata DATASEC map used for const variables. However, libarena still defines the zero variable as constant. Modify the zero variable definition into a volatile variable. This change adds a complication caused by the compiler optimizing array derefences from for (i = zero; i < NUM_LOOPS; i++) { val = *(ptr + i); } into for (i = zero; i < NUM_LOOPS; i++) { val = *ptr++; } and causing verification failures. Use the barrier_var() clobber macro to prevent this optimization from taking place. Using barrier_var() is the only way to break the optimization, as annotating the index as volatile does not suffice. After that, remove the bpf_for() invocations introduced in libarena for parallel spmc testing. Reported-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-3-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 20:55:07 +0000