A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability.

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:

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:

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:

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:

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:

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.

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 do sanity check on block address in f2fsdozerorange()

As Yanming reported in bugzilla:

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

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

I have uploaded the system call sequence as case.c, and a fuzzed image can be found in google net disk

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

kernel BUG at fs/f2fs/segment.c:2291! Call Trace: f2fsinvalidateblocks+0x193/0x2d0 f2fsfallocate+0x2593/0x4a70 vfsfallocate+0x2a5/0xac0 ksysfallocate+0x35/0x70 x64sysfallocate+0x8e/0xf0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae

The root cause is, after image was fuzzed, block mapping info in inode will be inconsistent with SIT table, so in f2fsfallocate(), it will cause panic when updating SIT with invalid blkaddr.

Let's fix the issue by adding sanity check on block address before updating SIT table with it.

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

mt76: fix use-after-free by removing a non-RCU wcid pointer

Fixes an issue caught by KASAN about use-after-free in mt76txqschedule by protecting mtxq-&gt;wcid with rculock between mt76txqschedule and stainfo[alloc, free].

[18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76txqschedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215

[18853.876840] Call trace: [18853.876861] dumpbacktrace+0x0/0x3ec [18853.876878] showstack+0x20/0x2c [18853.876899] dumpstack+0x11c/0x1ac [18853.876918] printaddressdescription+0x74/0x514 [18853.876934] kasanreport+0x134/0x174 [18853.876948] asanreportload8noabort+0x44/0x50 [18853.876976] mt76txqschedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76txqscheduleall+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921txworker+0xa0/0x1cc [mt7921common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] mt76workerfn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] retfromfork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasansavestack+0x38/0x68 [18853.877147] kasankmalloc+0xd4/0xfc [18853.877163] kasankmalloc+0x10/0x1c [18853.877177] kmalloc+0x264/0x3c4 [18853.877294] stainfoalloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211prepconnection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211mgdauth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211auth+0x20/0x2c [mac80211] [18853.877733] rdevauth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211mlmeauth+0x26c/0x390 [cfg80211] [18853.877919] nl80211authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genlrcvmsg+0x748/0x93c [18853.877954] netlinkrcvskb+0x160/0x2a8 [18853.877969] genlrcv+0x3c/0x54 [18853.877985] netlinkunicastkernel+0x104/0x1ec [18853.877999] netlinkunicast+0x178/0x268 [18853.878015] netlinksendmsg+0x3cc/0x5f0 [18853.878030] socksendmsg+0xb4/0xd8 [18853.878043] syssendmsg+0x2f8/0x53c [18853.878058] syssendmsg+0xe8/0x150 [18853.878071] syssendmsg+0xc4/0x1f4 [18853.878087] arm64compatsyssendmsg+0x88/0x9c [18853.878101] el0svccommon+0x1b4/0x390 [18853.878115] doel0svccompat+0x8c/0xdc [18853.878131] el0svccompat+0x10/0x1c [18853.878146] el0synccompathandler+0xa8/0xcc [18853.878161] el0synccompat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasansavestack+0x38/0x68 [18853.878215] kasansettrack+0x28/0x3c [18853.878228] kasansetfreeinfo+0x24/0x48 [18853.878244] kasanslabfree+0x11c/0x154 [18853.878259] kasanslabfree+0x14/0x24 [18853.878273] slabfreefreelisthook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] stainfofree+0x198/0x210 [mac80211] [18853.878515] stainfodestroypart2+0x230/0x2d4 [mac80211] [18853.878628] stainfoflush+0x300/0x37c [mac80211] [18853.878740] ieee80211setdisassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211mgddeauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211deauth+0x20/0x2c [mac80211] [18853.879057] rdevdeauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211mlmedeauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211mlmedown+0xe4/0x118 [cfg80211] [18853.879335] cfg80211disconnect+0x218/0x2d8 [cfg80211] [18853.879427] cfg80211leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211leave+0x3c/0x58 [cfg80211] [18853.879611] wiphysuspend+0xdc/0x200 [cfg80211] [18853.879628] dpmruncallback+0x58/0x408 [18853.879642] devicesuspend+0x4cc/0x864 [18853.879658] asyncsuspend+0x34/0xf4 [18 ---truncated---

blk-throttle: Set BIOTHROTTLED when bio has been throttled

crypto: arm64/neonbs - fix out-of-bounds access on short input

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

peci: cpu: Fix use-after-free in adevrelease()

When auxiliarydeviceadd() returns an error, auxiliarydeviceuninit() is called, which causes refcount for device to be decremented and .release callback will be triggered.

Because adevrelease() re-calls auxiliarydeviceuninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcountwarnsaturate+0x110/0x15 [ 1269.464007] refcountt: underflow; use-after-free.

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

media: amphion: Fix race between m2m jobabort and devicerun

Fix kernel panic caused by race condition where v4l2m2mctxrelease() frees m2mctx while v4l2m2mtryrun() is about to call devicerun with the same context.

Race sequence: v4l2m2mtryrun(): v4l2m2mctxrelease(): lock/unlock v4l2m2mcanceljob() jobabort() v4l2m2mjobfinish() kfree(m2mctx) <- frees ctx devicerun() <- use-after-free crash at 0x538

Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2m2mtryrun+0x78/0x138 v4l2m2mdevicerunwork+0x14/0x20

The amphion vpu driver does not rely on the m2m framework's devicerun callback to perform encode/decode operations.

Fix the race by preventing m2m framework job scheduling entirely: - Add jobready callback returning 0 (no jobs ready for m2m framework) - Remove jobabort callback to avoid the race condition

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:

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:

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:

net/rds: Fix circular locking dependency in rdstcptune

syzbot reported a circular locking dependency in rdstcptune() where sknetrefcntupgrade() is called while holding the socket lock:

====================================================== WARNING: possible circular locking dependency detected ====================================================== kworker/u10:8/15040 is trying to acquire lock: ffffffff8e9aaf80 (fsreclaim){+.+.}-{0:0}, at: kmalloccachenoprof+0x4b/0x6f0

but task is already holding lock: ffff88805a3c1ce0 (k-sklock-AFINET6){+.+.}-{0:0}, at: rdstcptune+0xd7/0x930

The issue occurs because sknetrefcntupgrade() performs memory allocation (via getnettrack() -> reftrackeralloc()) while the socket lock is held, creating a circular dependency with fsreclaim.

Fix this by moving sknetrefcntupgrade() outside the socket lock critical section. This is safe because the fields modified by the sknetrefcntupgrade() call (sknetrefcnt, nstracker) are not accessed by any concurrent code path at this point.

v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits

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

scsi: pm8001: Fix use-after-free in pm8001queuecommand()

Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001taskexec()") refactors pm8001queuecommand(), however it introduces a potential cause of a double free scenario when it changes the function to return -ENODEV in case of phy down/device gone state.

In this path, pm8001queuecommand() updates task status and calls taskdone to indicate to upper layer that the task has been handled. However, this also frees the underlying SAS task. A -ENODEV is then returned to the caller. When libsas sasataqcissue() receives this error value, it assumes the task wasn't handled/queued by LLDD and proceeds to clean up and free the task again, resulting in a double free.

Since pm8001queuecommand() handles the SAS task in this case, it should return 0 to the caller indicating that the task has been handled.

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

hisiaccvfiopci: bugfix live migration function without VF device driver

If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.

Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.

ASoC: qcom: Fix sc7280 lpass potential buffer overflow

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

vxlan: vnifilter: Fix unlocked deletion of default FDB entry

When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").

Reproducer:

# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0

Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.

[1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlancore.c:417 vxlanfindmac+0x17f/0x1a0 [...] RIP: 0010:vxlanfindmac+0x17f/0x1a0 [...] Call Trace: <TASK> vxlanfdbdelete+0xbe/0x560 vxlanvnideletegroup+0x2ba/0x940 vxlanvnidel.isra.0+0x15f/0x580 vxlanprocessvnifilter+0x38b/0x7b0 vxlanvnifilterprocess+0x3bb/0x510 rtnetlinkrcvmsg+0x2f7/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 syssendmsg+0xfc/0x180 syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53

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

irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs

On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIONOWAKEIRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs:

root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpmsettype+0x80/0xcc lr : mpmsettype+0x5c/0xcc Call trace: mpmsettype+0x80/0xcc (P) qcommpmsettype+0x64/0x158 irqchipsettypeparent+0x20/0x38 msmgpioirqsettype+0x50/0x530 irqsettrigger+0x60/0x184 setupirq+0x304/0x6bc requestthreadedirq+0xc8/0x19c edgedetectorsetup+0x260/0x364 linereqcreate+0x420/0x5a8 gpioioctl+0x2d4/0x6c0

Fix this by copying the check for GPIONOWAKEIRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs.