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.

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

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

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:

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:

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:

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:

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:

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:

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:

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:

An issue was discovered in the Linux kernel through 5.18.3 on powerpc 32-bit platforms. There is a buffer overflow in ptrace PEEKUSER and POKEUSER (aka PEEKUSR and POKEUSR) when accessing floating point registers.

A use-after-free vulnerability was found in the Linux kernel's Netfilter subsystem in net/netfilter/nftablesapi.c. This flaw allows a local attacker with user access to cause a privilege escalation issue.

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

net: phy: micrel: Fix potential null pointer dereference

In lan8814getsigrx() and lan8814getsigtx() ptpparseheader() may return NULL as ptpheader due to abnormal packet type or corrupted packet. Fix this bug by adding ptpheader check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

powerpc/pseries: Fix potential memleak in paprgetattr()

buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.

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:

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:

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.

ath11k: fix the warning of devwake in mhipmdisabletransition()

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

media: venus: hfi: avoid null dereference in deinit

If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the coredeinit function anymore.

Avoid this null pointer derefence by skipping the call when necessary.

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

arm64: compat: Do not treat syscall number as ESRELx for a bad syscall

If a compat process tries to execute an unknown system call above the ARMNRCOMPATEND number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() -> arm64showsignal().

arm64showsignal() interprets a non-zero value for current->thread.faultcode as an exception syndrome and displays the message associated with the ESRELx.EC field (bits 31:26). current->thread.faultcode is set in compatarmsyscall() -> arm64notifydie() with the bad syscall number instead of a valid ESRELx value. This means that the ESRELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages. For example, for the syscall number 0x68000000, which evaluates to ESRELx.EC value of 0x1A (ESRELxECFPAC) the kernel prints this error:

[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]

which is misleading, as the bad compat syscall has nothing to do with pointer authentication.

Stop arm64showsignal() from printing exception syndrome information by having compatarmsyscall() set the ESRELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes:

[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]

which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace.

A 32-bit value above or equal to 0x80000000 is interpreted as a negative integer in compatarmsyscal() and the condition scno < ARMNRCOMPATEND evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64notifydie() being called.

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

ath11k: disable spectral scan during spectral deinit

When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash.

Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectraldeinit API to avoid this crash.

