The Linux Kernel, the operating system core itself.

Security Fix(es):

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

KVM: x86: Handle SRCU initialization failure during page track init

Check the return of initsrcustruct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller.

Move the call towards the beginning of kvmarchinit_vm. - Paolo

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

NFSD: prevent underflow in nfssvcdecodewriteargs()

Smatch complains:

fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
warn: no lower bound on 'args->len'

Change the type to unsigned to prevent this issue.(CVE-2022-49280)

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

tty: synclinkgt: Fix null-pointer-dereference in slgtclean()

When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat:

[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detachhdlcprotocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregisterhdlcdevice+0x16/0x30 [ 25.078481] slgtcleanup+0x157/0x9f0 [synclinkgt]

Fix this by checking whether the 'info->netdev' is a null pointer first.(CVE-2022-49307)

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

tty: goldfish: Use ttyportdestroy() to destroy port

In goldfishttyprobe(), the port initialized through ttyportinit() should be destroyed in error paths.In goldfishttyremove(), qtty->port also should be destroyed or else might leak resources.

Fix the above by calling ttyportdestroy().(CVE-2022-49399)

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

media: cx25821: Fix the warning when removing the module

When removing the module, we will get the following warning:

[ 14.746697] removeprocentry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 removeprocentry+0x389/0x3f0 [ 14.751611] RIP: 0010:removeprocentry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] <TASK> [ 14.759975] unregisterirqproc+0x14c/0x170 [ 14.760340] irqfreedescs+0x94/0xe0 [ 14.760640] mpunmapirq+0xb6/0x100 [ 14.760937] acpiunregistergsiioapic+0x27/0x40 [ 14.761334] acpipciirqdisable+0x1d3/0x320 [ 14.761688] pcidisabledevice+0x1ad/0x380 [ 14.762027] ? rawspinunlockirqrestore+0x2d/0x60 [ 14.762442] ? cx25821shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821finidev+0x48/0xc0 [cx25821] [ 14.763242] pcideviceremove+0x92/0x240

Fix this by freeing the irq before call pcidisabledevice().(CVE-2022-49525)

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

dm raid: fix accesses beyond end of raid member array

On dm-raid table load (using raidctr), dm-raid allocates an array rs->devs[rs->raiddisks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor.

In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6)

When accessing array members, rs->raiddisks must be used in control loops instead of the potentially larger value in rs->md.raiddisks. Otherwise it will cause memory access beyond the end of the rs->devs array.

Fix this by changing code that is prone to out-of-bounds access. Also fix validateraidredundancy() to validate all devices that are added. Also, use braces to help clean up raiditeratedevices().

The out-of-bounds memory accesses was discovered using KASAN.

This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).(CVE-2022-49674)

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

wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads

This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmfconstructchaninfo() and brcmfenablebw402g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmfsetupwiphybands() or brcmfcfg80211_attach().

Found by a modified version of syzkaller.

Crash Report from brcmfconstructchaninfo():

BUG: KASAN: slab-out-of-bounds in brcmfsetupwiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896

CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d printaddressdescription.constprop.0.cold+0x93/0x334 kasanreport.cold+0x83/0xdf brcmfsetupwiphybands+0x1238/0x1430 brcmfcfg80211attach+0x2118/0x3fd0 brcmfattach+0x389/0xd40 brcmfusbprobe+0x12de/0x1690 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 busforeachdrv+0x123/0x1a0 _deviceattach+0x207/0x330 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 usbsetconfiguration+0x984/0x1770 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 busforeachdrv+0x123/0x1a0 _deviceattach+0x207/0x330 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 usbnewdevice.cold+0x463/0xf66 hubevent+0x10d5/0x3330 processonework+0x873/0x13e0 workerthread+0x8b/0xd10 kthread+0x379/0x450 retfromfork+0x1f/0x30

Allocated by task 1896: kasansavestack+0x1b/0x40 _kasankmalloc+0x7c/0x90 kmemcachealloctrace+0x19e/0x330 brcmfsetupwiphybands+0x290/0x1430 brcmfcfg80211attach+0x2118/0x3fd0 brcmfattach+0x389/0xd40 brcmfusbprobe+0x12de/0x1690 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 busforeachdrv+0x123/0x1a0 _deviceattach+0x207/0x330 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 usbsetconfiguration+0x984/0x1770 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 busforeachdrv+0x123/0x1a0 _deviceattach+0x207/0x330 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 usbnewdevice.cold+0x463/0xf66 hubevent+0x10d5/0x3330 processonework+0x873/0x13e0 workerthread+0x8b/0xd10 kthread+0x379/0x450 retfrom_fork+0x1f/0x30

The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800)

Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Crash Report from brcmfenablebw40_2g():

---truncated---(CVE-2022-49740)

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

vcscreen: move load of struct vcdata pointer in vcs_read() to avoid UAF

After a call to consoleunlock() in vcsread() the vcdata struct can be freed by vcdeallocate(). Because of that, the struct vcdata pointer load must be done at the top of while loop in vcsread() to avoid a UAF when vcs_size() is called.

Syzkaller reported a UAF in vcs_size().

BUG: KASAN: use-after-free in vcssize (drivers/tty/vt/vcscreen.c:215) Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537

CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module Call Trace: <TASK> _asanreportload4noabort (mm/kasan/reportgeneric.c:350) vcssize (drivers/tty/vt/vcscreen.c:215) vcsread (drivers/tty/vt/vcscreen.c:415) vfsread (fs/readwrite.c:468 fs/readwrite.c:450) ... </TASK>

Allocated by task 1191: ... kmalloctrace (mm/slabcommon.c:1069) vcallocate (./include/linux/slab.h:580 ./include/linux/slab.h:720 drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108) coninstall (drivers/tty/vt/vt.c:3383) ttyinitdev (drivers/tty/ttyio.c:1301 drivers/tty/ttyio.c:1413 drivers/tty/ttyio.c:1390) ttyopen (drivers/tty/ttyio.c:2080 drivers/tty/ttyio.c:2126) chrdevopen (fs/chardev.c:415) dodentryopen (fs/open.c:883) vfs_open (fs/open.c:1014) ...

Freed by task 1548: ... kfree (mm/slabcommon.c:1021) vcportdestruct (drivers/tty/vt/vt.c:1094) ttyportdestructor (drivers/tty/ttyport.c:296) ttyportput (drivers/tty/ttyport.c:312) vtdisallocateall (drivers/tty/vt/vtioctl.c:662 (discriminator 2)) vtioctl (drivers/tty/vt/vtioctl.c:903) ttyioctl (drivers/tty/ttyio.c:2776) ...

The buggy address belongs to the object at ffff888113747800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 424 bytes inside of 1024-byte region [ffff888113747800, ffff888113747c00)

The buggy address belongs to the physical page: page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x113740 head:00000000b3fe6c7c order:3 compoundmapcount:0 subpagesmapcount:0 compound_pincount:0 anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Disabling lock debugging due to kernel taint(CVE-2023-52973)

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

ext4: fix uninitialized ratelimitstate->lock access in _ext4fillsuper()

In the following concurrency we will access the uninitialized rs->lock:

ext4fillsuper ext4registersysfs // sysfs registered msgratelimitintervalms // Other processes modify rs->interval to // non-zero via msgratelimitintervalms ext4orphancleanup ext4msg(sb, KERNINFO, "Errors on filesystem, " ext4msg _ratelimit(&(EXT4SB(sb)->smsgratelimitstate) if (!rs->interval) // do nothing if interval is 0 return 1; rawspintrylockirqsave(&rs->lock, flags) rawspintrylock(lock) rawspintrylock _rawspintrylock spinacquire(&lock->depmap, 0, 1, RETIP) lockacquire _lockacquire registerlockclass assignlockkey dumpstack(); ratelimitstateinit(&sbi->smsgratelimitstate, 5 * HZ, 10); rawspinlock_init(&rs->lock); // init rs->lock here

and get the following dump_stack:

========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dumpstacklvl+0xc5/0x170 dumpstack+0x18/0x30 registerlockclass+0x740/0x7c0 lockacquire+0x69/0x13a0 lockacquire+0x120/0x450 _rawspintrylock+0x98/0xd0 _ratelimit+0xf6/0x220 _ext4msg+0x7f/0x160 [ext4] ext4orphancleanup+0x665/0x740 [ext4] _ext4fillsuper+0x21ea/0x2b10 [ext4] ext4fillsuper+0x14d/0x360 [ext4]

[...]

Normally interval is 0 until smsgratelimitstate is initialized, so _ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msgratelimitintervalms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.(CVE-2024-40998)

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:

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcrelease_getacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? _warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? _pfxsvcprocesscommon+0x10/0x10 ? _rcureadunlock+0x69/0xa0 ? _pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? _pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panicon_warn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.(CVE-2025-21796)

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)