The Linux Kernel, the operating system core itself.

Security Fix(es):

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

blk-mq: don't touch ->tagset in blkmqgetsqhctx

blkmqrunhwqueues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blkcleanupqueue() returns.

So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.(CVE-2022-49377)

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

macsec: fix UAF bug for real_dev

Create a new macsec device but not get reference to realdev. That can not ensure that realdev is freed after macsec. That will trigger the UAF bug for real_dev as following:

================================================================== BUG: KASAN: use-after-free in macsecgetiflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsecgetiflink+0x5f/0x70 drivers/net/macsec.c:3662 devgetiflink+0x73/0xe0 net/core/dev.c:637 defaultoperstate net/core/linkwatch.c:42 [inline] rfc2863policy+0x233/0x2d0 net/core/linkwatch.c:54 linkwatchdodev+0x2a/0x150 net/core/link_watch.c:161

Allocated by task 22209: ... allocnetdevmqs+0x98/0x1100 net/core/dev.c:10549 rtnlcreatelink+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748

Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 devicerelease+0x9f/0x240 drivers/base/core.c:2229 kobjectcleanup lib/kobject.c:673 [inline] kobjectrelease lib/kobject.c:704 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1c8/0x540 lib/kobject.c:721 netdevrun_todo+0x72e/0x10b0 net/core/dev.c:10327

After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackholenetdev"), we can add devholdtrack() in macsecdevinit() and devputtrack() in macsecfree_netdev() to fix the problem.(CVE-2022-49390)

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

netfilter: nf_tables: don't skip expired elements during walk

There is an asymmetry between commit/abort and preparation phase if the following conditions are met:

1. set is a verdict map ("1.2.3.4 : jump foo")
2. timeouts are enabled

In this case, following sequence is problematic:

1. element E in set S refers to chain C
2. userspace requests removal of set S
3. kernel does a set walk to decrement chain->use count for all elements from preparation phase
4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)

If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed.

Then, when set is culled, ->destroy callback will zap the element via nftablessetelemdestroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure.

Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.(CVE-2023-52924)

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

powerpc/mm/fault: Fix kfence page fault reporting

copyfromkernelnofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copyfromkernelnofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.

Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within _dopagefault().

This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M

Some example false negatives:

=============================== BUG: KFENCE: invalid read in copyfromkernelnofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copyfromkernelnofault+0x9c/0x1a0 0xc00000000665f950 readkcoreiter+0x57c/0xa04 procregreaditer+0xe4/0x16c vfsread+0x320/0x3ec ksysread+0x90/0x154 systemcallexception+0x120/0x310 systemcallvectoredcommon+0x15c/0x2ec

BUG: KFENCE: use-after-free read in copyfromkernelnofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copyfromkernelnofault+0x9c/0x1a0 0xc00000000665f950 readkcoreiter+0x57c/0xa04 procregreaditer+0xe4/0x16c vfsread+0x320/0x3ec ksysread+0x90/0x154 systemcallexception+0x120/0x310 systemcallvectoredcommon+0x15c/0x2ec(CVE-2024-56678)

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

nfsd: fix nfs4openowner leak when concurrent nfsd4open occur

The action force umount(umount -f) will attempt to kill all rpctask even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpctask to nfs server.

               NFS CLIENT

thread1 thread2 open("file") ... nfs4doopen nfs4doopen _nfs4openandgetstate _nfs4procopen nfs4runopentask /* rpctask1 */ rpcruntask rpcwaitforcompletion_task

                                umount -f
                                nfs_umount_begin
                                 rpc_killall_tasks
                                  rpc_signal_task
 rpc_task1 been wakeup
 and return -512

nfs4doopen // while loop ... nfs4runopentask /* rpctask2 */ rpcruntask rpcwaitforcompletion_task

While processing an open request, nfsd will first attempt to find or allocate an nfs4openowner. If it finds an nfs4openowner that is not marked as NFS4OOCONFIRMED, this nfs4openowner will released. Since two rpctask can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.

                NFS SERVER

nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads

nfsd4open nfsd4processopen1 findorallocopenstateowner // alloc oo1, stateid1 nfsd4open nfsd4processopen1 findorallocopenstateowner // find oo1, without NFS4OOCONFIRMED releaseopenowner unhashopenownerlocked listdelinit(&oo->ooperclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2

nfsd4processopen2 initopenstateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4getvfsfile // alloc nfsdfile1 and nfsdfilemark1 // all LEAK!!!

                     nfsd4_process_open2
                     ...

                                write_threads
                                 ...
                                 nfsd_destroy_serv
                                  nfsd_shutdown_net
                                   nfs4_state_shutdown_net
                                    nfs4_state_destroy_net
                                     destroy_client
                                      __destroy_client
                                      // won't find oo1!!!
                                 nfsd_shutdown_generic
                                  nfsd_file_cache_shutdown
                                   kmem_cache_destroy
                                   for nfsd_file_slab
                                   and nfsd_file_mark_slab
                                   // bark since nfsd_file1
                                   // and nfsd_file_mark1
                                   // still alive

======================================================================= BUG nfsdfile (Not tainted): Objects remaining in nfsdfile on

_kmemcache_shutdown()

Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)

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

xfrm: state: fix out-of-bounds read during lookup

lookup and resize can run in parallel.

The xfrmstatehash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.

rehash does: rcuassignpointer(net->xfrm.statebydst, ndst) [..] net->xfrm.statehmask = nhashmask;

While state lookup does: h = xfrmdsthash(net, daddr, saddr, tmpl->reqid, encapfamily); hlistforeachentryrcu(x, net->xfrm.statebydst + h, bydst) {

This is only safe in case the update to statebydst is larger than net->xfrm.xfrmstate_hmask (or if the lookup function gets serialized via state spinlock again).

Fix this by prefetching statehmask and the associated pointers. The xfrmstatehashgeneration seqlock retry will ensure that the pointer and the hmask will be consistent.

The existing helpers, like xfrmdsthash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.

xfrmstatelookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)

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

rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read

The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.

Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)

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

vfio/platform: check the bounds of read/write syscalls

count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)

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

atm: Fix NULL pointer dereference

When MPOAcacheimposrcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holdingtime are NULL. Because there is only for the situation where entry is NULL and holdingtime exists, it can be passed when both entry and holdingtime are NULL. If these are NULL, the entry will be passd to egcacheput() as parameter and it is referenced by entry->use code in it.

kasan log:

