The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ntbhwswitchtec: Fix shift-out-of-bounds in switchtecntbmwsettrans

There is a kernel API ntbmwcleartrans() would pass 0 to both addr and size. This would make xlatepos negative.

[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntbhwswitchtec.c:293:7 [ 23.734418] shift exponent -1 is negative

Ensuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)

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

drm/msm/gem: prevent integer overflow in msmioctlgem_submit()

The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32 values that come from the user via the submitlookupcmds() function. This addition could lead to an integer wrapping bug so use size_add() to prevent that.

Patchwork: https://patchwork.freedesktop.org/patch/624696/(CVE-2024-52559)

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

fs/ntfs3: Mark inode as bad as soon as error detected in mienumattr()

Extended the mi_enum_attr() function interface with an additional parameter, struct ntfs_inode *ni, to allow marking the inode as bad as soon as an error is detected.(CVE-2024-52560)

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

crypto: qat/qat4xxx - fix off by one in uofget_name()

The fwobjs[] array has "numobjs" elements so the > needs to be >= to prevent an out of bounds read.(CVE-2024-53162)

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

smb: client: fix use-after-free of signing key

Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:

task A task B cifsmount() dfsmountshare() getsession() cifsmountgetsession() cifssendrecv() cifsgetsmbses() compoundsendrecv() cifssetupsession() smb2setuprequest() kfreesensitive() smb2calcsignature() cryptoshash_setkey() UAF

Fix this by ensuring that we have a valid @ses->authkey.response by checking whether @ses->sesstatus is SESGOOD or SESEXITING with @ses->seslock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2reconnectserver()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->authkey.response), so it's safe to access signing key when @ses->sesstatus == SESEXITING.(CVE-2024-53179)

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

scsi: ufs: bsg: Set bsg_queue to NULL after removal

Currently, this does not cause any issues, but I believe it is necessary to set bsg_queue to NULL after removing it to prevent potential use-after-free (UAF) access.(CVE-2024-54458)

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

KVM: x86: Play nice with protected guests in completehypercallexit()

Use is64bithypercall() instead of is64bitmode() to detect a 64-bit hypercall when completing said hypercall. For guests with protected state, e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bit mode as the vCPU state needed to detect 64-bit mode is unavailable.

Hacking the sevsmoketest selftest to generate a KVMHCMAPGPARANGE hypercall via VMGEXIT trips the WARN:

------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 completehypercallexit+0x44/0xe0 [kvm] Modules linked in: kvmamd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sevsmoketest Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:completehypercallexit+0x44/0xe0 [kvm] Call Trace: <TASK> kvmarchvcpuioctlrun+0x2400/0x2720 [kvm] kvmvcpuioctl+0x54f/0x630 [kvm] _sesysioctl+0x6b/0xc0 dosyscall64+0x83/0x160 entrySYSCALL64afterhwframe+0x76/0x7e </TASK> ---[ end trace 0000000000000000 ]---(CVE-2024-55881)

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

drm/dp_mst: Fix MST sideband message body length check

Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message.

This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drmdpsidebandappendpayload() and the following errors in dmesg:

UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drmdpmsttopology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drmdpsidebandappendpayload+0x33d/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 [drmdisplayhelper]

memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drmdpmsttopology.c:791 (size 256) Call Trace: drmdpsidebandappendpayload+0x324/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 drmdisplayhelper

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

bpf, sockmap: Fix race between element replace and close()

Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. _sockmap_delete() unconditionally unrefs the (wrong) element:

// set map[0] = s0 mapupdateelem(map, 0, s0)

// drop fd of s0 close(s0) sockmapclose() locksock(sk) (s0!) sockmapremovelinks(sk) link = skpsocklinkpop() sockmapunlink(sk, link) sockmapdeletefromlink // replace map[0] with s1 mapupdateelem(map, 0, s1) sockmapupdateelem (s1!) locksock(sk) sockmapupdatecommon psock = skpsock(sk) spinlock(&stab->lock) osk = stab->sks[idx] sockmapaddlink(..., &stab->sks[idx]) sockmapunref(osk, &stab->sks[idx]) psock = skpsock(osk) skpsockput(sk, psock) if (refcountdecandtest(&psock)) skpsockdrop(sk, psock) spinunlock(&stab->lock) unlocksock(sk) _sockmapdelete spinlock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sktest || sktest == sk) // sktest (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sockmapunref(sk, psk) // unref s1; sks[idx] will dangle psock = skpsock(sk) skpsockput(sk, psock) if (refcountdecandtest()) skpsockdrop(sk, psock) spinunlock(&stab->lock) releasesock(sk)

Then close(map) enqueues bpfmapfreedeferred, which finally calls sockmapfree(). This results in some refcountt warnings along with a KASAN splat [1].

Fix _sockmapdelete(), do not allow sockmap_unref() on elements that may have been replaced.

Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063

CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: eventsunbound bpfmapfreedeferred Call Trace: <TASK> dumpstacklvl+0x68/0x90 printreport+0x174/0x4f6 kasanreport+0xb9/0x190 kasancheckrange+0x10f/0x1e0 sockmapfree+0x10e/0x330 bpfmapfreedeferred+0x173/0x320 processonework+0x846/0x1420 workerthread+0x5b3/0xf80 kthread+0x29e/0x360 retfromfork+0x2d/0x70 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 1202: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 _kasanslaballoc+0x85/0x90 kmemcacheallocnoprof+0x131/0x450 skprotalloc+0x5b/0x220 skalloc+0x2c/0x870 unixcreate1+0x88/0x8a0 unixcreate+0xc5/0x180 _sockcreate+0x241/0x650 _syssocketpair+0x1ce/0x420 _x64syssocketpair+0x92/0x100 dosyscall64+0x93/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 46: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 _kasanslabfree+0x4b/0x70 kmemcachefree+0x1a1/0x590 _skdestruct+0x388/0x5a0 skpsockdestroy+0x73e/0xa50 processonework+0x846/0x1420 workerthread+0x5b3/0xf80 kthread+0x29e/0x360 retfromfork+0x2d/0x70 retfromforkasm+0x1a/0x30

The bu ---truncated---(CVE-2024-56664)

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

ceph: fix memory leak in cephdirectread_write()

The bvecs array which is allocated in itergetbvecsalloc() is leaked and pages remain pinned if cephallocsparseext_map() fails.

There is no need to delay the allocation of sparseext map until after the bvecs array is set up, so fix this by moving sparseext allocation a bit earlier. Also, make a similar adjustment in _cephsyncread() for consistency (a leak of the same kind in _cephsyncread() has been addressed differently).(CVE-2024-56710)

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

RDMA/rxe: Remove the direct link to net_device

The similar patch in siw is in the link: https://git.kernel.org/rdma/rdma/c/16b87037b48889

This problem also occurred in RXE. The following analyze this problem. In the following Call Traces: " BUG: KASAN: slab-use-after-free in devgetflags+0x188/0x1d0 net/core/dev.c:8782 Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295

CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted 6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: infiniband ibcacheeventtask Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 devgetflags+0x188/0x1d0 net/core/dev.c:8782 rxequeryport+0x12d/0x260 drivers/infiniband/sw/rxe/rxeverbs.c:60 _ibqueryport drivers/infiniband/core/device.c:2111 [inline] ibqueryport+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ibcacheupdate+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ibcacheeventtask+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa65/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> "

1). In the link [1],

" infiniband syz2: set down "

This means that on 839.350575, the event ibcacheeventtask was sent andi queued in ibwq.

2). In the link [1],

" team0 (unregistering): Port device teamslave0 removed "

It indicates that before 843.251853, the net device should be freed.

3). In the link [1],

" BUG: KASAN: slab-use-after-free in devgetflags+0x188/0x1d0 "

This means that on 850.559070, this slab-use-after-free problem occurred.

In all, on 839.350575, the event ibcacheeventtask was sent and queued in ibwq,

before 843.251853, the net device veth was freed.

on 850.559070, this event was executed, and the mentioned freed net device was called. Thus, the above call trace occurred.

[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000(CVE-2024-57795)

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

RDMA/siw: Remove direct link to net_device

Do not manage a per device direct link to netdevice. Rely on associated ibdevices netdevice management, not doubling the effort locally. A badly managed local link to netdevice was causing a 'KASAN: slab-use-after-free' exception during siwqueryport() call.(CVE-2024-57857)

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

iio: imu: kmx61: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57908)

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

iio: dummy: iiosimplydummy_buffer: fix information leak in triggered buffer

The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)

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

iio: pressure: zpa2326: fix information leak in triggered buffer

The 'sample' local struct is used to push data to user space from a triggered buffer, but it has a hole between the temperature and the timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp). This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57912)

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

dm array: fix releasing a faulty array block twice in dmarraycursor_end

When dmbmreadlock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dmbmreadlock() should not operate on this invalid dmblock pointer, or it will lead to undefined result. For example, the dmarraycursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double release in dmarraycursorend(), then hitting the BUGON in dm-bufio cacheput().

Reproduce steps:

1. initialize a cache device

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

2. wipe the second array block offline

dmsteup remove cache cmeta cdata corig mappingroot=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mappingroot+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock

3. try reopen the cache device

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

Kernel logs:

(snip) device-mapper: array: arrayblockcheck failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: getablock failed device-mapper: cache metadata: dmarraycursornext for mapping failed ------------[ cut here ]------------ kernel BUG at drivers/md/dm-bufio.c:638!

Fix by setting the cached block pointer to NULL on errors.

In addition to the reproducer described above, this fix can be verified using the "arraycursor/damaged" test in dm-unit: dm-unit run /pdata/arraycursor/damaged --kernel-dir <KERNEL_DIR>(CVE-2024-57929)

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

Revert "libfs: fix infinite directory reads for offset dir"

The current directory offset allocator (based on mtreealloccyclic) stores the next offset value to return in octx->next_offset. This mechanism typically returns values that increase monotonically over time. Eventually, though, the newly allocated offset value wraps back to a low number (say, 2) which is smaller than other already- allocated offset values.

Yu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir"), if a directory's offset allocator wraps, existing entries are no longer visible via readdir/getdents because offsetreaddir() stops listing entries once an entry's offset is larger than octx->nextoffset. These entries vanish persistently -- they can be looked up, but will never again appear in readdir(3) output.

The reason for this is that the commit treats directory offsets as monotonically increasing integer values rather than opaque cookies, and introduces this comparison:

