In the Linux kernel, the following vulnerability has been resolved:

net: bonding: Fix ndtbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. If bonding ARP/NS validation is enabled, an IPv6 NS/NA packet received on a slave can reach bondvalidatena(), which calls bondhasthisip6(). That path calls ipv6chkaddr() and can crash in ipv6chkaddrandflags().

BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ipv6chkaddrandflags+0x69/0x170 Call Trace: <IRQ> ipv6chkaddr+0x1f/0x30 bondvalidatena+0x12e/0x1d0 [bonding] ? pfxbondhandleframe+0x10/0x10 [bonding] bondrcvvalidate+0x1a0/0x450 [bonding] bondhandleframe+0x5e/0x290 [bonding] ? srsoaliasreturnthunk+0x5/0xfbef5 netifreceiveskbcore.constprop.0+0x3e8/0xe50 ? srsoaliasreturnthunk+0x5/0xfbef5 ? updatecfsrqloadavg+0x1a/0x240 ? srsoaliasreturnthunk+0x5/0xfbef5 ? enqueueentity+0x5e/0x240 netifreceiveskbonecore+0x39/0xa0 processbacklog+0x9c/0x150 napipoll+0x30/0x200 ? srsoaliasreturnthunk+0x5/0xfbef5 netrxaction+0x338/0x3b0 handlesoftirqs+0xc9/0x2a0 dosoftirq+0x42/0x60 </IRQ> <TASK> localbhenableip+0x62/0x70 devqueuexmit+0x2d3/0x1000 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? packetparseheaders+0x10a/0x1a0 packetsendmsg+0x10da/0x1700 ? kickpool+0x5f/0x140 ? srsoaliasreturnthunk+0x5/0xfbef5 ? queuework+0x12d/0x4f0 syssendto+0x1f3/0x220 x64syssendto+0x24/0x30 dosyscall64+0x101/0xf80 ? excpagefault+0x6e/0x170 ? srsoaliasreturnthunk+0x5/0xfbef5 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this by checking ipv6modenabled() before dispatching IPv6 packets to bondnarcv(). If IPv6 is disabled, return early from bondrcvvalidate() and avoid the path to ipv6chkaddr().

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Do not skip unrelated mode changes in DSC validation

Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state modechanged flag to false when recomputing the DSC configuration results in no timing change for a particular stream.

However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the modechanged flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in prevalidatedsc().

At this point, however, dmupdatecrtcstate() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpudmcommitstreams() will never release the old stream, resulting in a memory leak. amdgpudmatomiccommittail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on:

BUG: KASAN: use-after-free in dcstreamrelease+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977

Workqueue: events drmmodermfbworkfn Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 printaddressdescription.constprop.0+0x88/0x320 ? dcstreamrelease+0x25/0x90 [amdgpu] printreport+0xfc/0x1ff ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x225/0x4e0 ? dcstreamrelease+0x25/0x90 [amdgpu] kasanreport+0xe1/0x180 ? dcstreamrelease+0x25/0x90 [amdgpu] kasancheckrange+0x125/0x200 dcstreamrelease+0x25/0x90 [amdgpu] dcstatedestruct+0x14d/0x5c0 [amdgpu] dcstaterelease.part.0+0x4e/0x130 [amdgpu] dmatomicdestroystate+0x3f/0x70 [amdgpu] drmatomicstatedefaultclear+0x8ee/0xf30 ? drmmodeobjectput.part.0+0xb1/0x130 drmatomicstatefree+0x15c/0x2d0 atomicremovefb+0x67e/0x980

Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the modechanged flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the modechanged flag to this earlier value instead in prevalidatedsc().

(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)

In the Linux kernel, the following vulnerability has been resolved:

nvmet: move async event work off nvmet-wq

For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()

C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530

Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: allow exp not to be removed in nfctfindexpectation

Currently nfconntrackin() calling nfctfindexpectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches.

This patch allows exp not to be removed by setting IPSCONFIRMED in the status of the tmpl.

In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix 'scheduling while atomic' in mptcppmnlappendnewlocaladdr

If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcppmnlappendnewlocaladdr because none found the address in localaddrlist during their call to mptcppmnlgetlocalid. In this case, the concurrent newlocaladdr calls may delete the address entry created by the previous caller. These deletes use synchronizercu, but this is not permitted in some of the contexts where this function may be called. During packet recv, the caller may be in a rcu read critical section and have preemption disabled.