[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I [ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102 [ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 3.319298] RIP: 0010:egcacheremoveentry+0xa5/0x470 [ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80 [ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006 [ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e [ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030 [ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88 [ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15 [ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068 [ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000 [ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0 [ 3.326430] Call Trace: [ 3.326725] <TASK> [ 3.326927] ? dieaddr+0x3c/0xa0 [ 3.327330] ? excgeneralprotection+0x161/0x2a0 [ 3.327662] ? asmexcgeneralprotection+0x26/0x30 [ 3.328214] ? vprintkemit+0x15e/0x420 [ 3.328543] ? egcacheremoveentry+0xa5/0x470 [ 3.328910] ? egcacheremoveentry+0x9a/0x470 [ 3.329294] ? pfxegcacheremoveentry+0x10/0x10 [ 3.329664] ? consoleunlock+0x107/0x1d0 [ 3.329946] ? _pfxconsoleunlock+0x10/0x10 [ 3.330283] ? dosyscall64+0xa6/0x1a0 [ 3.330584] ? entrySYSCALL64afterhwframe+0x47/0x7f [ 3.331090] ? _pfxprbreadvalid+0x10/0x10 [ 3.331395] ? downtrylock+0x52/0x80 [ 3.331703] ? vprintkemit+0x15e/0x420 [ 3.331986] ? _pfxvprintkemit+0x10/0x10 [ 3.332279] ? downtrylock+0x52/0x80 [ 3.332527] ? printk+0xbf/0x100 [ 3.332762] ? _pfxprintk+0x10/0x10 [ 3.333007] ? rawwritelockirq+0x81/0xe0 [ 3.333284] ? pfxrawwritelockirq+0x10/0x10 [ 3.333614] msgfrommpoad+0x1185/0x2750 [ 3.333893] ? buildskbaround+0x27b/0x3a0 [ 3.334183] ? _pfxmsgfrommpoad+0x10/0x10 [ 3.334501] ? _allocskb+0x1c0/0x310 [ 3.334809] ? _pfxallocskb+0x10/0x10 [ 3.335283] ? rawspinlock+0xe0/0xe0 [ 3.335632] ? finishwait+0x8d/0x1e0 [ 3.335975] vccsendmsg+0x684/0xba0 [ 3.336250] ? pfxvccsendmsg+0x10/0x10 [ 3.336587] ? _pfxautoremovewakefunction+0x10/0x10 [ 3.337056] ? fdget+0x176/0x3e0 [ 3.337348] _syssendto+0x4a2/0x510 [ 3.337663] ? _pfxsyssendto+0x10/0x10 [ 3.337969] ? ioctlhasperm.constprop.0.isra.0+0x284/0x400 [ 3.338364] ? sockioctl+0x1bb/0x5a0 [ 3.338653] ? rseqhandlenotifyresume+0x825/0xd20 [ 3.339017] ? _pfxsockioctl+0x10/0x10 [ 3.339316] ? _pfxrseqhandlenotifyresume+0x10/0x10 [ 3.339727] ? selinuxfileioctl+0xa4/0x260 [ 3.340166] _x64syssendto+0xe0/0x1c0 [ 3.340526] ? syscallexittousermode+0x123/0x140 [ 3.340898] dosyscall64+0xa6/0x1a0 [ 3.341170] entrySYSCALL64after_hwframe+0x77/0x7f [ 3.341533] RIP: 0033:0x44a380 [ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00 [
---truncated---(CVE-2025-22018)

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

udp: Fix memory accounting leak.

Matt Dowling reported a weird UDP memory usage issue.

Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.

We can reproduce the issue with the script below [0]:

1. /proc/net/sockstat reports 0 pages

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 0

2. Run the script till the report reaches 524,288

   python3 test.py & sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 3 mem 524288 <-- (INTMAX + 1) >> PAGESHIFT

3. Kill the socket and confirm the number never drops

   pkill python3 && sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 524288

4. (necessary since v6.0) Trigger protomemorypcpu_drain()

   python3 test.py & sleep 1 && pkill python3

5. The number doubles

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 1048577

The application set INTMAX to SORCVBUF, which triggered an integer overflow in udprmemrelease().

When a socket is close()d, udpdestructcommon() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.

The total size is then passed to udprmemrelease() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.

Then, the released amount is calculated as follows:

1) Add size to sk->skforwardalloc. 2) Round down sk->skforwardalloc to the nearest lower multiple of PAGESIZE and assign it to amount. 3) Subtract amount from sk->skforwardalloc. 4) Pass amount >> PAGESHIFT to _skmemreduceallocated().

When the issue occurred, the total in udpdestructcommon() was 2147484480 (INTMAX + 833), which was cast to -2147482816 in udprmem_release().

At 1) sk->skforwardalloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inetsockdestruct(). However, udpmemoryallocated ends up doubling at 4).

Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memoryallocated"), memory usage no longer doubles immediately after a socket is close()d because _skmemreduceallocated() caches the amount in udpmemorypercpufwalloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.

This issue makes further memory allocation fail once the socket's sk->skrmemalloc exceeds net.ipv4.udprmemmin, resulting in packet drops.

To prevent this issue, let's use unsigned int for the calculation and call skforwardalloc_add() only once for the small delta.

Note that firstpacketlength() also potentially has the same problem.

SORCVBUFFORCE = 33 INTMAX = (2 ** 31) - 1

s = socket(AFINET, SOCKDGRAM) s.bind(('', 0)) s.setsockopt(SOLSOCKET, SORCVBUFFORCE, INT_MAX)

c = socket(AFINET, SOCKDGRAM) c.connect(s.getsockname())

data = b'a' * 100

while True: c.send(data)(CVE-2025-22058)

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

rtnetlink: Allocate vfinfo size for VF GUIDs when supported

Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long

Kernel warning:

------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnlgetlink+0x586/0x5a0 Modules linked in: xtconntrack xtMASQUERADE nfnetlink xtaddrtype iptablenat nfnat brnetfilter overlay mlx5ib macsec mlx5core tls rpcrdma rdmaucm ibuverbs ibiser libiscsi scsitransportiscsi ibumad rdmacm iwcm ibipoib fuse ibcm ibcore CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnlgetlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0xa5/0x230 ? rtnlgetlink+0x586/0x5a0 ? reportbug+0x22d/0x240 ? handlebug+0x53/0xa0 ? excinvalidop+0x14/0x50 ? asmexcinvalidop+0x16/0x20 ? skbtrim+0x6a/0x80 ? rtnlgetlink+0x586/0x5a0 ? _pfxrtnlgetlink+0x10/0x10 ? rtnetlinkrcvmsg+0x1e5/0x860 ? _pfxmutexlock+0x10/0x10 ? rcuiswatching+0x34/0x60 ? pfxlockacquire+0x10/0x10 ? stacktracesave+0x90/0xd0 ? filterirqstacks+0x1d/0x70 ? kasansavestack+0x30/0x40 ? kasansavestack+0x20/0x40 ? kasansavetrack+0x10/0x30 rtnetlinkrcvmsg+0x21c/0x860 ? entrySYSCALL64afterhwframe+0x76/0x7e ? _pfxrtnetlinkrcvmsg+0x10/0x10 ? archstackwalk+0x9e/0xf0 ? rcuiswatching+0x34/0x60 ? lockacquire+0xd5/0x410 ? rcuiswatching+0x34/0x60 netlinkrcvskb+0xe0/0x210 ? _pfxrtnetlinkrcvmsg+0x10/0x10 ? _pfxnetlinkrcvskb+0x10/0x10 ? rcuiswatching+0x34/0x60 ? _pfxnetlinklookup+0x10/0x10 ? lockrelease+0x62/0x200 ? netlinkdelivertap+0xfd/0x290 ? rcuiswatching+0x34/0x60 ? lockrelease+0x62/0x200 ? netlinkdelivertap+0x95/0x290 netlinkunicast+0x31f/0x480 ? pfxnetlinkunicast+0x10/0x10 ? rcuiswatching+0x34/0x60 ? lockacquire+0xd5/0x410 netlinksendmsg+0x369/0x660 ? lockrelease+0x62/0x200 ? _pfxnetlinksendmsg+0x10/0x10 ? importubuf+0xb9/0xf0 ? _importiovec+0x254/0x2b0 ? lockrelease+0x62/0x200 ? _pfxnetlinksendmsg+0x10/0x10 _syssendmsg+0x559/0x5a0 ? pfxsyssendmsg+0x10/0x10 ? _pfxcopymsghdrfromuser+0x10/0x10 ? rcuiswatching+0x34/0x60 ? doreadfault+0x213/0x4a0 ? rcuiswatching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfxsyssendmsg+0x10/0x10 ? dofault+0x2cc/0x6f0 ? handleptefault+0x2e3/0x3d0 ? _pfxhandleptefault+0x10/0x10 ---truncated---(CVE-2025-22075)

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

isofs: Prevent the use of too small fid

syzbot reported a slab-out-of-bounds Read in isofsfhto_parent. [1]

The handlebytes value passed in by the reproducing program is equal to 12. In handletopath(), only 12 bytes of memory are allocated for the structure filehandle->fhandle member, which causes an out-of-bounds access when accessing the member parentblock of the structure isofsfid in isofs, because accessing parentblock requires at least 16 bytes of fhandle. Here, fhlen is used to indirectly confirm that the value of handlebytes is greater than 3 before accessing parentblock.

[1] BUG: KASAN: slab-out-of-bounds in isofsfhtoparent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: showstack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xe4/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0x198/0x550 mm/kasan/report.c:521 kasanreport+0xd8/0x138 mm/kasan/report.c:634 _asanreportload4noabort+0x20/0x2c mm/kasan/reportgeneric.c:380 isofsfhtoparent+0x1b8/0x210 fs/isofs/export.c:183 exportfsdecodefhraw+0x2dc/0x608 fs/exportfs/expfs.c:523 dohandletopath+0xa0/0x198 fs/fhandle.c:257 handletopath fs/fhandle.c:385 [inline] dohandleopen+0x8cc/0xb8c fs/fhandle.c:403 _dosysopenbyhandleat fs/fhandle.c:443 [inline] _sesysopenbyhandleat fs/fhandle.c:434 [inline] _arm64sysopenbyhandleat+0x80/0x94 fs/fhandle.c:434 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t64synchandler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Allocated by task 6466: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x40/0x78 mm/kasan/common.c:68 kasansaveallocinfo+0x40/0x50 mm/kasan/generic.c:562 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0xac/0xc4 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4294 [inline] _kmallocnoprof+0x32c/0x54c mm/slub.c:4306 kmallocnoprof include/linux/slab.h:905 [inline] handletopath fs/fhandle.c:357 [inline] dohandleopen+0x5a4/0xb8c fs/fhandle.c:403 _dosysopenbyhandleat fs/fhandle.c:443 [inline] _sesysopenbyhandleat fs/fhandle.c:434 [inline] _arm64sysopenbyhandleat+0x80/0x94 fs/fhandle.c:434 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t64synchandler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)

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

net_sched: hfsc: Fix a UAF vulnerability in class handling

This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfscchangeclass() when working with certain child qdiscs like netem or codel.

The vulnerability works as follows: 1. hfscchangeclass() checks if a class has packets (q.qlen != 0) 2. It then calls qdiscpeeklen(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free

The fix adds a second queue length check after qdiscpeeklen() to verify the queue wasn't emptied.(CVE-2025-37797)

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

net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc

As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).

This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)

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

schhfsc: Fix qlen accounting bug when using peek in hfscenqueue()

When enqueuing the first packet to an HFSC class, hfscenqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdiscpeekdequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisctreereducebacklog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.

This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)

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

net_sched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.

The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].

By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].

However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfscenqueue whether the class is already in the eltree whenever the HFSCRSC flag is set.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)

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

net/tipc: fix slab-use-after-free Read in tipcaeadencrypt_done

Syzbot reported a slab-use-after-free with the following call trace:

================================================================== BUG: KASAN: slab-use-after-free in tipcaeadencrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25

Call Trace: kasanreport+0xd9/0x110 mm/kasan/report.c:601 tipcaeadencryptdone+0x4bd/0x510 net/tipc/crypto.c:840 cryptorequestcomplete include/crypto/algapi.h:266 aeadrequestcomplete include/crypto/internal/aead.h:85 cryptdaeadcrypt+0x3b8/0x750 crypto/cryptd.c:772 cryptorequestcomplete include/crypto/algapi.h:266 cryptdqueueworker+0x131/0x200 crypto/cryptd.c:181 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231

Allocated by task 8355: kzallocnoprof include/linux/slab.h:778 tipccryptostart+0xcc/0x9e0 net/tipc/crypto.c:1466 tipcinitnet+0x2dd/0x430 net/tipc/core.c:72 opsinit+0xb9/0x650 net/core/netnamespace.c:139 setupnet+0x435/0xb40 net/core/netnamespace.c:343 copynetns+0x2f0/0x670 net/core/netnamespace.c:508 createnewnamespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unsharensproxynamespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksysunshare+0x419/0x970 kernel/fork.c:3323 _dosysunshare kernel/fork.c:3394

Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipccryptostop+0x23c/0x500 net/tipc/crypto.c:1539 tipcexitnet+0x8c/0x110 net/tipc/core.c:119 opsexitlist+0xb0/0x180 net/core/netnamespace.c:173 cleanupnet+0x5b7/0xbf0 net/core/netnamespace.c:640 processone_work+0x9fb/0x1b60 kernel/workqueue.c:3231

After freed the tipccrypto tx by delete namespace, tipcaeadencryptdone may still visit it in cryptdqueueworker workqueue.

I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key thisisamasterkey master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1

The key of reproduction is that, simdaeadencrypt is interrupted, leading to cryptosimdusable() return false. Thus, the cryptdqueueworker is triggered, and the tipc_crypto tx will be visited.

tipcdisctimeout tipcbearerxmitskb tipccryptoxmit tipcaeadencrypt cryptoaeadencrypt // encrypt() simdaeadencrypt // cryptosimdusable() is false child = &ctx->cryptdtfm->base;

simdaeadencrypt cryptoaeadencrypt // encrypt() cryptdaeadencryptenqueue cryptdaeadenqueue cryptdenqueuerequest // trigger cryptdqueueworker queueworkon(smpprocessorid(), cryptdwq, &cpu_queue->work)

Fix this by holding net reference count before encrypt.(CVE-2025-38052)

A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)

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

tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer

The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPCNLUDPGETREMOTEIP with media name set to tun

tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syztun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipcudpnldump_remoteip+0x4a4/0x8f0

the ub was in fact a struct dev.

when bid != 0 && skipcnt != 0, bearerlist[bid] may be NULL or other media when other thread changes it.

fix this by checking media_id.(CVE-2025-38184)

A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)

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

md/raid1: Fix stack memory use after return in raid1_reshape

In the raid1reshape function, newpool is allocated on the stack and assigned to conf->r1biopool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.

Example access path:

raid1reshape() { // newpool is on the stack mempoolt newpool, oldpool; // initialize newpool.wait.head to stack address mempoolinit(&newpool, ...); conf->r1biopool = newpool; }

raid1readrequest() or raid1writerequest() { allocr1bio() { mempoolalloc() { // if pool->alloc fails removeelement() { --pool->currnr; } } } }

mempoolfree() { if (pool->currnr < pool->minnr) { // pool->wait.head is a stack address // wakeup() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }

Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)

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

tipc: Fix use-after-free in tipcconnclose().

syzbot reported a null-ptr-deref in tipcconnclose() during netns dismantle. [0]

tipctopsrvstop() iterates tipcnet(net)->topsrv->connidr and calls tipcconnclose() for each tipc_conn.

The problem is that tipcconnclose() is called after releasing the IDR lock.

At the same time, there might be tipcconnrecvwork() running and it could call tipcconnclose() for the same tipcconn and release its last ->kref.

Once we release the IDR lock in tipctopsrvstop(), there is no guarantee that the tipc_conn is alive.

Let's hold the ref before releasing the lock and put the ref after tipcconnclose() in tipctopsrvstop().

Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanupnet Call Trace: _dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x1fc/0x2ef lib/dumpstack.c:118 printaddressdescription.cold+0x54/0x219 mm/kasan/report.c:256 kasanreporterror.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasanreport mm/kasan/report.c:412 [inline] _asanreportload8noabort+0x88/0x90 mm/kasan/report.c:433 tipcconnclose+0x122/0x140 net/tipc/topsrv.c:165 tipctopsrvstop net/tipc/topsrv.c:701 [inline] tipctopsrvexitnet+0x27b/0x5c0 net/tipc/topsrv.c:722 opsexitlist+0xa5/0x150 net/core/netnamespace.c:153 cleanupnet+0x3b4/0x8b0 net/core/netnamespace.c:553 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

Allocated by task 23: kmemcachealloctrace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipcconnalloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipctopsrvaccept+0x1b5/0x280 net/tipc/topsrv.c:470 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

Freed by task 23: _cachefree mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipcconnkrefrelease net/tipc/topsrv.c:150 [inline] krefput include/linux/kref.h:70 [inline] connput+0x2cd/0x3a0 net/tipc/topsrv.c:155 processonework+0x864/0x1570 kernel/workqueue.c:2153 workerthread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 retfromfork+0x24/0x30 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)

A vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)

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

tracing: Add downwrite(traceevent_sem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.

If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.

The addition of the event should take the traceeventsem for write while it adds the new event.

Also add a lockdepassertheld() on that semaphore in _traceaddeventdirs() as it iterates the list.(CVE-2025-38539)

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

perf/core: Exit early on perf_mmap() fail

When perfmmap() fails to allocate a buffer, it still invokes the eventmapped() callback of the related event. On X86 this might increase the perfrdpmcallowed reference counter. But nothing undoes this as perfmmapclose() is never called in this case, which causes another reference count leak.

Return early on failure to prevent that.(CVE-2025-38565)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)