call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11kspectralprocessdata+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11kspectralprocessdata [ath11k]) from [<7f917fdc>] (ath11kdbringbufferreleaseevent+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11kdbringbufferreleaseevent [ath11k]) from [<7f8ea3c4>] (ath11kwmitlvoprx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11kwmitlvoprx [ath11k]) from [<7f8fe868>] (ath11khtcrxcompletionhandler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11khtcrxcompletionhandler [ath11k]) from [<7f91308c>] (ath11kceperengineservice+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11kceperengineservice [ath11k]) from [<7f9a4198>] (ath11kpcicetasklet+0x28/0x80 [ath11kpci]) [ 1253.514811] [<7f9a4198>] (ath11kpcicetasklet [ath11kpci]) from [<8032227c>] (taskletactioncommon.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (taskletactioncommon.constprop.2) from [<803021e8>] (dosoftirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (dosoftirq) from [<80322610>] (irqexit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irqexit) from [<8036a4a4>] (handledomainirq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (handledomainirq) from [<805eb348>] (gichandleirq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gichandleirq) from [<80301a78>] (irqsvc+0x58/0x8c)

Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPLSILICONZ-1

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

ASoC: SOF: ipc3-topology: Correct getcontroldata for non bytes payload

It is possible to craft a topology where sofgetcontroldata() would do out of bounds access because it expects that it is only called when the payload is bytes type. Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes.

Fix the code to count the non bytes controls and instead of storing a pointer to sofabihdr in sofwidgetdata (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data.

In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end.

In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context. The data is pointing to the end of cdata struct, so it should never be null.

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

ath10k: skip ath10khalt during suspend for driver state RESTARTING

Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10kcorerestart() which calls driver clean up via ath10khalt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10kstop() which again triggers ath10khalt() The double invocation of ath10khalt() causes ath10khttrxfree() to be called twice(Note: ath10khttrxalloc was not called by restart worker thread because of its frozen state), causing the crash.

To fix this, during the suspend flow, skip call to ath10khalt() in ath10kstop() when the current driver state is ATH10KSTATERESTARTING. Also, for driver state ATH10KSTATERESTARTING, call ath10kwaitforsuspend() in ath10kstop(). This is because call to ath10kwaitforsuspend() is skipped later in [ath10khalt() > ath10kcorestop()] for the driver state ATH10KSTATERESTARTING.

The frozen restart worker thread will be cancelled during resume when the device comes out of suspend.

Below is the crash stack for reference:

[ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: eventsunbound asyncrunentryfn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dmafreeattrs+0x5f/0x7d [ 428.469320] ath10kcorestop+0x5b/0x6f [ 428.469336] ath10khalt+0x126/0x177 [ 428.469352] ath10kstop+0x41/0x7e [ 428.469387] drvstop+0x88/0x10e [ 428.469410] ieee80211suspend+0x297/0x411 [ 428.469441] rdevsuspend+0x6e/0xd0 [ 428.469462] wiphysuspend+0xb1/0x105 [ 428.469483] ? nameshow+0x2d/0x2d [ 428.469490] dpmruncallback+0x8c/0x126 [ 428.469511] ? nameshow+0x2d/0x2d [ 428.469517] devicesuspend+0x2e7/0x41b [ 428.469523] asyncsuspend+0x1f/0x93 [ 428.469529] asyncrunentryfn+0x3d/0xd1 [ 428.469535] processonework+0x1b1/0x329 [ 428.469541] workerthread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? prcontwork+0x58/0x58 [ 428.469558] ? kthreadblkcg+0x31/0x31

Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

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

f2fs: fix to avoid f2fsbugon() in decvalidnodecount()

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/showbug.cgi?id=215897

I have encountered a bug in F2FS file system in kernel v5.17.

The kernel should enable CONFIGKASAN=y and CONFIGKASANINLINE=y. You can reproduce the bug by running the following commands:

The kernel message is shown below:

kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fsremoveinodepage+0x2a2/0x830 f2fsevictinode+0x9b7/0x1510 evict+0x282/0x4e0 dounlinkat+0x33a/0x540 x64sysunlinkat+0x8e/0xd0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae

The root cause is: .totalvalidblockcount or .totalvalidnodecount could fuzzed to zero, then once decvalidnodecount() was called, it will cause BUGON(), this patch fixes to print warning info and set SBINEEDFSCK into CP instead of panic.

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

soc: ti: tiscipmdomains: Check for null return of devmkcalloc

The allocation funciton devmkcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devmkcalloc in previous code.

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

f2fs: fix to do sanity check on totaldatablocks

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/showbug.cgi?id=215916

The kernel message is shown below:

kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocatesegmentbydefault+0x228/0x440 f2fsallocatedatablock+0x13d1/0x31f0 dowritepage+0x18d/0x710 f2fsoutplacewritedata+0x151/0x250 f2fsdowritedatapage+0xef9/0x1980 movedatapage+0x6af/0xbc0 dogarbagecollect+0x312f/0x46f0 f2fsgc+0x6b0/0x3bc0 f2fsbalancefs+0x921/0x2260 f2fswritesingledatapage+0x16be/0x2370 f2fswritecachepages+0x428/0xd00 f2fswritedatapages+0x96e/0xd50 dowritepages+0x168/0x550 writebacksingleinode+0x9f/0x870 writebacksbinodes+0x47d/0xb20 writebackinodeswb+0xb2/0x200 wbwriteback+0x4bd/0x660 wbworkfn+0x5f3/0xab0 processonework+0x79f/0x13e0 workerthread+0x89/0xf60 kthread+0x26a/0x300 retfromfork+0x22/0x30 RIP: 0010:newcurseg+0xe8d/0x15f0

The root cause is: ckpt.validblockcount is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment.

So that during garbage colloection, it triggers panic when LFS allocator fails to find free segment.

This patch tries to fix this issue by checking consistency in between ckpt.validblockcount and block accounted from SIT.