if (dentry2offset(dentry) >= last_index) {

On 64-bit platforms, the directory offset value upper bound is 2^63 - 1. Directory offsets will monotonically increase for millions of years without wrapping.

On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator can wrap after only a few weeks (at worst).

Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir") to prepare for a fix that can work properly on 32-bit systems and might apply to recent LTS kernels where shmem employs the simple_offset mechanism.(CVE-2024-57952)

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

netsched: schsfq: don't allow 1 packet limit

The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well.

This fixes the following syzkaller reported crash:

UBSAN: array-index-out-of-bounds in net/sched/schsfq.c:210:6 index 65535 is out of range for type 'struct sfqhead[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: _dumpstack lib/dumpstack.c:79 [inline] dumpstack+0x125/0x19f lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:148 [inline] _ubsanhandleoutofbounds+0xed/0x120 lib/ubsan.c:347 sfqlink net/sched/schsfq.c:210 [inline] sfqdec+0x528/0x600 net/sched/schsfq.c:238 sfqdequeue+0x39b/0x9d0 net/sched/schsfq.c:500 sfqreset+0x13/0x50 net/sched/schsfq.c:525 qdiscreset+0xfe/0x510 net/sched/schgeneric.c:1026 tbfreset+0x3d/0x100 net/sched/schtbf.c:319 qdiscreset+0xfe/0x510 net/sched/schgeneric.c:1026 devresetqueue+0x8c/0x140 net/sched/schgeneric.c:1296 netdevforeachtxqueue include/linux/netdevice.h:2350 [inline] devdeactivatemany+0x6dc/0xc20 net/sched/schgeneric.c:1362 _devclosemany+0x214/0x350 net/core/dev.c:1468 devclosemany+0x207/0x510 net/core/dev.c:1506 unregisternetdevicemany+0x40f/0x16b0 net/core/dev.c:10738 unregisternetdevicequeue+0x2be/0x310 net/core/dev.c:10695 unregisternetdevice include/linux/netdevice.h:2893 [inline] _tundetach+0x6b6/0x1600 drivers/net/tun.c:689 tundetach drivers/net/tun.c:705 [inline] tunchrclose+0x104/0x1b0 drivers/net/tun.c:3640 _fput+0x203/0x840 fs/filetable.c:280 taskworkrun+0x129/0x1b0 kernel/taskwork.c:185 exittaskwork include/linux/taskwork.h:33 [inline] doexit+0x5ce/0x2200 kernel/exit.c:931 dogroupexit+0x144/0x310 kernel/exit.c:1046 _dosysexitgroup kernel/exit.c:1057 [inline] _sesysexitgroup kernel/exit.c:1055 [inline] _x64sysexitgroup+0x3b/0x40 kernel/exit.c:1055 dosyscall64+0x6c/0xd0 entrySYSCALL64afterhwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270

The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1):

tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1

Scenario that triggers the crash:

• the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1

• TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.

• the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.

At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access.(CVE-2024-57996)

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

powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW

Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.

These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.

The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below

BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: afpacket rfkill ibmveth(X) lpfc(+) nvmetfc nvmet nvmekeyring crct10difvpmsum nvmefc nvmefabrics nvmecore be2net(+) nvmeauth rtcgeneric nfsd authrpcgss nfsacl lockd grace sunrpc fuse configfs iptables xtables xfs libcrc32c dmservicetime ibmvfc(X) scsitransportfc vmxcrypto gf128mul crc32cvpmsum dmmirror dmregionhash dmlog dmmultipath dmmod sdmod scsidhemc scsidhrdac scsidhalua t10pi crc64rocksoftgeneric crc64rocksoft sg crc64 scsimod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950149) hv:phyp pSeries Workqueue: events workforcpufn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommutablereservepages+0xac/0x100 LR [c00000000005e830] iommuinittable+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommuinittable+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommubypasssupportedpSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dmaiommudmasupported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dmasupported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dmasetmask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] beprobe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] localpciprobe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] workforcpufn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] processonework+0x314/0x620 [c00001400c9fff10] [c00000000018f280] workerthread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] startkernelthread+0x14/0x18

There are 2 issues in the code

1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap.

2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.(CVE-2024-57999)

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

media: uvcvideo: Remove dangling pointers

When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future.

If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use.

Clean all the dangling pointers during release().

To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.(CVE-2024-58002)

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

media: i2c: ds90ub9x3: Fix extra fwnodehandleput()

The ub913 and ub953 drivers call fwnodehandleput(priv->sd.fwnode) as part of their remove process, and if the driver is removed multiple times, eventually leads to put "overflow", possibly causing memory corruption or crash.

The fwnodehandleput() is a leftover from commit 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching"), which changed the code related to the sd.fwnode, but missed removing these fwnodehandleput() calls.(CVE-2024-58003)

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

soc: qcom: socinfo: Avoid out of bounds read of serial number

On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always:

db410c:/sys/devices/soc0$ cat serial_number 2644893864

The firmware used on MSM8916 exposes SOCINFOVERSION(0, 8), which does not have support for the serialnum field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the itemsize returned by SMEM, we need to make sure the *end* of the serialnum is within bounds, instead of comparing with the start offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM.

Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.(CVE-2024-58007)

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

Bluetooth: L2CAP: handle NULL sock pointer in l2capsockalloc

A NULL sock pointer is passed into l2capsockalloc() when it is called from l2capsocknewconnectioncb() and the error handling paths should also be aware of it.

Seemingly a more elegant solution would be to swap btsockalloc() and l2capchancreate() calls since they are not interdependent to that moment but then l2capchancreate() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2024-58009)

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

platform/x86: int3472: Check for adev == NULL

Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs.

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in sklint3472getacpibuffer().(CVE-2024-58011)

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

Bluetooth: MGMT: Fix slab-use-after-free Read in mgmtremoveadvmonitorsync

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961

CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 hcicmdsyncwork+0x22b/0x400 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Allocated by task 16026: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kzallocnoprof include/linux/slab.h:1037 [inline] mgmtpendingnew+0x65/0x250 net/bluetooth/mgmtutil.c:269 mgmtpendingadd+0x36/0x120 net/bluetooth/mgmtutil.c:296 removeadvmonitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 hcimgmtcmd+0xc47/0x11d0 net/bluetooth/hcisock.c:1712 hcisocksendmsg+0x7b8/0x11c0 net/bluetooth/hcisock.c:1832 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x221/0x270 net/socket.c:726 sockwriteiter+0x2d7/0x3f0 net/socket.c:1147 newsyncwrite fs/readwrite.c:586 [inline] vfswrite+0xaeb/0xd30 fs/readwrite.c:679 ksyswrite+0x18f/0x2b0 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Freed by task 16022: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:582 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2338 [inline] slabfree mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746 mgmtpendingforeach+0xd1/0x130 net/bluetooth/mgmtutil.c:259 _mgmtpoweroff+0x183/0x430 net/bluetooth/mgmt.c:9550 hcidevclosesync+0x6c4/0x11c0 net/bluetooth/hcisync.c:5208 hcidevdoclose net/bluetooth/hcicore.c:483 [inline] hcidevclose+0x112/0x210 net/bluetooth/hcicore.c:508 sockdoioctl+0x158/0x460 net/socket.c:1209 sockioctl+0x626/0x8e0 net/socket.c:1328 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:906 [inline] _sesysioctl+0xf5/0x170 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-58013)

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

wifi: brcmsmac: add gain range check to wlcphyiqcalgainparamsnphy()

In 'wlcphyiqcalgainparamsnphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbliqcalgainparams_nphy' access. Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-58014)

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

safesetid: check size of policy writes

syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handlepolicyupdate(), triggering a warning in kmalloc.

Check the size specified for write buffers before allocating.

PM: subject tweak

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

printk: Fix signed integer overflow when defining LOGBUFLEN_MAX

Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior.

This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.(CVE-2024-58017)

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

clk: qcom: gcc-sm6350: Add missing parent_map for two clocks

If a clkrcg2 has a parent, it should also have parentmap defined, otherwise we'll get a NULL pointer dereference when calling clksetrate like the following:

[ 3.388105] Call trace: [ 3.390664] qcomfindsrcindex+0x3c/0x70 (P) [ 3.395301] qcomfindsrcindex+0x1c/0x70 (L) [ 3.399934] freqtbldeterminerate+0x48/0x100 [ 3.404753] clkrcg2determinerate+0x1c/0x28 [ 3.409387] clkcoredetermineroundnolock+0x58/0xe4 [ 3.421414] clkcoreroundratenolock+0x48/0xfc [ 3.432974] clkcoreroundratenolock+0xd0/0xfc [ 3.444483] clkcoresetratenolock+0x8c/0x300 [ 3.455886] clkset_rate+0x38/0x14c

Add the parentmap property for two clocks where it's missing and also un-inline the parentdata as well to keep the matching parentmap and parentdata together.(CVE-2024-58076)

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

media: uvcvideo: Fix crash during unbind if gpio unit is in use

We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device.

If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled.

If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS.

We cannot use the function devmrequestthreadedirq here. The devm* clean functions may be called after the main structure is released by uvc_delete.

Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.(CVE-2024-58079)

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

KVM: Explicitly verify target vCPU is online in kvmgetvcpu()

Explicitly verify the target vCPU is fully online prior to clamping the index in kvmgetvcpu(). If the index is "bad", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL.

In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor.

However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")), i.e. before vCPU creation is guaranteed to succeed.

As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvmvmioctlcreatevcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 ("KVM: Fix vcpuarray[0] races") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpuarray[0] UAF race.(CVE-2024-58083)

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

drm/v3d: Stop active perfmon if it is being destroyed

If the active performance monitor (v3d->active_perfmon) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the v3d->active_perfmon pointer stale. This can lead to undefined behavior and instability.

This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").(CVE-2024-58086)

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

bpf: Fix deadlock when freeing cgroup storage

The following commit bc235cdb423a ("bpf: Prevent deadlock from recursive bpftaskstorage[get|delete]") first introduced deadlock prevention for fentry/fexit programs attaching on bpftask_storage helpers. That commit also employed the logic in map free path in its v6 version.

Later bpfcgrpstorage was first introduced in c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs") which faces the same issue as bpftaskstorage, instead of its busy counter, NULL was passed to bpflocalstoragemapfree() which opened a window to cause deadlock:

<TASK>
    (acquiring local_storage->lock)
_raw_spin_lock_irqsave+0x3d/0x50
bpf_local_storage_update+0xd1/0x460
bpf_cgrp_storage_get+0x109/0x130
bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
? __bpf_prog_enter_recur+0x16/0x80
bpf_trampoline_6442485186+0x43/0xa4
cgroup_storage_ptr+0x9/0x20
    (holding local_storage->lock)
bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
bpf_selem_unlink_storage+0x6f/0x110
bpf_local_storage_map_free+0xa2/0x110
bpf_map_free_deferred+0x5b/0x90
process_one_work+0x17c/0x390
worker_thread+0x251/0x360
kthread+0xd2/0x100
ret_from_fork+0x34/0x50
ret_from_fork_asm+0x1a/0x30
</TASK>