An example stack:

BUG: scheduling while atomic: swapper/2/0/0x00000302

Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) dumpstack (lib/dumpstack.c:124) schedulebug (kernel/sched/core.c:5943) scheduledebug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) schedule (arch/x86/include/asm/jumplabel.h:27 include/linux/jumplabel.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) scheduletimeout (kernel/time/timer.c:2160) waitforcompletion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) waitrcugp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronizercu (kernel/rcu/tree.c:3609) mptcppmnlappendnewlocaladdr (net/mptcp/pmnetlink.c:966 net/mptcp/pmnetlink.c:1061) mptcppmnlgetlocalid (net/mptcp/pmnetlink.c:1164) mptcppmgetlocalid (net/mptcp/pm.c:420) subflowcheckreq (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflowv4routereq (net/mptcp/subflow.c:305) tcpconnrequest (net/ipv4/tcpinput.c:7216) subflowv4connrequest (net/mptcp/subflow.c:651) tcprcvstateprocess (net/ipv4/tcpinput.c:6709) tcpv4dorcv (net/ipv4/tcpipv4.c:1934) tcpv4rcv (net/ipv4/tcpipv4.c:2334) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205 (discriminator 1)) iplocaldeliverfinish (include/linux/rcupdate.h:813 net/ipv4/ipinput.c:234) iplocaldeliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ipinput.c:254) ipsublistrcvfinish (include/net/dst.h:461 net/ipv4/ipinput.c:580) ipsublistrcv (net/ipv4/ipinput.c:640) iplistrcv (net/ipv4/ipinput.c:675) netifreceiveskblistcore (net/core/dev.c:5583 net/core/dev.c:5631) netifreceiveskblistinternal (net/core/dev.c:5685 net/core/dev.c:5774) napicompletedone (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igbpoll (drivers/net/ethernet/intel/igb/igbmain.c:8244) igb napipoll (net/core/dev.c:6582) netrxaction (net/core/dev.c:6653 net/core/dev.c:6787) handlesoftirqs (kernel/softirq.c:553) irqexitrcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irqexitrcu (kernel/softirq.c:651) commoninterrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>

This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address. In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first localaddrlist entries which have the internal address instead.

Fix by skipping the replacement of an existing implicit local address if called via mptcppmnlgetlocalid.

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()

Syzkaller reported a panic in smctcpsynrecvsock() [1].

smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().

This leads to two issues:

1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriafops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheckreq() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) / No lock on listener / smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!

Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.

Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.

- Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcureadlock(). - Use rcureadlock() to protect reading skuserdata. - Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smcsock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smcsock field, so it is not affected.

Reproducer was verified with mdelay injection and smcrun, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

ext4: fix use-after-free in updatesuperwork when racing with umount

In the Linux kernel, the following vulnerability has been resolved:

mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index

The Linux kernel CVE team has assigned CVE-2024-26783 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T

In the Linux kernel, the following vulnerability has been resolved:

bpf, testrun: Fix use-after-free issue in ethskbpkttype()

KMSAN reported a use-after-free issue in ethskbpkttype()[1]. The cause of the issue was that ethskbpkttype() accessed skb's data that didn't contain an Ethernet header. This occurs when bpfprogtestrunxdp() passes an invalid value as the userdata argument to bpftestinit().

Fix this by returning an error when userdata is less than ETHHLEN in bpftestinit(). Additionally, remove the check for "if (usersize > size)" as it is unnecessary.

