linux, branch v6.14

Linux 6.14

2025-03-24T14:02:41Z

Merge tag 'i2c-for-6.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2025-03-23T00:33:38Z

Pull i2c fix from Wolfram Sang: "Fix double free of irq in amd-mp2 driver" * tag 'i2c-for-6.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: amd-mp2: drop free_irq() of devm_request_irq() allocated irq

Merge tag 'perf-urgent-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-03-22T21:40:27Z

Pull x86 perf events fix from Ingo Molnar: "Fix an information leak regression in the AMD IBS PMU code" * tag 'perf-urgent-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/amd/ibs: Prevent leaking sensitive data to userspace

Merge tag 'keys-next-6.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd

2025-03-22T21:10:07Z

Pull keys fix from Jarkko Sakkinen: "Fix potential use-after-free in key_put()" * tag 'keys-next-6.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: keys: Fix UAF in key_put()

Merge tag 'io_uring-6.14-20250322' of git://git.kernel.dk/linux

2025-03-22T17:45:44Z

Pull io_uring fix from Jens Axboe: "Just a single fix for the commit that went into your tree yesterday, which exposed an issue with not always clearing notifications. That could cause them to be used more than once" * tag 'io_uring-6.14-20250322' of git://git.kernel.dk/linux: io_uring/net: fix sendzc double notif flush

io_uring/net: fix sendzc double notif flush

2025-03-22T14:14:36Z

refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 5823 at lib/refcount.c:28 refcount_warn_saturate+0x15a/0x1d0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15a/0x1d0 lib/refcount.c:28 Call Trace: io_notif_flush io_uring/notif.h:40 [inline] io_send_zc_cleanup+0x121/0x170 io_uring/net.c:1222 io_clean_op+0x58c/0x9a0 io_uring/io_uring.c:406 io_free_batch_list io_uring/io_uring.c:1429 [inline] __io_submit_flush_completions+0xc16/0xd20 io_uring/io_uring.c:1470 io_submit_flush_completions io_uring/io_uring.h:159 [inline] Before the blamed commit, sendzc relied on io_req_msg_cleanup() to clear REQ_F_NEED_CLEANUP, so after the following snippet the request will never hit the core io_uring cleanup path. io_notif_flush(); io_req_msg_cleanup(); The easiest fix is to null the notification. io_send_zc_cleanup() can still be called after, but it's tolerated. Reported-by: syzbot+cf285a028ffba71b2ef5@syzkaller.appspotmail.com Tested-by: syzbot+cf285a028ffba71b2ef5@syzkaller.appspotmail.com Fixes: cc34d8330e036 ("io_uring/net: don't clear REQ_F_NEED_CLEANUP unconditionally") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/e1306007458b8891c88c4f20c966a17595f766b0.1742643795.git.asml.silence@gmail.com Signed-off-by: Jens Axboe

keys: Fix UAF in key_put()

2025-03-22T13:36:49Z

Once a key's reference count has been reduced to 0, the garbage collector thread may destroy it at any time and so key_put() is not allowed to touch the key after that point. The most key_put() is normally allowed to do is to touch key_gc_work as that's a static global variable. However, in an effort to speed up the reclamation of quota, this is now done in key_put() once the key's usage is reduced to 0 - but now the code is looking at the key after the deadline, which is forbidden. Fix this by using a flag to indicate that a key can be gc'd now rather than looking at the key's refcount in the garbage collector. Fixes: 9578e327b2b4 ("keys: update key quotas in key_put()") Reported-by: syzbot+6105ffc1ded71d194d6d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/673b6aec.050a0220.87769.004a.GAE@google.com/ Signed-off-by: David Howells Tested-by: syzbot+6105ffc1ded71d194d6d@syzkaller.appspotmail.com Reviewed-by: Oleg Nesterov Signed-off-by: Jarkko Sakkinen

perf/amd/ibs: Prevent leaking sensitive data to userspace

2025-03-22T07:18:24Z

Although IBS "swfilt" can prevent leaking samples with kernel RIP to the userspace, there are few subtle cases where a 'data' address and/or a 'branch target' address can fall under kernel address range although RIP is from userspace. Prevent leaking kernel 'data' addresses by discarding such samples when {exclude_kernel=1,swfilt=1}. IBS can now be invoked by unprivileged user with the introduction of "swfilt". However, this creates a loophole in the interface where an unprivileged user can get physical address of the userspace virtual addresses through IBS register raw dump (PERF_SAMPLE_RAW). Prevent this as well. This upstream commit fixed the most obvious leak: 65a99264f5e5 perf/x86: Check data address for IBS software filter Follow that up with a more complete fix. Fixes: d29e744c7167 ("perf/x86: Relax privilege filter restriction on AMD IBS") Suggested-by: Matteo Rizzo Co-developed-by: Ravi Bangoria Signed-off-by: Namhyung Kim Signed-off-by: Ravi Bangoria Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250321161251.1033-1-ravi.bangoria@amd.com

Merge tag 'spi-fix-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2025-03-21T21:07:40Z

Pull spi fix from Mark Brown: "This is a straightforward fix for a reference count leak in the rarely used SPI device mode functionality" * tag 'spi-fix-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: Fix reference count leak in slave_show()

Merge tag 'regulator-fix-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2025-03-21T20:42:55Z

Pull regulator fixes from Mark Brown: "More fixes than I'd like at this point, some of which is due to me cooking things in -next for a bit and resetting that cooking time as more fixes came in. - Christian Eggers fixed some race conditions with the dummy regulator not being available very early in boot due to the use of asynchronous probing, both the provider side (ensuring that it's availalbe) and consumer side (handling things if that goes wrong) are fixed - Ludvig Pärsson fixed some lockdep issues with the debugfs registration for regulators holding more locks than it really needs causing issues later when looking at the resulting debugfs.boot - Some device specific fixes for incorrect descriptions of the RTQ2208 from ChiYuan Huang" * tag 'regulator-fix-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: rtq2208: Fix the LDO DVS capability regulator: rtq2208: Fix incorrect buck converter phase mapping regulator: check that dummy regulator has been probed before using it regulator: dummy: force synchronous probing regulator: core: Fix deadlock in create_regulator()