Progs: - A: SEC("fentry/cgroupstorageptr") - cgid (BPFMAPTYPEHASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPFMAPTYPECGRPSTORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpfcgroupfromid(). This trusted pointer can then be passed to bpfcgrpstorageget() to finally trigger the deadlock issue. - B: SEC("tpbtf/sysenter") - cgrpb (BPFMAPTYPECGRPSTORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpfcgrpstorageget() for as many userspace tasks as possible.

Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; }

Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking.(CVE-2024-58088)

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

sched/core: Prevent rescheduling when interrupts are disabled

David reported a warning observed while loop testing kexec jump:

Interrupts enabled after irqrouterresume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscoreresume+0x18a/0x220 kernelkexec+0xf6/0x180 _dosysreboot+0x206/0x250 dosyscall64+0x95/0x180

The corresponding interrupt flag trace:

hardirqs last enabled at (15573): [<ffffffffa8281b8e>] _upconsolesem+0x7e/0x90 hardirqs last disabled at (15580): [<ffffffffa8281b73>] _upconsolesem+0x63/0x90

That means _upconsolesem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscoresuspend() callbacks woke up a task, which set the NEEDRESCHED flag. A later callback in the resume path invoked condresched() which in turn led to the invocation of the scheduler:

_condresched+0x21/0x60 downtimeout+0x18/0x60 acpioswaitsemaphore+0x4c/0x80 acpiutacquiremutex+0x3d/0x100 acpinsgetnode+0x27/0x60 acpinsevaluate+0x1cb/0x2d0 acpirssetsrsmethoddata+0x156/0x190 acpipcilinkset+0x11c/0x290 irqrouterresume+0x54/0x60 syscoreresume+0x6a/0x200 kernelkexec+0x145/0x1c0 _dosysreboot+0xeb/0x240 dosyscall64+0x95/0x180

This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEEDRESCHED flag. condresched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end.

Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time.

The problem only affects the PREEMPTNONE and PREEMPTVOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account.

Cure the problem by adding a corresponding check into cond_resched().(CVE-2024-58090)

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

sctp: sysctl: plpmtudprobeinterval: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.probe_interval' is used.(CVE-2025-21636)

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

sctp: sysctl: udp_port: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure.(CVE-2025-21637)

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

sctp: sysctl: auth_enable: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure.(CVE-2025-21638)

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

sctp: sysctl: cookiehmacalg: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.sctphmacalg' is used.(CVE-2025-21640)

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

filemap: avoid truncating 64-bit offset to 32 bits

On 32-bit kernels, folioseekhole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem.(CVE-2025-21665)

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

vsock: prevent null-ptr-deref in vsock*[hasdata|has_space]

Recent reports have shown how we sometimes call vsock*has_data() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't.

Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning.

This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems.(CVE-2025-21666)

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

vsock/virtio: discard packets if the transport changes

If the socket has been de-assigned or assigned to another transport, we must discard any packets received because they are not expected and would cause issues when we access vsk->transport.

A possible scenario is described by Hyunwoo Kim in the attached link, where after a first connect() interrupted by a signal, and a second connect() failed, we can find vsk->transport at NULL, leading to a NULL pointer dereference.(CVE-2025-21669)

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

net/mlx5: Clear port select structure when fail to create

Clear the port select structure on error so no stale values left after definers are destroyed. That's because the mlx5lagdestroydefiners() always try to destroy all lag definers in the ttmap, so in the flow below lag definers get double-destroyed and cause kernel crash:

mlx5lagportselcreate() mlx5lagcreatedefiners() mlx5lagcreatedefiner() <- Failed on tt 1 mlx5lagdestroydefiners() <- definers[tt=0] gets destroyed mlx5lagportselcreate() mlx5lagcreatedefiners() mlx5lagcreatedefiner() <- Failed on tt 0 mlx5lagdestroydefiners() <- definers[tt=0] gets double-destroyed

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptableraw bonding ipgre ip6gre gre ip6tunnel tunnel6 geneve ip6udptunnel udptunnel ipip tunnel4 iptunnel rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) ibuverbs(OE) mlx5fwctl(OE) fwctl(OE) mlx5core(OE) mlxdevm(OE) ibcore(OE) mlxfw(OE) memtrack(OE) mlxcompat(OE) openvswitch nsh nfconncount psample xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xfrmuser xfrmalgo xtaddrtype iptablefilter iptablenat nfnat nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc netconsole overlay efipstore schfqcodel zram iptables crct10difce qemufwcfg fuse ipv6 crcccitt [last unloaded: mlxcompat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5lag mlx5dobondwork [mlx5core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5delflowrules+0x24/0x2c0 [mlx5core] lr : mlx5lagdestroydefiner+0x54/0x100 [mlx5core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5delflowrules+0x24/0x2c0 [mlx5core] mlx5lagdestroydefiner+0x54/0x100 [mlx5core] mlx5lagdestroydefiners+0xa0/0x108 [mlx5core] mlx5lagportselcreate+0x2d4/0x6f8 [mlx5core] mlx5activatelag+0x60c/0x6f8 [mlx5core] mlx5dobondwork+0x284/0x5c8 [mlx5core] processonework+0x170/0x3e0 workerthread+0x2d8/0x3e0 kthread+0x11c/0x128 retfromfork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---(CVE-2025-21675)

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

scsi: storvsc: Ratelimit warning logs to prevent VM denial of service

If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM.(CVE-2025-21690)

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

net: sched: fix ets qdisc OOB Indexing

Haowei Yan <g1042620637@gmail.com> found that etsclassfromarg() can index an Out-Of-Bound class in etsclassfromarg() when passed clid of 0. The overflow may cause local privilege escalation.

[ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/schets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'etsclass [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dumpstacklvl+0xc2/0xf0 [ 18.859607] dumpstack+0x10/0x20 [ 18.860908] ubsanhandleoutofbounds+0xa7/0xf0 [ 18.864022] etsclasschange+0x3d6/0x3f0 [ 18.864322] tcctltclass+0x251/0x910 [ 18.864587] ? lockacquire+0x5e/0x140 [ 18.865113] ? _mutexlock+0x9c/0xe70 [ 18.866009] ? _mutexlock+0xa34/0xe70 [ 18.866401] rtnetlinkrcvmsg+0x170/0x6f0 [ 18.866806] ? _lockacquire+0x578/0xc10 [ 18.867184] ? _pfxrtnetlinkrcvmsg+0x10/0x10 [ 18.867503] netlinkrcvskb+0x59/0x110 [ 18.867776] rtnetlinkrcv+0x15/0x30 [ 18.868159] netlinkunicast+0x1c3/0x2b0 [ 18.868440] netlinksendmsg+0x239/0x4b0 [ 18.868721] _syssendmsg+0x3e2/0x410 [ 18.869012] _syssendmsg+0x88/0xe0 [ 18.869276] ? rseqipfixup+0x198/0x260 [ 18.869563] ? rsequpdatecpunodeid+0x10a/0x190 [ 18.869900] ? tracehardirqsoff+0x5a/0xd0 [ 18.870196] ? syscallexittousermode+0xcc/0x220 [ 18.870547] ? dosyscall64+0x93/0x150 [ 18.870821] ? _memcgslabfreehook+0x69/0x290 [ 18.871157] _syssendmsg+0x69/0xd0 [ 18.871416] _x64syssendmsg+0x1d/0x30 [ 18.871699] x64syscall+0x9e2/0x2670 [ 18.871979] dosyscall64+0x87/0x150 [ 18.873280] ? dosyscall64+0x93/0x150 [ 18.874742] ? lockrelease+0x7b/0x160 [ 18.876157] ? douseraddrfault+0x5ce/0x8f0 [ 18.877833] ? irqentryexittousermode+0xc2/0x210 [ 18.879608] ? irqentryexit+0x77/0xb0 [ 18.879808] ? clearbhbloop+0x15/0x70 [ 18.880023] ? clearbhbloop+0x15/0x70 [ 18.880223] ? clearbhbloop+0x15/0x70 [ 18.880426] entrySYSCALL64afterhwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]---(CVE-2025-21692)

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

drm/v3d: Ensure job pointer is set to NULL after job completion

After a job completes, the corresponding pointer in the device must be set to NULL. Failing to do so triggers a warning when unloading the driver, as it appears the job is still active. To prevent this, assign the job pointer to NULL after completing the job, indicating the job has finished.(CVE-2025-21697)

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

net: sched: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

step3. a class for nesting tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7. tc class add dev lo classid 3:1 drr

step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

The semantics of "replace" is for a del/add on the same node and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config".

Joint work with Lion Ackermann <nnamrec@gmail.com>(CVE-2025-21700)

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

net: avoid race between device unregistration and ethnl ops

The following trace can be seen if a device is being unregistered while its number of channels are being modified.

DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 mutexlock+0xc8a/0x1120 CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771 RIP: 0010:mutexlock+0xc8a/0x1120 Call Trace: <TASK> ethtoolcheckmaxchannel+0x1ea/0x880 ethnlsetchannels+0x3c3/0xb10 ethnldefaultsetdoit+0x306/0x650 genlfamilyrcvmsgdoit+0x1e3/0x2c0 genlrcvmsg+0x432/0x6f0 netlinkrcvskb+0x13d/0x3b0 genlrcv+0x28/0x40 netlinkunicast+0x42e/0x720 netlinksendmsg+0x765/0xc20 _syssendto+0x3ac/0x420 _x64syssendto+0xe0/0x1c0 dosyscall64+0x95/0x180 entrySYSCALL64after_hwframe+0x76/0x7e

This is because unregisternetdevicemanynotify might run before the rtnl lock section of ethnl operations, eg. setchannels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.

Fix this by denying any operation on devices being unregistered. A check was already there in ethnlopsbegin, but not wide enough.

Note that the same issue cannot be seen on the ioctl version (_devethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.(CVE-2025-21701)

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

kernel: be more careful about dup_mmap() failures and uprobe registering

If a memory allocation fails during dupmmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exitmmap() call (in mm/mmap.c), but the incomplete mmstruct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mmstruct.

Up to this point, there have been no issues with being able to find an mmstruct that was only partially initialised. Syzbot was able to make the incomplete mmstruct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below.

Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race.

This patch sets the MMFOOMSKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMFUNSTABLE to avoid other potential users from using a partially initialised mmstruct.

When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised.(CVE-2025-21709)

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

md/md-bitmap: Synchronize bitmapgetstats() with bitmap lifetime

After commit ec6bb299c7c3 ("md/md-bitmap: add 'syncsize' into struct mdbitmap_stats"), following panic is reported:

Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmapgetstats+0x2b/0xa0 Call Trace: <TASK> mdseqshow+0x2d2/0x5b0 seqreaditer+0x2b9/0x470 seqread+0x12f/0x180 procregread+0x57/0xb0 vfsread+0xf6/0x380 ksysread+0x6c/0xf0 dosyscall64+0x82/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

Root cause is that bitmapgetstats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger.

Fix the problem by protecting bitmapgetstats() with bitmap_info.mutex.(CVE-2025-21712)

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

nilfs2: handle errors that nilfspreparechunk() may return

Patch series "nilfs2: fix issues with rename operations".

This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved.

This patch (of 2):

The directory manipulation routines nilfssetlink() and nilfsdeleteentry() rewrite the directory entry in the folio/page previously read by nilfsfindentry(), so error handling is omitted on the assumption that nilfspreparechunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine.

This assumption is wrong, as proven by syzbot: the buffer layer called by nilfspreparechunk() may call nilfsgetblock() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests.

Fix this issue by adding missing error paths in nilfssetlink(), nilfsdeleteentry(), and their caller nilfs_rename().(CVE-2025-21721)

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

NFC: nci: Add bounds checking in ncihcicreate_pipe()

The "pipe" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, ncihciconnect_gate().(CVE-2025-21735)

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

scsi: ufs: core: Fix use-after free in init error and remove paths

devmblkcryptoprofileinit() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufshba's data structure 'struct ufshba::cryptoprofile'. This structure is allocated as part of the underlying ufshcd and therefore Scsihost allocation.

During driver release or during error handling in ufshcdpltfrminit(), this structure is released as part of ufshcddeallochost() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufshba::cryptoprofile'. This causes a use-after-free situation:

Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blkcryptoprofiledestroycallback+0x28/0x70 devmactionrelease+0x1c/0x30 releasenodes+0x6c/0x108 devresreleaseall+0x98/0x100 deviceunbindcleanup+0x20/0x70 reallyprobe+0x218/0x2d0

In other words, the initialisation code flow is:

platform-device probe ufshcdpltfrminit() ufshcdallochost() scsihostalloc() allocation of struct ufshba creation of scsi-host devices devmblkcryptoprofile_init() devm registration of cleanup handler using platform-device

and during error handling of ufshcdpltfrminit() or during driver removal:

ufshcddeallochost() scsihostput() putdevice(scsi-host) release of struct ufshba put_device(platform-device) crypto cleanup handler

To fix this use-after free, change ufshcdallochost() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcddeallochost(). This way:

* the crypto profile and all other ufs_hba-owned resources are
  destroyed before SCSI (as they've been registered after)
* a memleak is plugged in tc-dwc-g210-pci.c remove() as a
  side-effect
* EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as
  it's not needed anymore
* no future drivers using ufshcd_alloc_host() could ever forget
  adding the cleanup(CVE-2025-21739)

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

usbnet: ipheth: fix DPE OoB read

Fix an out-of-bounds DPE read, limit the number of processed DPEs to the amount that fits into the fixed-size NDP16 header.(CVE-2025-21741)

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

usbnet: ipheth: use static NDP16 location in URB

Original code allowed for the start of NDP16 to be anywhere within the URB based on the wNdpIndex value in NTH16. Only the start position of NDP16 was checked, so it was possible for even the fixed-length part of NDP16 to extend past the end of URB, leading to an out-of-bounds read.

On iOS devices, the NDP16 header always directly follows NTH16. Rely on and check for this specific format.

This, along with NCM-specific minimal URB length check that already exists, will ensure that the fixed-length part of NDP16 plus a set amount of DPEs fit within the URB.

Note that this commit alone does not fully address the OoB read. The limit on the amount of DPEs needs to be enforced separately.(CVE-2025-21742)

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

wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()

On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs.

The following sequence deletes the interface:

brcmfdetach() brcmfremoveinterface() brcmfdel_if()

Inside the brcmfdelif() function the drvr->if2bss[ifidx] is updated to BRCMFBSSIDXINVALID (-1) if the bsscfgidx matches.

After brcmfremoveinterface() call the brcmfprotodetach() function is called providing the following sequence:

brcmfdetach() brcmfprotodetach() brcmfprotomsgbufdetach() brcmfflowringdetach() brcmfmsgbufdeleteflowring() brcmfmsgbufremoveflowring() brcmfflowringdelete() brcmfgetifp() brcmf_txfinalize()

Since brcmfgetip() can and actually will return NULL in this case the call to brcmftxfinalize() will result in a NULL pointer dereference inside brcmftxfinalize() when trying to update ifp->ndev->stats.tx_errors.

This will only happen if a flowring still has an skb.

Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.(CVE-2025-21744)

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

Input: synaptics - fix crash when enabling pass-through port

When enabling a pass-through port an interrupt might come before psmouse driver binds to the pass-through port. However synaptics sub-driver tries to access psmouse instance presumably associated with the pass-through port to figure out if only 1 byte of response or entire protocol packet needs to be forwarded to the pass-through port and may crash if psmouse instance has not been attached to the port yet.

Fix the crash by introducing open() and close() methods for the port and check if the port is open before trying to access psmouse instance. Because psmouse calls serio_open() only after attaching psmouse instance to serio port instance this prevents the potential crash.(CVE-2025-21746)

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

ksmbd: fix integer overflows on 32 bit systems

On 32bit systems the addition operations in ipcmsgalloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBDIPCMAX_PAYLOAD to avoid overflow.(CVE-2025-21748)

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

net: rose: lock the socket in rose_bind()

syzbot reported a soft lockup in roseloopbacktimer(), with a repro calling bind() from multiple threads.

rose_bind() must lock the socket to avoid this issue.(CVE-2025-21749)

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

btrfs: fix use-after-free when attempting to join an aborted transaction

When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fsinfo->translock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free.

Fix this by reading the 'aborted' field while holding fsinfo->translock since any freeing task must first acquire that lock and set fsinfo->runningtransaction to NULL before freeing the transaction.

This was reported by syzbot and Dmitry with the following stack traces from KASAN:

================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128

CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: eventsunbound btrfsasyncreclaimdataspace Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 jointransaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 starttransaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flushspace+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfsasyncreclaimdataspace+0x159/0x510 fs/btrfs/space-info.c:1321 processonework kernel/workqueue.c:3236 [inline] processscheduledworks+0xa66/0x1840 kernel/workqueue.c:3317 workerthread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

Allocated by task 5315: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x243/0x390 mm/slub.c:4329 kmallocnoprof include/linux/slab.h:901 [inline] jointransaction+0x144/0xda0 fs/btrfs/transaction.c:308 starttransaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfscreatecommon+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookupopen fs/namei.c:3649 [inline] openlastlookups fs/namei.c:3748 [inline] pathopenat+0x1c03/0x3590 fs/namei.c:3984 dofilpopen+0x27f/0x4e0 fs/namei.c:4014 dosysopenat2+0x13e/0x1d0 fs/open.c:1402 dosysopen fs/open.c:1417 [inline] _dosyscreat fs/open.c:1495 [inline] _sesyscreat fs/open.c:1489 [inline] _x64syscreat+0x123/0x170 fs/open.c:1489 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 5336: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:582 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2353 [inline] slabfree mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanuptransaction fs/btrfs/transaction.c:2063 [inline] btrfscommittransaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insertbalanceitem+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---(CVE-2025-21753)

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

ipv6: mcast: add RCU protection to mld_newpack()

mld_newpack() can be called without RTNL or RCU being held.

Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFP_KERNEL allocations which can sleep.

Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.(CVE-2025-21758)

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

ipv6: mcast: extend RCU protection in igmp6_send()

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.

Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFP_KERNEL allocations which can sleep.

Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.(CVE-2025-21759)

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

ndisc: extend RCU protection in ndiscsendskb()

ndiscsendskb() can be called without RTNL or RCU held.

Acquire rcureadlock() earlier, so that we can use devnetrcu() and avoid a potential UAF.(CVE-2025-21760)

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

openvswitch: use RCU protection in ovsvportcmdfillinfo()

ovsvportcmdfillinfo() can be called without RTNL or RCU.

Use RCU protection and devnetrcu() to avoid potential UAF.(CVE-2025-21761)

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

arp: use RCU protection in arp_xmit()

arp_xmit() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.(CVE-2025-21762)

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

neighbour: use RCU protection in _neighnotify()

_neighnotify() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.(CVE-2025-21763)

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

ndisc: use RCU protection in ndiscallocskb()

ndiscallocskb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.(CVE-2025-21764)

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

ipv6: use RCU protection in ip6defaultadvmss()

ip6defaultadvmss() needs rcu protection to make sure the net structure it reads does not disappear.(CVE-2025-21765)

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

ipv4: use RCU protection in _iprtupdatepmtu()

_iprtupdatepmtu() must use RCU protection to make sure the net structure it reads does not disappear.(CVE-2025-21766)

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

partitions: mac: fix handling of bogus partition table

Fix several issues in partition probing:

• The bailout for a bad partoffset must use putdevsector(), since the preceding readpartsector() succeeded.
• If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory.
• We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)

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

can: etas_es58x: fix potential NULL pointer dereference on udev->serial

The driver assumed that es58x_dev->udev->serial could never be NULL. While this is true on commercially available devices, an attacker could spoof the device identity providing a NULL USB serial number. That would trigger a NULL pointer dereference.

Add a check on es58x_dev->udev->serial before accessing it.(CVE-2025-21773)

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

can: ctucanfd: handle skb allocation failure

If skb allocation fails, the pointer to struct canframe is NULL. This is actually handled everywhere inside ctucanerr_interrupt() except for the only place.

Add the missed NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2025-21775)

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

KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel

Advertise support for Hyper-V's SENDIPI and SENDIPIEX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVMCAPHYPERVENFORCE_CPUID.

Rejecting SENDIPI and SENDIPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:

dumpstack+0xbe/0xfd _kasanreport.cold+0x34/0x84 kasanreport+0x3a/0x50 _apicacceptirq+0x3a/0x5c0 kvmhvsendipi.isra.0+0x34e/0x820 kvmhvhypercall+0x8d9/0x9d0 kvmemulatehypercall+0x506/0x7e0 _vmxhandleexit+0x283/0xb60 vmxhandleexit+0x1d/0xd0 vcpuenterguest+0x16b0/0x24c0 vcpurun+0xc0/0x550 kvmarchvcpuioctlrun+0x170/0x6d0 kvmvcpuioctl+0x413/0xb20 _sesysioctl+0x111/0x160 dosyscal164+0x30/0x40 entrySYSCALL64after_hwframe+0x67/0xd1

Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.(CVE-2025-21779)

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

drm/amdgpu: avoid buffer overflow attach in smusyssetpptable()

It malicious user provides a small pptable through sysfs and then a bigger pptable, it may cause buffer overflow attack in function smusyssetpptable().(CVE-2025-21780)

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

batman-adv: fix panic during interface removal

Reference counting is used to ensure that batadvhardifneighnode and batadvhardiface are not freed before/during batadvvelpthroughputmetricupdate work is finished.

But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished.

This fixes a crash triggered by reboot that looks like this:

Call trace: batadvvmeshfree+0xd0/0x4dc [batmanadv] batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x178/0x398 workerthread+0x2e8/0x4d0 kthread+0xd8/0xdc retfromfork+0x10/0x20

(the batadvvmesh_free call is misleading, and does not actually happen)

I was able to make the issue happen more reliably by changing hardifneigh->batv.metric_work work to be delayed work. This allowed me to track down and confirm the fix.

sven@narfation.org: prevent entering batadvvelpgetthroughput without soft_iface

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

drm/amdgpu: bail out when failed to load fw in pspinitcap_microcode()

In function pspinitcap_microcode(), it should bail out when failed to load firmware, otherwise it may cause invalid memory access.(CVE-2025-21784)

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

vxlan: check vxlanvnigroupinit() return value

vxlaninit() must check vxlanvnigroup_init() success otherwise a crash happens later, spotted by syzbot.

Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlanvnigroupuninit+0x89/0x500 drivers/net/vxlan/vxlanvnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlanuninit+0x1ab/0x200 drivers/net/vxlan/vxlancore.c:2942 unregisternetdevicemanynotify+0x12d6/0x1f30 net/core/dev.c:11824 unregisternetdevicemany net/core/dev.c:11866 [inline] unregisternetdevicequeue+0x307/0x3f0 net/core/dev.c:11736 registernetdevice+0x1829/0x1eb0 net/core/dev.c:10901 _vxlandevcreate+0x7c6/0xa30 drivers/net/vxlan/vxlancore.c:3981 vxlannewlink+0xd1/0x130 drivers/net/vxlan/vxlancore.c:4407 rtnlnewlinkcreate net/core/rtnetlink.c:3795 [inline] _rtnl_newlink net/core/rtnetlink.c:3906 inline

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

ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt

If an AX25 device is bound to a socket by setting the SOBINDTODEVICE socket option, a refcount leak will occur in ax25release().

Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25cbdel()") added decrement of device refcounts in ax25release(). In order for that to work correctly the refcounts must already be incremented when the device is bound to the socket. An AX25 device can be bound to a socket by either calling ax25bind() or setting SOBINDTODEVICE socket option. In both cases the refcounts should be incremented, but in fact it is done only in ax25bind().

This bug leads to the following issue reported by Syzkaller:

================================================================ refcountt: decrement hit 0; leaking memory. WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcountwarnsaturate+0x1ed/0x210 lib/refcount.c:31 Modules linked in: CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcountwarnsaturate+0x1ed/0x210 lib/refcount.c:31 Call Trace: <TASK> _refcountdec include/linux/refcount.h:336 [inline] refcountdec include/linux/refcount.h:351 [inline] reftrackerfree+0x710/0x820 lib/reftracker.c:236 netdevtrackerfree include/linux/netdevice.h:4156 [inline] netdevput include/linux/netdevice.h:4173 [inline] netdevput include/linux/netdevice.h:4169 [inline] ax25release+0x33f/0xa10 net/ax25/afax25.c:1069 _sockrelease+0xb0/0x270 net/socket.c:640 sockclose+0x1c/0x30 net/socket.c:1408 ... dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f ...

</TASK>

Fix the implementation of ax25_setsockopt() by adding increment of refcounts for the new device bound, and decrement of refcounts for the old unbound device.(CVE-2025-21792)

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

spi: sn-f-ospi: Fix division by zero

When there is no dummy cycle in the spi-nor commands, both dummy bus cycle bytes and width are zero. Because of the cpu's warning when divided by zero, the warning should be avoided. Return just zero to avoid such calculations.(CVE-2025-21793)

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

fbdev: omap: use threaded IRQ for LCD DMA

When using touchscreen and framebuffer, Nokia 770 crashes easily with:

BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000
Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd
CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2
Hardware name: Nokia 770
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x54/0x5c
 dump_stack_lvl from __schedule_bug+0x50/0x70
 __schedule_bug from __schedule+0x4d4/0x5bc
 __schedule from schedule+0x34/0xa0
 schedule from schedule_preempt_disabled+0xc/0x10
 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4
 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4
 clk_prepare_lock from clk_set_rate+0x18/0x154
 clk_set_rate from sossi_read_data+0x4c/0x168
 sossi_read_data from hwa742_read_reg+0x5c/0x8c
 hwa742_read_reg from send_frame_handler+0xfc/0x300
 send_frame_handler from process_pending_requests+0x74/0xd0
 process_pending_requests from lcd_dma_irq_handler+0x50/0x74
 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130
 __handle_irq_event_percpu from handle_irq_event+0x28/0x68
 handle_irq_event from handle_level_irq+0x9c/0x170
 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c
 generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c
 omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c
 generic_handle_arch_irq from call_with_stack+0x1c/0x24
 call_with_stack from __irq_svc+0x94/0xa8
Exception stack(0xc5255da0 to 0xc5255de8)
5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248
5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94
5de0: 60000013 ffffffff
 __irq_svc from clk_prepare_lock+0x4c/0xe4
 clk_prepare_lock from clk_get_rate+0x10/0x74
 clk_get_rate from uwire_setup_transfer+0x40/0x180
 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c
 spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664
 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498
 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8
 __spi_sync from spi_sync+0x24/0x40
 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0
 ads7846_halfd_read_state from ads7846_irq+0x58/0x348
 ads7846_irq from irq_thread_fn+0x1c/0x78
 irq_thread_fn from irq_thread+0x120/0x228
 irq_thread from kthread+0xc8/0xe8
 kthread from ret_from_fork+0x14/0x28

As a quick fix, switch to a threaded IRQ which provides a stable system.(CVE-2025-21821)

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

netfilter: nftables: reject mismatching sum of fieldlen with set key length

The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits.

Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.(CVE-2025-21826)

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

landlock: Handle weird files

A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.(CVE-2025-21830)

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

PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1

commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the policy that all PCIe ports are allowed to use D3. When the system is suspended if the port is not power manageable by the platform and won't be used for wakeup via a PME this sets up the policy for these ports to go into D3hot.

This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a specific old BIOS. This manifests as a system hang.

On the affected Device + BIOS combination, add a quirk for the root port of the problematic controller to ensure that these root ports are not put into D3hot at suspend.

This patch is based on

https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com

but with the added condition both in the documentation and in the code to apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports.(CVE-2025-21831)

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

usb: gadget: f_midi: fix MIDI Streaming descriptor lengths

While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.

This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller.

The precise meaning of "in" and "out" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that "in" ports send data to the host and "out" ports receive data from it.(CVE-2025-21835)

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

io_uring/kbuf: reallocate buf lists on upgrade

IORINGREGISTERPBUFRING can reuse an old struct iobuffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead.(CVE-2025-21836)

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

usb: gadget: core: flush gadget workqueue after device removal

devicedel() can lead to new work being scheduled in gadget->work workqueue. This is observed, for example, with the dwc3 driver with the following call stack: devicedel() gadgetunbinddriver() usbgadgetdisconnectlocked() dwc3gadgetpullup() dwc3gadgetsoftdisconnect() usbgadgetsetstate() schedulework(&gadget->work)

Move flushwork() after devicedel() to ensure the workqueue is cleaned up.(CVE-2025-21838)

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

ASoC: SOF: stream-ipc: Check for cstream nullity in sofipcmsg_data()

The nullity of sps->cstream should be checked similarly as it is done in sofsetstreamdataoffset() function. Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference.(CVE-2025-21847)

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

nfp: bpf: Add check for nfpappctrlmsgalloc()

Add check for the return value of nfpappctrlmsgalloc() in nfpbpfcmsg_alloc() to prevent null pointer dereference.(CVE-2025-21848)

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

ibmvnic: Don't reference skb after sending to VIOS

Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.

It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnicxmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dumpstacklvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] printreport+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasanreport+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] _asanload4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnicxmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] devhardstartxmit+0x150/0x358 <...> Freed by task 0: kasansavestack+0x34/0x68 kasansavetrack+0x2c/0x50 kasansavefreeinfo+0x64/0x108 _kasanmempoolpoisonobject+0x148/0x2d4 napiskbcacheput+0x5c/0x194 nettxaction+0x154/0x5b8 handlesoftirqs+0x20c/0x60c dosoftirqownstack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuffhead_cache of size 224 ==================================================================(CVE-2025-21855)

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

net/sched: cls_api: fix error handling causing NULL dereference

tcfextsmisscookiebasealloc() calls xaalloccyclic() which can return 1 if the allocation succeeded after wrapping. This was treated as an error, with value 1 returned to caller tcfextsinitex() which sets exts->actions to NULL and returns 1 to caller fl_change().

flchange() treats err == 1 as success, calling tcfextsvalidateex() which calls tcfactioninit() with exts->actions as argument, where it is dereferenced.

Example trace:

BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el95.x8664 #1 RIP: 0010:tcfactioninit+0x1f8/0x2c0 Call Trace: tcfactioninit+0x1f8/0x2c0 tcfextsvalidateex+0x175/0x190 flchange+0x537/0x1120 cls_flower

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

geneve: Fix use-after-free in genevefinddev().

syzkaller reported a use-after-free in genevefinddev() [0] without repro.

geneveconfigure() links struct genevedev.next to netgeneric(net, genevenetid)->genevelist.

The net here could differ from devnet(dev) if IFLANETNSPID, IFLANETNSFD, or IFLATARGET_NETNSID is set.

When devnet(dev) is dismantled, geneveexitbatchrtnl() finally calls unregisternetdevicequeue() for each dev in the netns, and later the dev is freed.

However, its geneve_dev.next is still linked to the backend UDP socket netns.

Then, use-after-free will occur when another geneve dev is created in the netns.

Let's call genevedellink() instead in genevedestroy_tunnels().

BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441

CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: showstack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xbc/0x108 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x16c/0x6f0 mm/kasan/report.c:489 kasanreport+0xc0/0x120 mm/kasan/report.c:602 _asanreportload2noabort+0x20/0x30 mm/kasan/reportgeneric.c:379 genevefinddev drivers/net/geneve.c:1295 [inline] geneveconfigure+0x234/0x858 drivers/net/geneve.c:1343 genevenewlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnlnewlinkcreate+0x23c/0x868 net/core/rtnetlink.c:3795 _rtnlnewlink net/core/rtnetlink.c:3906 [inline] rtnlnewlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlinkrcvmsg+0x61c/0x918 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1dc/0x398 net/netlink/afnetlink.c:2543 rtnetlinkrcv+0x34/0x50 net/core/rtnetlink.c:6938 netlinkunicastkernel net/netlink/afnetlink.c:1322 [inline] netlinkunicast+0x618/0x838 net/netlink/afnetlink.c:1348 netlinksendmsg+0x5fc/0x8b0 net/netlink/afnetlink.c:1892 socksendmsgnosec net/socket.c:713 [inline] _socksendmsg net/socket.c:728 [inline] _syssendmsg+0x410/0x6f8 net/socket.c:2568 _syssendmsg+0x178/0x1d8 net/socket.c:2622 _syssendmsg net/socket.c:2654 [inline] _dosyssendmsg net/socket.c:2659 [inline] _sesyssendmsg net/socket.c:2657 [inline] _arm64syssendmsg+0x12c/0x1c8 net/socket.c:2657 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0svccommon+0x13c/0x250 arch/arm64/kernel/syscall.c:132 doel0svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t64synchandler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t64sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600

Allocated by task 13247: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x30/0x68 mm/kasan/common.c:68 kasansaveallocinfo+0x44/0x58 mm/kasan/generic.c:568 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x84/0xa0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4298 [inline] _kmallocnodenoprof+0x2a0/0x560 mm/slub.c:4304 _kvmallocnodenoprof+0x9c/0x230 mm/util.c:645 allocnetdevmqs+0xb8/0x11a0 net/core/dev.c:11470 rtnlcreatelink+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnlnewlinkcreate+0x19c/0x868 net/core/rtnetlink.c:3780 _rtnlnewlink net/core/rtnetlink.c:3906 [inline] rtnlnewlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlinkrcvmsg+0x61c/0x918 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1dc/0x398 net/netlink/afnetlink.c:2543 rtnetlinkrcv+0x34/0x50 net/core/rtnetlink.c:6938 netlinkunicastkernel net/netlink/af_n ---truncated---(CVE-2025-21858)

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

USB: gadget: fmidi: fmidicomplete to call queuework

When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to fmiditransmit, causing a deadlock.

Fix it by using queuework() to schedule the inner fmidi_transmit() via a high priority work queue from the completion handler.(CVE-2025-21859)

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

drop_monitor: fix incorrect initialization order

Syzkaller reports the following bug:

BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: <none>/-1, .ownercpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x119/0x179 lib/dumpstack.c:118 debugspinlockbefore kernel/locking/spinlockdebug.c:83 [inline] dorawspinlock+0x1f6/0x270 kernel/locking/spinlockdebug.c:112 _rawspinlockirqsave include/linux/spinlockapismp.h:117 [inline] _rawspinlockirqsave+0x50/0x70 kernel/locking/spinlock.c:159 resetpercpudata+0xe6/0x240 [dropmonitor] netdmcmdtrace+0x43d/0x17a0 [dropmonitor] genlfamilyrcvmsgdoit+0x22f/0x330 net/netlink/genetlink.c:739 genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] genlrcvmsg+0x341/0x5a0 net/netlink/genetlink.c:800 netlinkrcvskb+0x14d/0x440 net/netlink/afnetlink.c:2497 genlrcv+0x29/0x40 net/netlink/genetlink.c:811 netlinkunicastkernel net/netlink/afnetlink.c:1322 [inline] netlinkunicast+0x54b/0x800 net/netlink/afnetlink.c:1348 netlinksendmsg+0x914/0xe00 net/netlink/afnetlink.c:1916 socksendmsgnosec net/socket.c:651 [inline] _socksendmsg+0x157/0x190 net/socket.c:663 syssendmsg+0x712/0x870 net/socket.c:2378 _syssendmsg+0xf8/0x170 net/socket.c:2432 _syssendmsg+0xea/0x1b0 net/socket.c:2461 dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 entrySYSCALL64afterhwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768

If dropmonitor is built as a kernel module, syzkaller may have time to send a netlink NETDMCMDSTART message during the module loading. This will call the netdmmonitor_start() function that uses a spinlock that has not yet been initialized.

To fix this, let's place resource initialization above the registration of a generic netlink family.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-21862)

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

powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC

Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6:

BUG: KASAN: vmalloc-out-of-bounds in copytokernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293

CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dumpstacklvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] printreport+0xdc/0x504 [c2437610] [c050475c] kasanreport+0xf8/0x108 [c2437690] [c0505a3c] kasancheckrange+0x24/0x18c [c24376a0] [c03fb5e4] copytokernelnofault+0xd8/0x1c8 [c24376c0] [c004c014] patchinstructions+0x15c/0x16c [c2437710] [c00731a8] bpfarchtextcopy+0x60/0x7c [c2437730] [c0281168] bpfjitbinarypackfinalize+0x50/0xac [c2437750] [c0073cf4] bpfintjitcompile+0xb30/0xdec [c2437880] [c0280394] bpfprogselectruntime+0x15c/0x478 [c24378d0] [c1263428] bpfpreparefilter+0xbf8/0xc14 [c2437990] [c12677ec] bpfprogcreatefromuser+0x258/0x2b4 [c24379d0] [c027111c] doseccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] systemcallexception+0x2dc/0x420 [c2437f30] [c00281ac] retfromsyscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 <VEC,EE,PR,FP,ME,IR,DR,RI> CR: 24004422 XER: 00000000

GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00

The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: textareacpu_up+0x20/0x190

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================

f8 corresponds to KASANVMALLOCINVALID which means the area is not initialised hence not supposed to be used yet.

Powerpc text patching infrastructure allocates a virtual memory area using getvmarea() and flags it as VMALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to _vmallocnoderange() which is never called for that area.

That went undetected until commit e4137f08816b ("mm, kasan, kmsan: instrument copyfrom/tokernel_nofault")

The area allocated by textareacpuup() is not vmalloc memory, it is mapped directly on demand when needed by mapkernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.(CVE-2025-21866)

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 bpftest_init().

Fix this by returning an error when userdata is less than ETHHLEN in bpftestinit(). Additionally, remove the check for "if (user_size > 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 entrySYSCALL64after_hwframe+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/entry_64.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(CVE-2025-21867)

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

ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers

Other, non DAI copier widgets could have the same stream name (sname) as the ALH copier and in that case the copier->data is NULL, no alhdata is attached, which could lead to NULL pointer dereference. We could check for this NULL pointer in sofipc4preparecopiermodule() and avoid the crash, but a similar loop in sofipc4widgetsetupcompdai() will miscalculate the ALH device count, causing broken audio.

The correct fix is to harden the matching logic by making sure that the 1. widget is a DAI widget - so dai = w->private is valid 2. the dai (and thus the copier) is ALH copier(CVE-2025-21870)

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

