The Linux Kernel, the operating system core itself.

Security Fix(es):

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

mmc: vub300: fix return value check of mmcaddhost()

mmcaddhost() may return error, if we ignore its return value, the memory that allocated in mmcallochost() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path.

So fix this by checking the return value and goto error path which will call mmcfreehost(), besides, the timer added before mmcaddhost() needs be del.

And this patch fixes another missing call mmcfreehost() if usbcontrolmsg() fails.(CVE-2022-50251)

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

PNP: fix name memory leak in pnpallocdev()

After commit 1fa5ae857bb1 ("driver core: get rid of struct device's busid string array"), the name of device is allocated dynamically, move devsetname() after pnpadd_id() to avoid memory leak.(CVE-2022-50278)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-50290)

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

mmc: rtsxusbsdmmc: fix return value check of mmcaddhost()

mmcaddhost() may return error, if we ignore its return value, the memory that allocated in mmcallochost() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path.

So fix this by checking the return value and calling mmcfreehost() in the error path, besides, ledclassdevunregister() and pmruntimedisable() also need be called.(CVE-2022-50347)

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

Bluetooth: L2CAP: Fix user-after-free

This uses l2capchanholdunlesszero() after calling _l2capgetchanblah() to prevent the following trace:

Bluetooth: l2capcore.c:static void l2capchan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d

Bluetooth: parent 00000000ae861c08

BUG: KASAN: use-after-free in _mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in _mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in _mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389(CVE-2022-50386)

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

NFSD: Protect against send buffer overflow in NFSv2 READ

Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time.

Once an RPC Call has been received, svcprocess() updates svcrqst::rqres to describe the part of rqpages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large.

A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.(CVE-2022-50410)

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

scsi: fcoe: Fix transport not deattached when fcoeifinit() fails

fcoeinit() calls fcoetransportattach(&fcoeswtransport), but when fcoeifinit() fails, &fcoeswtransport is not detached and leaves freed &fcoeswtransport on fcoetransports list. This causes panic when reinserting module.

BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoetransportattach+0xe1/0x230 [libfcoe] Call Trace: <TASK> dooneinitcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ...(CVE-2022-50414)

In the Linux kernel, the mxm-wmi driver's mxmwmicallmxds|mx function has a memory leak vulnerability. The ACPI buffer memory (out.pointer) returned by wmievaluatemethod() is not freed after the call, which leads to memory leak. Since the method results in ACPI buffer is not used, passing NULL to wmievaluate_method() fixes the memory leak.(CVE-2022-50521)

In the Linux kernel, a vulnerability exists in the VME subsystem's fakeinit() function. The _rootdeviceregister() function may fail but the error is not caught, which can cause failure when unregistering vme_root during exit, leading to null pointer dereference and potential system crash.(CVE-2022-50538)

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

media: az6007: Fix null-ptr-deref in az6007i2cxfer()

In az6007i2cxfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007i2cxfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027i2cxfer()")(CVE-2023-53220)

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

wifi: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiexprocessmgmtpacket, mwifiexprocessstarxpacket and mwifiexprocessuaprxpacket, mwifiexuapqueuebridgedpkt and mwifiexprocessrxpacket not out-of-bounds access the skb->data buffer.(CVE-2023-53226)

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

wifi: mac80211: fix invalid drvstaprercuremove calls for non-uploaded sta

Avoid potential data corruption issues caused by uninitialized driver private data structures.(CVE-2023-53229)

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

watchdog: Fix kmemleak in watchdogcdevregister

kmemleak reports memory leaks in watchdogdevregister, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] _kmemcacheallocnode+0x157/0x220 [<000000006a389304>] kmalloctrace+0x21/0x110 [<000000008d640eea>] watchdogdevregister+0x4e/0x780 [watchdog] [<0000000053c9f248>] _watchdogregisterdevice+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdogregisterdevice+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] dooneinitcall+0xcb/0x4d0 [<00000000b98be325>] doinitmodule+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ...

unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] _kmemcacheallocnode+0x157/0x220 [<00000000486ab89b>] _kmallocnodetrackcaller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintfconst+0x55/0x180 [<000000009276cb7f>] kobjectsetnamevargs+0x56/0x150 [<00000000a92e820b>] devsetname+0xab/0xe0 [<00000000cec812c6>] watchdogdevregister+0x285/0x780 [watchdog] [<0000000053c9f248>] _watchdogregisterdevice+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdogregisterdevice+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] dooneinitcall+0xcb/0x4d0 [<00000000b98be325>] doinitmodule+0x1ca/0x5f0 [<0000000046d08e7c>] loadmodule+0x6133/0x70f0 ...

The reason is that putdevice is not be called if cdevdevice_add fails and wdd->id != 0.

watchdogcdevregister wddata = kzalloc [1] err = devsetname [2] .. err = cdevdevice_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked

To fix it, call put_device in all wdd->id cases.(CVE-2023-53234)

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

kobject: Add sanity check for kset->kobj.ktype in kset_register()

When I register a kset in the following way: static struct kset mykset; kobjectsetname(&mykset.kobj, "mykset"); ret = ksetregister(&my_kset);

A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobjectgetownership+0xc/0x34 [ 4453.817493] kobjectaddinternal+0x98/0x274 [ 4453.822005] ksetregister+0x5c/0xb4 [ 4453.825820] mykobjinit+0x44/0x1000 [mykset] ... ...

Because I didn't initialize my_kset.kobj.ktype.

According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype.

So add sanity check to make sure kset->kobj.ktype is not NULL.(CVE-2023-53480)

A vulnerability was found in the Linux kernel's drm/i915/gvt module. The issue occurs during vgpu debugfs cleanup process. When destroying vgpu, the code doesn't properly check if the root debugfs is available. In remove cases, the drm minor's debugfs root might already be destroyed, which leads to kernel NULL pointer dereference and causes kernel oops as shown in the description.(CVE-2023-53625)

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

scsi: libiscsi: Initialize iscsiconn->dddata only if memory is allocated

In case of an ibfastregmr allocation failure during iSER setup, the machine hits a panic because iscsiconn->dddata is initialized unconditionally, even when no memory is allocated (ddsize == 0). This leads invalid pointer dereference during connection teardown.

Fix by setting iscsiconn->dddata only if memory is actually allocated.

Panic trace:

iser: isercreatefastregdesc: Failed to allocate ibfastregmr err=-12 iser: iserallocrxdescriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swakeuplocked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsiiserconnstop+0x88/0xb0 [ibiser] iscsistopconn+0x66/0xc0 [scsitransportiscsi] iscsiifstopconn+0x14a/0x150 [scsitransportiscsi] iscsiifrx+0x1135/0x1834 [scsitransportiscsi] ? netlinklookup+0x12f/0x1b0 ? netlinkdelivertap+0x2c/0x200 netlinkunicast+0x1ab/0x280 netlinksendmsg+0x257/0x4f0 ? _copyfromuser+0x29/0x60 socksendmsg+0x5f/0x70(CVE-2025-38700)

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

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in _getblkslow() due to requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)

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

tracing: Limit access to parser->buffer when tracegetuser failed

When the length of the string written to setftracefilter exceeds FTRACEBUFFMAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: showstack+0x34/0x50 (C) dumpstacklvl+0xa0/0x158 printaddressdescription.constprop.0+0x88/0x398 printreport+0xb0/0x280 kasanreport+0xa4/0xf0 asanreportload1noabort+0x20/0x30 strsep+0x18c/0x1b0 ftraceprocessregex.isra.0+0x100/0x2d8 ftraceregexrelease+0x484/0x618 _fput+0x364/0xa58 _fput+0x28/0x40 taskworkrun+0x154/0x278 donotifyresume+0x1f0/0x220 el0svc+0xec/0xf0 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1ac/0x1b0

The reason is that tracegetuser will fail when processing a string longer than FTRACEBUFFMAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftraceregexrelease-> ftraceprocessregex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when tracegetuser failed.(CVE-2025-39683)