[1] BUG: KMSAN: use-after-free in ethskbpkttype include/linux/etherdevice.h:627 [inline] BUG: KMSAN: use-after-free in ethtypetrans+0x4ee/0x980 net/ethernet/eth.c:165 ethskbpkttype include/linux/etherdevice.h:627 [inline] ethtypetrans+0x4ee/0x980 net/ethernet/eth.c:165 xdpbuildskbfromframe+0x5a8/0xa50 net/core/xdp.c:635 xdprecvframes net/bpf/testrun.c:272 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2954/0x3330 net/bpf/testrun.c:390 bpfprogtestrunxdp+0x148e/0x1b10 net/bpf/testrun.c:1318 bpfprogtestrun+0x5b7/0xa30 kernel/bpf/syscall.c:4371 sysbpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777 dosysbpf kernel/bpf/syscall.c:5866 [inline] sesysbpf kernel/bpf/syscall.c:5864 [inline] x64sysbpf+0xa4/0xf0 kernel/bpf/syscall.c:5864 x64syscall+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: freepagesprepare mm/pagealloc.c:1056 [inline] freeunrefpage+0x156/0x1320 mm/pagealloc.c:2657 freepages+0xa3/0x1b0 mm/pagealloc.c:4838 bpfringbuffree kernel/bpf/ringbuf.c:226 [inline] ringbufmapfree+0xff/0x1e0 kernel/bpf/ringbuf.c:235 bpfmapfree kernel/bpf/syscall.c:838 [inline] bpfmapfreedeferred+0x17c/0x310 kernel/bpf/syscall.c:862 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa2b/0x1b60 kernel/workqueue.c:3310 workerthread+0xedf/0x1550 kernel/workqueue.c:3391 kthread+0x535/0x6b0 kernel/kthread.c:389 retfromfork+0x6e/0x90 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:

mm/pagealloc: clear page->private in freepagesprepare()

Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via splitpage(), tail pages retain stale page->private values.

This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swapcountcontinued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LISTPOISON values, causing a crash:

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:dosysswapoff+0x1151/0x1860

Fix this by clearing page->private in freepagesprepare(), ensuring all freed pages have clean state regardless of previous use.

In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only set fullmesh for subflow endp

With the in-kernel path-manager, it is possible to change the 'fullmesh' flag. The code in mptcppmnlfullmesh() expects to change it only on 'subflow' endpoints, to recreate more or less subflows using the linked address.

Unfortunately, the setflags() hook was a bit more permissive, and allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not allowed before.

That's what syzbot found, triggering the following warning:

WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 marksubflowendpavailable net/mptcp/pmnetlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcppmnlfullmesh net/mptcp/pmnetlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcpnlsetflags net/mptcp/pmnetlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pmnetlink.c:1496 mptcppmnlsetflags+0x974/0xdc0 net/mptcp/pmnetlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:marksubflowendpavailable net/mptcp/pmnetlink.c:1496 [inline] RIP: 0010:mptcppmnlfullmesh net/mptcp/pmnetlink.c:1980 [inline] RIP: 0010:mptcpnlsetflags net/mptcp/pmnetlink.c:2003 [inline] RIP: 0010:mptcppmnlsetflags+0x974/0xdc0 net/mptcp/pmnetlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48 RSP: 0018:ffffc9000d307240 EFLAGS: 00010293 RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0 R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2542 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 syssendmsg net/socket.c:2637 [inline] syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5fe8785d29 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:00007fff571f5558 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007 RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000 ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix potential for tearing in ->remoteisize and ->zeropoint

Fix potential tearing in using ->remoteisize and ->zeropoint by copying isizeread() and isizewrite() and using the same seqcount as for isize.

We need to make sure that netfslib and the filesystems that use it always hold ilock whilst updating any of the sizes to prevent isizeseqcount from getting corrupted.

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs: check contexts->nr before accessing contextsarr[0]

Multiple sysfs command paths dereference contextsarr[0] without first verifying that kdamond->contexts->nr == 1. A user can set nrcontexts to 0 via sysfs while DAMON is running, causing NULL pointer dereferences.

In more detail, the issue can be triggered by privileged users like below.

First, start DAMON and make contexts directory empty (kdamond->contexts->nr == 0).

# damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/nrcontexts

Then, each of below commands will cause the NULL pointer dereference.

# echo updateschemesstats > state # echo updateschemestriedregions > state # echo updateschemestriedbytes > state # echo updateschemeseffectivequotas > state # echo updatetunedintervals > state

Guard all commands (except OFF) at the entry point of damonsysfshandlecmd().

In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject sleepable kprobemulti programs at attach time

kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpfkprobemultilinkattach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpfcopyfromuser() to be invoked from a non-sleepable context.

This causes a "sleeping function called from invalid context" splat:

BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 1787, name: sudo preemptcount: 1, expected: 0 RCU nest depth: 2, expected: 0

Fix this by rejecting sleepable programs early in bpfkprobemultilinkattach(), before any further processing.

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: fix NULL pointer dereference during unbind race

Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown") introduced two stages of synchronization waits totaling 1500ms in uvcfunctionunbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions.

When the PM subsystem starts freezing user space processes, the waiteventinterruptibletimeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL):

[ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind no clean disconnect, wait for release

When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic:

[ 814.292597][ C0] PM: pmsystemirqwakeup: 479 triggered dhdpciehostwake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usbgadgetdeactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usbfunctiondeactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usbgadgetdeactivate+0x14/0xf4 [ 814.404083][ T4558] usbfunctiondeactivate+0x54/0x94 [ 814.404087][ T4558] uvcfunctiondisconnect+0x1c/0x5c [ 814.404092][ T4558] uvcv4l2release+0x44/0xac [ 814.404095][ T4558] v4l2release+0xcc/0x130

Address the race condition and NULL pointer dereference by:

1. State Synchronization (flag + mutex) Introduce a 'funcunbound' flag in struct uvcdevice. This allows uvcfunctiondisconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'funcconnected' for consistent state management.

2. Explicit Synchronization (completion) Use a completion to synchronize uvcfunctionunbind() with the uvcvdevrelease() callback. This prevents Use-After-Free (UAF) by ensuring struct uvcdevice is freed after all video device resources are released.

In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: CGX: fix bitmap leaks

The RX/TX flow-control bitmaps (rxfcpfvfbmap and txfcpfvfbmap) are allocated by cgxlmacinit() but never freed in cgxlmacexit(). Unbinding and rebinding the driver therefore triggers kmemleak:

unreferenced object (size 16): backtrace: rvuallocbitmap cgxprobe

Free both bitmaps during teardown.

In the Linux kernel, the following vulnerability has been resolved:

media: qcom: camss: vfe: Fix out-of-bounds access in vfeisrregupdate()

vfeisr() iterates using MSMVFEIMAGEMASTERSNUM(7) as the loop bound and passes the index to vfeisrregupdate(). However, vfe->line[] array is defined with VFELINENUMMAX(4):

struct vfeline line[VFELINENUMMAX];

When index is 4, 5, 6, the access to vfe->line[lineid] exceeds the array bounds and resulting in out-of-bounds memory access.

Fix this by using separate loops for output lines and write masters.

In the Linux kernel, the following vulnerability has been resolved:

mctp: i2c: fix skb memory leak in receive path

When 'midev->allowrx' is false, the newly allocated skb isn't consumed by netifrx(), it needs to free the skb directly.

In the Linux kernel, the following vulnerability has been resolved:

xdp: produce a warning when calculated tailroom is negative

Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpfxdpfragsincreasetail(), clearly expects a truesize.

Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDPADJUSTTAILGROWMULTIBUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->fragsize was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset.

We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINTMAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces.

[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookupswapcgroupid+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaffrompte+0x77/0xa0 [ 7340.422855] swapptebatch+0xa7/0x290 [ 7340.423363] zapnonpresentptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zappterange+0x281/0x580 [ 7340.424607] zappmdrange.isra.0+0xc9/0x240 [ 7340.425177] unmappagerange+0x24d/0x420 [ 7340.425714] unmapvmas+0xa1/0x180 [ 7340.426185] exitmmap+0xe1/0x3b0 [ 7340.426644] mmput+0x41/0x150 [ 7340.427098] exitmm+0xb1/0x110 [ 7340.427539] doexit+0x1b2/0x460 [ 7340.427992] dogroupexit+0x2d/0xc0 [ 7340.428477] getsignal+0x79d/0x7e0 [ 7340.428957] archdosignalorrestart+0x34/0x100 [ 7340.429571] exittousermodeloop+0x8e/0x4c0 [ 7340.430159] dosyscall64+0x188/ ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for example qat4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat4xxx.ko) is unloaded, while the core driver (intelqat.ko) remains loaded.

Since the driver uses a shared workqueue (qatmiscwq) across all devices and owned by intelqat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:

BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pmbhhandler+0x1d2/0x250 [intelqat] Call Trace: pmbhhandler+0x1d2/0x250 [intelqat] processonework+0x171/0x340 workerthread+0x277/0x3a0 kthread+0xf0/0x120 retfromfork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.

Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Use trycmpxchguser() to update guest PTE A/D bits

Use the recently introduced trycmpxchguser() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VMPFNMAP path is broken as it assumes that vmpgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vmpgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing "random" pfns for pretty much any other VMPFNMAP case.

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: Fix memory leak after mt76connacmcuallocstareq()

mt76connacmcuallocstareq() allocates an skb which is expected to be freed eventually by mt76mcuskbsendmsg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked.

Specifically, mt76connacmcustawedupdate() and mt76connacmcustakeytlv() may fail, leading to an immediate memory leak in the error path.

Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996mcustakeytlv error") made a similar change.

Compile tested only. Issue found using a prototype static analysis tool and code review.

In the Linux kernel, the following vulnerability has been resolved:

rpmsg: char: Fix use-after-free on probe error path

rpmsgchrdevprobe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsgchrdeveptdevadd(). If rpmsgchrdeveptdevadd() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer.

Avoid publishing eptdev through the default endpoint until rpmsgchrdeveptdevadd() succeeds. Messages received before the priv pointer is published should be ignored by rpmsgeptcb(). Flow-control updates can hit rpmsgeptflowcb() in the same window, so make both callbacks return success when priv is NULL.

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix sleep-inside-lock in smcsetsockopt() causing local DoS

A logic flaw in smcsetsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely.

The function smcsetsockopt() calls copyfromsockptr() while holding locksock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held.

Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog.

[ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smcshutdown+... [ 240.123512] locksocknested+...

This patch moves the user-space copy outside the locksock() critical section to prevent the issue.

drm/panfrost: Job should reference MMU not filepriv

In the Linux kernel, the following vulnerability has been resolved:

powerpc/time: Remove redundant preemptdisable|enable() calls from archirqworkraise()

A kernel panic is observed when handling machine check exceptions from real mode.

BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] archirqworkraise+0x10/0x70 LR [c00000000003ffc8] machinecheckqueueevent+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machinecheckqueueevent+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machinecheckearlycommon+0x1f0/0x2c0

The crash occurs because archirqworkraise() calls preemptdisable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preemptcount can fault, leading to the panic.

The preemptdisable()/preemptenable() pair in archirqworkraise() was originally added by commit 0fe1ac48bef0 ("powerpc/perfevent: Fix oops due to perfeventdopending call") to avoid races while raising irq work from exception context.

Later, commit 471ba0e686cb ("irqwork: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irqworkqueue() path, while commit 20b876918c06 ("irqwork: Use per cpu atomics instead of regular atomics") added equivalent protection in irqworkqueueon() before reaching archirqworkraise():

irqworkqueue() / irqworkqueueon() -> preemptdisable() -> irqworkqueuelocal() -> irqworkraise() -> archirqworkraise()

As a result, callers other than mceirqworkraise() already execute with preemption disabled, making the additional preemptdisable()/preemptenable() pair in archirqworkraise() redundant.

The archirqworkraise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preemptdisable()/preemptenable() calls from here.

Remove it to avoid accessing preemptcount from real mode context.

[Maddy: Fixed the commit title]

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix leak of request in netfswritebegin() error handling

Fix netfswritebegin() to not leak our ref on the request in the event that we get an error from netfswaitforread().

In the Linux kernel, the following vulnerability has been resolved:

In the Linux kernel, the following vulnerability has been resolved:

mm/memory-failure: fix hugetlblock AA deadlock in gethugepageforhwpoison

Two concurrent madvise(MADVHWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlblock when racing with a concurrent unmap:

thread#0 thread#1 -------- -------- madvise(folio, MADVHWPOISON) -> poisons the folio successfully madvise(folio, MADVHWPOISON) unmap(folio) trymemoryfailurehugetlb gethugepageforhwpoison spinlockirq(&hugetlblock) <- held gethugepageforhwpoison hugetlbupdatehwpoison() -> MFHUGETLBFOLIOPREPOISONED goto out: folioput() refcount: 1 -> 0 freehugefolio() spinlockirqsave(&hugetlblock) -> AA DEADLOCK!

The out: path in gethugepageforhwpoison() calls folioput() to drop the GUP reference while the hugetlblock is still held by the hugetlb.c wrapper gethugepageforhwpoison(). If concurrent unmap has released the page table mapping reference, folioput() drops the folio refcount to zero, triggering freehugefolio() which attempts to re-acquire the non-recursive hugetlblock.

Fix this by moving hugetlblock acquisition from the hugetlb.c wrapper into gethugepageforhwpoison(). Place spinunlockirq() before the folioput() at the out: label so the folio is always released outside the lock.

[akpm@linux-foundation.org: fix race, rename label per Miaohe]