tee: optee: Fix supplicant wait loop

OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application.

Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would.

This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.(CVE-2025-21871)

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

scsi: ufs: core: bsg: Fix crash when arpmb command fails

If the device doesn't support arpmb we'll crash due to copying user data in bsgtransportsgiofn().

In the case where ufsbsgexecadvancedrpmbreq() returns an error, do not set the job's replylen.

Memory crash backtrace: 3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22

4,1308,531166555,-;Call Trace:

4,1309,531166559,-; <TASK>

4,1310,531166565,-; ? show_regs+0x6d/0x80

4,1311,531166575,-; ? die+0x37/0xa0

4,1312,531166583,-; ? do_trap+0xd4/0xf0

4,1313,531166593,-; ? doerrortrap+0x71/0xb0

4,1314,531166601,-; ? usercopy_abort+0x6c/0x80

4,1315,531166610,-; ? excinvalidop+0x52/0x80

4,1316,531166622,-; ? usercopy_abort+0x6c/0x80

4,1317,531166630,-; ? asmexcinvalid_op+0x1b/0x20

4,1318,531166643,-; ? usercopy_abort+0x6c/0x80

4,1319,531166652,-; _checkheap_object+0xe3/0x120

4,1320,531166661,-; checkheapobject+0x185/0x1d0

4,1321,531166670,-; _checkobject_size.part.0+0x72/0x150

4,1322,531166679,-; _checkobject_size+0x23/0x30

4,1323,531166688,-; bsgtransportsgiofn+0x314/0x3b0(CVE-2025-21873)

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

usbnet: gl620a: fix endpoint checking in genelink_bind()

Syzbot reports [1] a warning in usbsubmiturb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch.

Fix the issue by resorting to a usbnet utility function usbnetgetendpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing.

[1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummyhcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mldifcwork RIP: 0010:usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbnetstartxmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3606 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 _devxmitskb net/core/dev.c:3827 [inline] _devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4400 devqueuexmit include/linux/netdevice.h:3168 [inline] neighresolveoutput net/core/neighbour.c:1514 [inline] neighresolveoutput+0x5bc/0x950 net/core/neighbour.c:1494 neighoutput include/net/neighbour.h:539 [inline] ip6finishoutput2+0xb1b/0x2070 net/ipv6/ip6output.c:141 _ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0x3f9/0x1360 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x1f8/0x540 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] mldsendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mldsendcr net/ipv6/mcast.c:2120 [inline] mldifcwork+0x740/0xca0 net/ipv6/mcast.c:2651 processonework+0x9c5/0x1ba0 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>(CVE-2025-21877)

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

i2c: npcm: disable interrupt enable bit before devmrequestirq

The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset.

Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer.

Disable the interrupt enable bit in the i2c module before calling devmrequestirq to fix this issue since the i2c relative status bit is read-only.

Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : _dosoftirq+0xb0/0x368 [ 28.212055] lr : _dosoftirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] _dosoftirq+0xb0/0x368 [ 28.296625] _irqexitrcu+0xe0/0x100 [ 28.300374] irqexit+0x14/0x20 [ 28.303513] handledomainirq+0x68/0x90 [ 28.307440] gichandleirq+0x78/0xb0 [ 28.311098] callonirqstack+0x20/0x38 [ 28.315019] dointerrupthandler+0x54/0x5c [ 28.319199] el1interrupt+0x2c/0x4c [ 28.322777] el1h64irqhandler+0x14/0x20 [ 28.326872] el1h64irq+0x74/0x78 [ 28.330269] _setupirq+0x454/0x780 [ 28.333841] requestthreadedirq+0xd0/0x1b4 [ 28.338107] devmrequestthreadedirq+0x84/0x100 [ 28.342809] npcmi2cprobebus+0x188/0x3d0 [ 28.346990] platformprobe+0x6c/0xc4 [ 28.350653] reallyprobe+0xcc/0x45c [ 28.354227] _driverprobedevice+0x8c/0x160 [ 28.358578] driverprobedevice+0x44/0xe0 [ 28.362670] _driverattach+0x124/0x1d0 [ 28.366589] busforeachdev+0x7c/0xe0 [ 28.370426] driverattach+0x28/0x30 [ 28.373997] busadddriver+0x124/0x240 [ 28.377830] driverregister+0x7c/0x124 [ 28.381662] _platformdriverregister+0x2c/0x34 [ 28.386362] npcmi2cinit+0x3c/0x5c [ 28.389937] dooneinitcall+0x74/0x230 [ 28.393768] kernelinitfreeable+0x24c/0x2b4 [ 28.398126] kernelinit+0x28/0x130 [ 28.401614] retfrom_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..(CVE-2025-21878)

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

uprobes: Reject the shared zeropage in uprobewriteopcode()

We triggered the following crash in syzkaller tests:

BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x32/0x50 badpage+0x69/0xf0 freeunrefpageprepare+0x401/0x500 freeunrefpage+0x6d/0x1b0 uprobewriteopcode+0x460/0x8e0 installbreakpoint.part.0+0x51/0x80 registerforeachvma+0x1d9/0x2b0 _uproberegister+0x245/0x300 bpfuprobemultilinkattach+0x29b/0x4f0 linkcreate+0x1e2/0x280 _sysbpf+0x75f/0xac0 _x64sysbpf+0x1a/0x30 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1

The following syzkaller test case can be used to reproduce:

