OESA-2025-1515

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

blk-mq: Fix kmemleak in blkmqinitallocatedqueue

There is a kmemleak caused by modprobe null_blk.ko

unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmallocnodetrace+0x22/0x60 [<00000000648f7950>] blkmqallocandinithctx+0x289/0x350 [<00000000af06de0e>] blkmqreallochwctxs+0x2fe/0x3d0 [<00000000e00c1872>] blkmqinitallocatedqueue+0x48c/0x1440 [<00000000d16b4e68>] _blkmqallocdisk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] dooneinitcall+0xd0/0x4f0 [<00000000b389383b>] doinitmodule+0x1a4/0x680 [<0000000087cf3542>] loadmodule+0x6249/0x7110 [<00000000beba61b8>] _dosysfinitmodule+0x140/0x200 [<00000000fdcfff51>] dosyscall64+0x35/0x80 [<000000003c0f1f71>] entrySYSCALL64afterhwframe+0x46/0xb0

That is because q->maops is set to NULL before blkrelease_queue is called.

blkmqinitqueuedata blkmqinitallocatedqueue blkmqreallochwctxs for (i = 0; i < set->nrhwqueues; i++) { oldhctx = xaload(&q->hctxtable, i); if (!blkmqallocandinithctx(.., i, ..)) [1] if (!old_hctx) break;

  xa_for_each_start(&q->hctx_table, j, hctx, j)
    blk_mq_exit_hctx(q, set, hctx, j);          [2]

if (!q->nr_hw_queues)                    [3]
  goto err_hctxs;

errexit: q->mqops = NULL; [4]

blkputqueue blkreleasequeue if (queueismq(q)) [5] blkmqrelease(q);

will be cleaned up in blkmqrelease. will not be called. The hctxs in q->unusedhctxlist are leaked.

To fix it, call blkreleasequeue in exception path.(CVE-2022-49901)

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

tracing: Do not let histogram values have some modifiers

Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so.

Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug.

Mark Rutland reported:

# echo 'p:copytouser _archcopytouser n=$arg2' >> /sys/kernel/tracing/kprobeevents # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copytouser/trigger # cat /sys/kernel/tracing/events/kprobes/copytouser/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : histfieldname.part.0+0x14/0x140 [ 143.707504] lr : histfieldname.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] histfieldname.part.0+0x14/0x140 [ 143.712642] histfieldname.part.0+0x104/0x140 [ 143.712925] histfieldprint+0x28/0x140 [ 143.713125] eventhisttriggerprint+0x174/0x4d0 [ 143.713348] histshow+0xf8/0x980 [ 143.713521] seqreaditer+0x1bc/0x4b0 [ 143.713711] seqread+0x8c/0xc4 [ 143.713876] vfsread+0xc8/0x2a4 [ 143.714043] ksysread+0x70/0xfc [ 143.714218] _arm64sysread+0x24/0x30 [ 143.714400] invokesyscall+0x50/0x120 [ 143.714587] el0svccommon.constprop.0+0x4c/0x100 [ 143.714807] doel0svc+0x44/0xd0 [ 143.714970] el0svc+0x2c/0x84 [ 143.715134] el0t64synchandler+0xbc/0x140 [ 143.715334] el0t64sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault(CVE-2023-53093)

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:

backlight: ledbl: Hold ledaccess lock when calling ledsysfsdisable()

Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 ledsysfsenable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] ledsysfsenable+0x54/0x80 (P) [ 142.507370] ledblremove+0x80/0xa8 [ledbl] [ 142.511742] platformremove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...

Indeed, ledsysfsenable() has to be called with the led_access lock held.

Hold the lock when calling ledsysfsdisable().(CVE-2025-23144)