r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORINGOFFSQRING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIOAPI(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIOAPI(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIOREGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIOZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROGLOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPFLINKCREATEXDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobemulti={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)

The cause is that zero pfn is set to the PTE without increasing the RSS count in mfillatomicptezeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobewriteopcode()->replacepage() to unconditional decrease the RSS count and old_folio's refcount.

Therefore, two bugs are introduced:

1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".

2. The reserved folio (zero folio) is freed when folio->refcount is zero, then freepagesprepare->freepageis_bad() report error "Bad page state".

There is more, the following warning could also theoretically be triggered:

_replacepage() -> ... -> folioremovermappte() -> VMWARNONFOLIO(iszerofolio(folio), folio)

Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after getuserpagevmaremote().

mingo: Cleaned up the changelog

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

ice: Fix deinitializing VF in error path

If iceenavfs() fails after calling icecreatevf_entries(), it frees all VFs without removing them from snapshot PF-VF mailbox list, leading to list corruption.

Reproducer: devlink dev eswitch set $PF1PCI mode switchdev ip l s $PF1 up ip l s $PF1 promisc on sleep 1 echo 1 > /sys/class/net/$PF1/device/sriovnumvfs sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs

Trace (minimized): listadd corruption. next->prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330). kernel BUG at lib/listdebug.c:29! RIP: 0010:_listaddvalidorreport+0xa6/0x100 icembxinitvfinfo+0xa7/0x180 [ice] iceinitializevfentry+0x1fa/0x250 [ice] icesriovconfigure+0x8d7/0x1520 [ice] ? _percpurefswitchmode+0x1b1/0x5d0 ? _pfxicesriovconfigure+0x10/0x10 [ice]

Sometimes a KASAN report can be seen instead with a similar stack trace: BUG: KASAN: use-after-free in _listaddvalidor_report+0xf1/0x100

VFs are added to this list in icembxinitvfinfo(), but only removed in icefreevfs(). Move the removing to icefreevfentries(), which is also being called in other places where VFs are being removed (including icefree_vfs() itself).(CVE-2025-21883)

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

RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers

While using nvme target with use_srq on, below kernel panic is noticed.

[ 549.698111] bnxten 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514) [ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI .. [ 566.393799] <TASK> [ 566.393807] ? _diebody+0x1a/0x60 [ 566.393823] ? die+0x38/0x60 [ 566.393835] ? dotrap+0xe4/0x110 [ 566.393847] ? bnxtqpliballocinithwq+0x1d4/0x580 [bnxtre] [ 566.393867] ? bnxtqpliballocinithwq+0x1d4/0x580 [bnxtre] [ 566.393881] ? doerrortrap+0x7c/0x120 [ 566.393890] ? bnxtqpliballocinithwq+0x1d4/0x580 [bnxtre] [ 566.393911] ? excdivideerror+0x34/0x50 [ 566.393923] ? bnxtqpliballocinithwq+0x1d4/0x580 [bnxtre] [ 566.393939] ? asmexcdivideerror+0x16/0x20 [ 566.393966] ? bnxtqpliballocinithwq+0x1d4/0x580 [bnxtre] [ 566.393997] bnxtqplibcreatesrq+0xc9/0x340 [bnxtre] [ 566.394040] bnxtrecreatesrq+0x335/0x3b0 [bnxtre] [ 566.394057] ? srsoreturnthunk+0x5/0x5f [ 566.394068] ? _initswaitqueuehead+0x4a/0x60 [ 566.394090] ibcreatesrquser+0xa7/0x150 [ibcore] [ 566.394147] nvmetrdmaqueueconnect+0x7d0/0xbe0 [nvmetrdma] [ 566.394174] ? lockrelease+0x22c/0x3f0 [ 566.394187] ? srsoreturn_thunk+0x5/0x5f

Page size and shift info is set only for the user space SRQs. Set page size and page shift for kernel space SRQs also.(CVE-2025-21885)

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

RDMA/mlx5: Fix a WARN during dereg_mr for DM type

Memory regions (MR) of type DM (device memory) do not have an associated umem.

In the _mlx5ibderegmr() -> mlx5freeprivdescs() flow, the code incorrectly takes the wrong branch, attempting to call dmaunmap_single() on a DMA address that is not mapped.

This results in a WARN [1], as shown below.

The issue is resolved by properly accounting for the DM type and ensuring the correct branch is selected in mlx5freepriv_descs().

[1] WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommudmaunmappage+0x79/0x90 Modules linked in: ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry ovelay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm mlx5ib ibuverbs ibcore fuse mlx5core CPU: 12 UID: 0 PID: 1346 Comm: ibvrcpingpong Not tainted 6.12.0-rc7+ #1631 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00 RSP: 0018:ffffc90001913a10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _warn+0x84/0x190 ? iommudmaunmappage+0x79/0x90 ? reportbug+0xf8/0x1c0 ? handlebug+0x55/0x90 ? excinvalidop+0x13/0x60 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 dmaunmappageattrs+0xe6/0x290 mlx5freeprivdescs+0xb0/0xe0 [mlx5ib] _mlx5ibderegmr+0x37e/0x520 [mlx5ib] ? rawspinunlockirq+0x24/0x40 ? waitforcompletion+0xfe/0x130 ? rdmarestrackput+0x63/0xe0 [ibcore] ibderegmruser+0x5f/0x120 [ibcore] ? lockrelease+0xc6/0x280 destroyhwidruobject+0x1d/0x60 [ibuverbs] uverbsdestroyuobject+0x58/0x1d0 [ibuverbs] uobjdestroy+0x3f/0x70 [ibuverbs] ibuverbscmdverbs+0x3e4/0xbb0 [ibuverbs] ? _pfxuverbsdestroydefhandler+0x10/0x10 [ibuverbs] ? lockacquire+0xc1/0x2f0 ? ibuverbsioctl+0xcb/0x170 [ibuverbs] ? ibuverbsioctl+0x116/0x170 [ibuverbs] ? lockrelease+0xc6/0x280 ibuverbsioctl+0xe7/0x170 [ibuverbs] ? ibuverbsioctl+0xcb/0x170 [ibuverbs] _x64sysioctl+0x1b0/0xa70 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f537adaf17b Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270 R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190 R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450 </TASK>(CVE-2025-21888)

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

RDMA/mlx5: Fix the recovery flow of the UMR QP

This patch addresses an issue in the recovery flow of the UMR QP, ensuring tasks do not get stuck, as highlighted by the call trace [1].

During recovery, before transitioning the QP to the RESET state, the software must wait for all outstanding WRs to complete.

Failing to do so can cause the firmware to skip sending some flushed CQEs with errors and simply discard them upon the RESET, as per the IB specification.

This race condition can result in lost CQEs and tasks becoming stuck.

To resolve this, the patch sends a final WR which serves only as a barrier before moving the QP state to RESET.

Once a CQE is received for that final WR, it guarantees that no outstanding WRs remain, making it safe to transition the QP to RESET and subsequently back to RTS, restoring proper functionality.

Note: For the barrier WR, we simply reuse the failed and ready WR. Since the QP is in an error state, it will only receive IBWCWRFLUSHERR. However, as it serves only as a barrier we don't care about its status.

[1] INFO: task rdmaresourcel:1922 blocked for more than 120 seconds. Tainted: G W 6.12.0-rc7+ #1626 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:rdmaresourcel state:D stack:0 pid:1922 tgid:1922 ppid:1369 flags:0x00004004 Call Trace: <TASK> _schedule+0x420/0xd30 schedule+0x47/0x130 scheduletimeout+0x280/0x300 ? markheldlocks+0x48/0x80 ? lockdephardirqsonprepare+0xe5/0x1a0 waitforcompletion+0x75/0x130 mlx5rumrpostsendwait+0x3c2/0x5b0 [mlx5ib] ? _pfxmlx5rumrdone+0x10/0x10 [mlx5ib] mlx5rumrrevokemr+0x93/0xc0 [mlx5ib] _mlx5ibderegmr+0x299/0x520 [mlx5ib] ? _rawspinunlockirq+0x24/0x40 ? waitforcompletion+0xfe/0x130 ? rdmarestrackput+0x63/0xe0 [ibcore] ibderegmruser+0x5f/0x120 [ibcore] ? lockrelease+0xc6/0x280 destroyhwidruobject+0x1d/0x60 [ibuverbs] uverbsdestroyuobject+0x58/0x1d0 [ibuverbs] uobjdestroy+0x3f/0x70 [ibuverbs] ibuverbscmdverbs+0x3e4/0xbb0 [ibuverbs] ? _pfxuverbsdestroydefhandler+0x10/0x10 [ibuverbs] ? _lockacquire+0x64e/0x2080 ? markheldlocks+0x48/0x80 ? findheldlock+0x2d/0xa0 ? lockacquire+0xc1/0x2f0 ? ibuverbsioctl+0xcb/0x170 [ibuverbs] ? _fgetfiles+0xc3/0x1b0 ibuverbsioctl+0xe7/0x170 [ibuverbs] ? ibuverbsioctl+0xcb/0x170 [ibuverbs] _x64sysioctl+0x1b0/0xa70 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f99c918b17b RSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX: 00007f99c918b17b RDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09: 000000000000bd7e R10: 00007f99c94c1c70 R11: 0000000000000246 R12: 00007ffc766d0530 R13: 000000000000001c R14: 0000000040246a80 R15: 0000000000000000 </TASK>(CVE-2025-21892)

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

perf/core: Order the PMU list to fix warning about unordered pmuctxlist

Syskaller triggers a warning due to prevepc->pmu != nextepc->pmu in perfeventswaptaskctxdata(). vmcore shows that two lists have the same perfeventpmucontext, but not in the same order.

The problem is that the order of pmuctxlist for the parent is impacted by the time when an event/PMU is added. While the order for a child is impacted by the event order in the pinnedgroups and flexiblegroups. So the order of pmuctxlist in the parent and child may be different.

To fix this problem, insert the perfeventpmucontext to its proper place after iteration of the pmuctx_list.

The follow testcase can trigger above warning:

# perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out & # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out

test.c

void main() { int count = 0; pid_t pid;

    printf("%d running\n", getpid());
    sleep(30);
    printf("running\n");

    pid = fork();
    if (pid == -1) {
            printf("fork error\n");
            return;
    }
    if (pid == 0) {
            while (1) {
                    count++;
            }
    } else {
            while (1) {
                    count++;
            }
    }

}

The testcase first opens an LBR event, so it will allocate taskctxdata, and then open tracepoint and software events, so the parent context will have 3 different perfeventpmucontexts. On inheritance, child ctx will insert the perfeventpmucontext in another order and the warning will trigger.

mingo: Tidied up the changelog.

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

ftrace: Avoid potential division by zero in functionstatshow()

Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case.

For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier.(CVE-2025-21898)

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

tracing: Fix bad hist from corrupting named_triggers list

The following commands causes a crash:

~# cd /sys/kernel/tracing/events/rcu/rcucallback ~# echo 'hist:name=bad:keys=commonpid:onmax(bogus).save(commonpid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=commonpid' > trigger

Because the following occurs:

eventtriggerwrite() { triggerprocessregex() { eventhisttrigger_parse() {

  data = event_trigger_alloc(..);

  event_trigger_register(.., data) {
    cmd_ops->reg(.., data, ..) [hist_register_trigger()] {
      data->ops->init() [event_hist_trigger_init()] {
        save_named_trigger(name, data) {
          list_add(&data->named_list, &named_triggers);
        }
      }
    }
  }

  ret = create_actions(); (return -EINVAL)
  if (ret)
    goto out_unreg;

[..] ret = histtriggerenable(data, ...) { listaddtailrcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!) [..] outunreg: eventhistunregister(.., data) { cmdops->unreg(.., data, ..) [histunregistertrigger()] { listforeachentry(iter, &file->triggers, list) { if (!histtriggermatch(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL

        test->ops->free(test) [event_hist_trigger_free()] {
          [..]
          if (data->name)
            del_named_trigger(data) {
              list_del(&data->named_list);  <<<<-- NEVER gets removed!
            }
          }
       }
     }

     [..]
     kfree(data); <<<-- frees item but it is still on list

The next time a hist with name is registered, it causes an u-a-f bug and the kernel can crash.

Move the code around such that if eventtriggerregister() succeeds, the next thing called is histtriggerenable() which adds it to the list.

A bunch of actions is called if getnamedtriggerdata() returns false. But that doesn't need to be called after eventtriggerregister(), so it can be moved up, allowing eventtriggerregister() to be called just before histtrigger_enable() keeping them together and allowing the file->triggers to be properly populated.(CVE-2025-21899)

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

wifi: cfg80211: regulatory: improve invalid hints checking

Syzbot keeps reporting an issue [1] that occurs when erroneous symbols sent from userspace get through into useralpha2[] via regulatoryhint_user() call. Such invalid regulatory hints should be rejected.

While a sanity check from commit 47caf685a685 ("cfg80211: regulatory: reject invalid hints") looks to be enough to deter these very cases, there is a way to get around it due to 2 reasons.

1) The way isalpha() works, symbols other than latin lower and upper letters may be used to determine a country/domain. For instance, greek letters will also be considered upper/lower letters and for such characters isalpha() will return true as well. However, ISO-3166-1 alpha2 codes should only hold latin characters.

2) While processing a user regulatory request, between regprocesshintuser() and regulatoryhintuser() there happens to be a call to queueregulatory_request() which modifies letters in request->alpha2[] with toupper(). This works fine for latin symbols, less so for weird letter characters from the second part of _ctype[].

Syzbot triggers a warning in isuserregdom_saved() by first sending over an unexpected non-latin letter that gets malformed by toupper() into a character that ends up failing isalpha() check.

Prevent this by enhancing isanalpha2() to ensure that incoming symbols are latin letters and nothing else.

[1] Syzbot report: ------------[ cut here ]------------ Unexpected user alpha2: A� WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 isuserregdomsaved net/wireless/reg.c:440 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restorealpha2 net/wireless/reg.c:3424 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restoreregulatorysettings+0x3c0/0x1e50 net/wireless/reg.c:3516 Modules linked in: CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: eventspowerefficient crdatimeoutwork RIP: 0010:isuserregdomsaved net/wireless/reg.c:440 [inline] RIP: 0010:restorealpha2 net/wireless/reg.c:3424 [inline] RIP: 0010:restoreregulatorysettings+0x3c0/0x1e50 net/wireless/reg.c:3516 ... Call Trace: <TASK> crdatimeoutwork+0x27/0x50 net/wireless/reg.c:542 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa65/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>(CVE-2025-21910)

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

slimbus: messaging: Free transaction ID in delayed interrupt scenario

In case of interrupt delay for any reason, slimdotransfer() returns timeout error but the transaction ID (TID) is not freed. This results into invalid memory access inside qcomslimngdrxmsgq_cb() due to invalid TID.

Fix the issue by freeing the TID in slimdotransfer() before returning timeout error to avoid invalid memory access.

Call trace: _memcpyfromio+0x20/0x190 qcomslimngdrxmsgqcb+0x130/0x290 [slimqcomngdctrl] vchancomplete+0x2a0/0x4a0 taskletactioncommon+0x274/0x700 taskletaction+0x28/0x3c stext+0x188/0x620 runksoftirqd+0x34/0x74 smpbootthreadfn+0x1d8/0x464 kthread+0x178/0x238 retfromfork+0x10/0x20 Code: aa0003e8 91000429 f100044a 3940002b (3800150b) ---[ end trace 0fe00bec2b975c99 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt.(CVE-2025-21914)

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

HID: hid-steam: Fix use-after-free when detaching device

When a hid-steam device is removed it must clean up the clienthdev used for intercepting hidraw access. This can lead to scheduling deferred work to reattach the input device. Though the cleanup cancels the deferred work, this was done before the clienthdev itself is cleaned up, so it gets rescheduled. This patch fixes the ordering to make sure the deferred work is properly canceled.(CVE-2025-21923)

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

nvme-tcp: fix potential memory corruption in nvmetcprecv_pdu()

nvmetcprecvpdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvmetcpverifyhdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.

Fix this by rejecting packets with an unexpected header length.(CVE-2025-21927)

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

HID: intel-ish-hid: Fix use-after-free issue in ishtphidremove()

The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtphidremove() function.

The function currently frees the driver_data directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, hid_destroy_device() uses driver_data when it calls hid_ishtp_set_feature() to power off the sensor, so freeing driver_data beforehand can result in accessing invalid memory.

This patch resolves the issue by storing the driver_data in a temporary variable before calling hid_destroy_device(), and then freeing the driver_data after the device is destroyed.(CVE-2025-21928)

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

rapidio: add check for rioaddnet() in rioscanalloc_net()

The return value of rioaddnet() should be checked. If it fails, putdevice() should be called to free the memory and give up the reference initialized in rioadd_net().(CVE-2025-21935)

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

drm/amd/display: Fix null check for pipectx->planestate in resourcebuildscaling_params

Null pointer dereference issue could occur when pipectx->planestate is null. The fix adds a check to ensure 'pipectx->planestate' is not null before accessing. This prevents a null pointer dereference.

Found by code review.

(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)(CVE-2025-21941)

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

gpio: aggregator: protect driver attr handlers against module unload

Both newdevicestore and deletedevicestore touch module global resources (e.g. gpioaggregatorlock). To prevent race conditions with module unload, a reference needs to be held.

Add trymoduleget() in these handlers.

For newdevicestore, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpioaggregatoridr but platformdeviceregister has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:

#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait

Starting with the following warning, several kinds of warnings will appear and the system may become unstable:

------------[ cut here ]------------ listdel corruption, ffff888103e2e980->next is LISTPOISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/listdebug.c:56 listdelentryvalidorreport+0xa3/0x120 [...] RIP: 0010:listdelentryvalidorreport+0xa3/0x120 [...] Call Trace: <TASK> ? _listdelentryvalidorreport+0xa3/0x120 ? _warn.cold+0x93/0xf2 ? _listdelentryvalidorreport+0xa3/0x120 ? reportbug+0xe6/0x170 ? _irqworkqueuelocal+0x39/0xe0 ? handlebug+0x58/0x90 ? excinvalidop+0x13/0x60 ? asmexcinvalidop+0x16/0x20 ? _listdelentryvalidorreport+0xa3/0x120 gpiodremovelookuptable+0x22/0x60 newdevicestore+0x315/0x350 [gpioaggregator] kernfsfopwriteiter+0x137/0x1f0 vfswrite+0x262/0x430 ksyswrite+0x60/0xd0 dosyscall64+0x6c/0x180 entrySYSCALL64afterhwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)

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

ksmbd: fix out-of-bounds in parsesecdesc()

If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size.(CVE-2025-21946)

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

LoongArch: Set hugetlb mmap base address aligned with pmd size

With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as:

kernel BUG at mm/hugetlb.c:5550! Oops - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001 t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmapvmas+0x130/0x218 ERA: 90000000004eaf1c _unmaphugepagerange+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Call Trace: [<90000000004eaf1c>] _unmaphugepagerange+0x6f4/0x7d0 [<9000000000485534>] unmapvmas+0x12c/0x218 [<9000000000494068>] exitmmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] doexit+0x294/0x898 [<900000000026aa30>] dogroupexit+0x30/0x98 [<900000000027bed4>] getsignal+0x83c/0x868 [<90000000002457b4>] archdosignalorrestart+0x54/0xfa0 [<90000000015795e8>] irqentryexittousermode+0xb8/0x138 [<90000000002572d0>] tlbdopagefault_1+0x114/0x1b4

The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run.

This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach genericgetunmappedarea{topdown} to handle hugetlb mappings").(CVE-2025-21949)

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

cifs: Fix integer overflow while processing acdirmax mount option

User-provided mount parameter acdirmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21963)

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

cifs: Fix integer overflow while processing acregmax mount option

User-provided mount parameter acregmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21964)

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

fbdev: hyperv_fb: Allow graceful removal of framebuffer

When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released.

[ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fbinfo.c:70 framebufferrelease+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? showregs+0x6c/0x80 [ 44.111295] ? _warn+0x8d/0x150 [ 44.111298] ? framebufferrelease+0x2c/0x40 [ 44.111300] ? reportbug+0x182/0x1b0 [ 44.111303] ? handlebug+0x6e/0xb0 [ 44.111306] ? excinvalidop+0x18/0x80 [ 44.111308] ? asmexcinvalidop+0x1b/0x20 [ 44.111311] ? framebufferrelease+0x2c/0x40 [ 44.111313] ? hvfbremove+0x86/0xa0 [hypervfb] [ 44.111315] vmbusremove+0x24/0x40 [hvvmbus] [ 44.111323] deviceremove+0x40/0x80 [ 44.111325] devicereleasedriverinternal+0x20b/0x270 [ 44.111327] ? busfind_device+0xb3/0xf0

Fix this by moving the release of framebuffer and assosiated memory to fbops.fbdestroy function, so that framebuffer framework handles it gracefully.

While we fix this, also replace manual registrations/unregistration of framebuffer with devmregisterframebuffer.(CVE-2025-21976)

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

drm/hyperv: Fix address space leak when Hyper-V DRM device is removed

When a Hyper-V DRM device is probed, the driver allocates MMIO space for the vram, and maps it cacheable. If the device removed, or in the error path for device probing, the MMIO space is released but no unmap is done. Consequently the kernel address space for the mapping is leaked.

Fix this by adding iounmap() calls in the device removal path, and in the error path during device probing.(CVE-2025-21978)

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

iscsiibft: Fix UBSAN shift-out-of-bounds warning in ibftattrshownic()

When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)

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

ksmbd: fix incorrect validation for numaces field of smbacl

parsedcal() validate numaces to allocate posixacestate_array.

if (numaces > ULONGMAX / sizeof(struct smb_ace *))

It is an incorrect validation that we can create an array of size ULONGMAX. smbacl has ->size field to calculate actual number of aces in request buffer size. Use this to check invalid num_aces.(CVE-2025-21994)

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

proc: fix UAF in procgetinode()

Fix race between rmmod and /proc/XXX's inode instantiation.

The bug is that pde->procops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless usepde/unuse_pde() pair has been used.

usepde/unusepde can be avoided (2 atomic ops!) because pde->procops never changes so information necessary for inode instantiation can be saved _before procregister() in PDE itself and used later, avoiding pde->procops->... dereference.

  rmmod                         lookup

sysdeletemodule proclookupde pdeget(de); procgetinode(dir->isb, de); mod->exit() procremove removeprocsubtree procentryrundown(de); freemodule(mod);

                           if (S_ISREG(inode->i_mode))
                         if (de->proc_ops->proc_read_iter)
                       --> As module is already freed, will trigger UAF

BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:procgetinode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proclookupde+0x11f/0x2e0 _lookupslow+0x188/0x350 walkcomponent+0x2ab/0x4f0 pathlookupat+0x120/0x660 filenamelookup+0x1ce/0x560 vfsstatx+0xac/0x150 _dosysnewstat+0x96/0x110 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

adobriyan@gmail.com: don't do 2 atomic ops on the common path

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

regulator: check that dummy regulator has been probed before using it

Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it.(CVE-2025-22008)

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

KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state

There are several problems with the way hyp code lazily saves the host's FPSIMD/SVE state, including:

• Host SVE being discarded unexpectedly due to inconsistent configuration of TIFSVE and CPACRELx.ZEN. This has been seen to result in QEMU crashes where SVE is used by memmove(), as reported by Eric Auger:

  https://issues.redhat.com/browse/RHEL-68997

• Host SVE state is discarded after modification by ptrace, which was an unintentional ptrace ABI change introduced with lazy discarding of SVE state.

• The host FPMR value can be discarded when running a non-protected VM, where FPMR support is not exposed to a VM, and that VM uses FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR before unbinding the host's FPSIMD/SVE/SME state, leaving a stale value in memory.

Avoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME state when loading a vCPU such that KVM does not need to save any of the host's FPSIMD/SVE/SME state. For clarity, fpsimdkvmprepare() is removed and the necessary call to fpsimdsaveandflushcpustate() is placed in kvmarchvcpuloadfp(). As 'fpsimdstate' and 'fpmr_ptr' should not be used, they are set to NULL; all uses of these will be removed in subsequent patches.

Historical problems go back at least as far as v5.17, e.g. erroneous assumptions about TIF_SVE being clear in commit:

8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving")

... and so this eager save+flush probably needs to be backported to ALL stable trees.(CVE-2025-22013)

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

tracing: Fix use-after-free in printgraphfunction_flags during tracer switching

Kairui reported a UAF issue in printgraphfunctionflags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutexunlock(&tracetypeslock)' in s_start(), and executing the following script:

$ echo functiongraph > currenttracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer

The root cause lies in the two calls to printgraphfunctionflags within printtraceline during each sshow():

• One through 'iter->trace->print_line()';
• Another through 'event->funcs->trace()', which is hidden in printtracefmt() before printtraceline returns.

Tracer switching only updates the former, while the latter continues to use the printline function of the old tracer, which in the script above is printgraphfunctionflags.

Moreover, when switching from the 'functiongraph' tracer to the 'timerlat' tracer, sstart only calls graphtraceclose of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.

To fix this issue, set 'iter->private' to NULL immediately after freeing it in graphtraceclose(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.

[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)

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

ksmbd: validate zero numsubauth before subauth is accessed

Access psid->subauth[psid->numsubauth - 1] without checking if numsubauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure numsubauth != 0 before sub_auth is accessed.(CVE-2025-22038)

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

LoongArch: Increase ARCHDMAMINALIGN up to 16

ARCHDMAMINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCHDMAMINALIGN as L1CACHEBYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16.(CVE-2025-22049)

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

ASoC: imx-card: Add NULL check in imxcardprobe()

devmkasprintf() returns NULL when memory allocation fails. Currently, imxcard_probe() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-22066)

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

ext4: goto right label 'outmmapsem' in ext4_setattr()

Otherwise, if ext4inodeattachjinode() fails, a hung task will happen because filemapinvalidateunlock() isn't called to unlock mapping->invalidatelock. Like this:

EXT4-fs error (device sda) in ext4setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds. Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373 taskflags:0x440140 flags:0x00000000 Call Trace: <TASK> _schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedulepreemptdisabled+0x15/0x30 rwsemdownreadslowpath+0x278/0x4c0 downread+0x59/0xb0 pagecacheraunbounded+0x65/0x1b0 filemapgetpages+0x124/0x3e0 filemapread+0x114/0x3d0 vfsread+0x297/0x360 ksysread+0x6c/0xe0 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2025-22120)

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

rjw: Subject edit, added Fixes:

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

drm/mediatek: dp: drmerr => deverr in HPD path to avoid NULL ptr

The function mtkdpwaithpdasserted() may be called before the mtk_dp->drm_dev pointer is assigned in mtkdpbridgeattach(). Specifically it can be called via this callpath: - mtkedpwaithpdasserted - [panel probe] - dpauxepprobe

Using "drm" level prints anywhere in this callpath causes a NULL pointer dereference. Change the error message directly in mtkdpwaithpdasserted() to deverr() to avoid this. Also change the error messages in mtkdpparsecapabilities(), which is called by mtkdpwaithpdasserted().

While touching these prints, also add the error code to them to make future debugging easier.(CVE-2025-38240)