{"schema_version":"1.7.2","id":"OESA-2025-1514","modified":"2025-05-16T13:24:40Z","published":"2025-05-16T13:24:40Z","upstream":["CVE-2022-49901","CVE-2023-53093","CVE-2025-21999","CVE-2025-23144"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: Fix kmemleak in blk_mq_init_allocated_queue\n\nThere is a kmemleak caused by modprobe null_blk.ko\n\nunreferenced object 0xffff8881acb1f000 (size 1024):\n  comm \u0026quot;modprobe\u0026quot;, pid 836, jiffies 4294971190 (age 27.068s)\n  hex dump (first 32 bytes):\n    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........\n    ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff  .........S......\n  backtrace:\n    [\u0026lt;000000004a10c249\u0026gt;] kmalloc_node_trace+0x22/0x60\n    [\u0026lt;00000000648f7950\u0026gt;] blk_mq_alloc_and_init_hctx+0x289/0x350\n    [\u0026lt;00000000af06de0e\u0026gt;] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0\n    [\u0026lt;00000000e00c1872\u0026gt;] blk_mq_init_allocated_queue+0x48c/0x1440\n    [\u0026lt;00000000d16b4e68\u0026gt;] __blk_mq_alloc_disk+0xc8/0x1c0\n    [\u0026lt;00000000d10c98c3\u0026gt;] 0xffffffffc450d69d\n    [\u0026lt;00000000b9299f48\u0026gt;] 0xffffffffc4538392\n    [\u0026lt;0000000061c39ed6\u0026gt;] do_one_initcall+0xd0/0x4f0\n    [\u0026lt;00000000b389383b\u0026gt;] do_init_module+0x1a4/0x680\n    [\u0026lt;0000000087cf3542\u0026gt;] load_module+0x6249/0x7110\n    [\u0026lt;00000000beba61b8\u0026gt;] __do_sys_finit_module+0x140/0x200\n    [\u0026lt;00000000fdcfff51\u0026gt;] do_syscall_64+0x35/0x80\n    [\u0026lt;000000003c0f1f71\u0026gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThat is because q-\u0026gt;ma_ops is set to NULL before blk_release_queue is\ncalled.\n\nblk_mq_init_queue_data\n  blk_mq_init_allocated_queue\n    blk_mq_realloc_hw_ctxs\n      for (i = 0; i \u0026lt; set-\u0026gt;nr_hw_queues; i++) {\n        old_hctx = xa_load(\u0026amp;q-\u0026gt;hctx_table, i);\n        if (!blk_mq_alloc_and_init_hctx(.., i, ..))\t\t[1]\n          if (!old_hctx)\n\t    break;\n\n      xa_for_each_start(\u0026amp;q-\u0026gt;hctx_table, j, hctx, j)\n        blk_mq_exit_hctx(q, set, hctx, j); \t\t\t[2]\n\n    if (!q-\u0026gt;nr_hw_queues)\t\t\t\t\t[3]\n      goto err_hctxs;\n\n  err_exit:\n      q-\u0026gt;mq_ops = NULL;\t\t\t  \t\t\t[4]\n\n  blk_put_queue\n    blk_release_queue\n      if (queue_is_mq(q))\t\t\t\t\t[5]\n        blk_mq_release(q);\n\n[1]: blk_mq_alloc_and_init_hctx failed at i != 0.\n[2]: The hctxs allocated by [1] are moved to q-\u0026gt;unused_hctx_list and\nwill be cleaned up in blk_mq_release.\n[3]: q-\u0026gt;nr_hw_queues is 0.\n[4]: Set q-\u0026gt;mq_ops to NULL.\n[5]: queue_is_mq returns false due to [4]. And blk_mq_release\nwill not be called. The hctxs in q-\u0026gt;unused_hctx_list are leaked.\n\nTo fix it, call blk_release_queue in exception path.(CVE-2022-49901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not let histogram values have some modifiers\n\nHistogram values can not be strings, stacktraces, graphs, symbols,\nsyscalls, or grouped in buckets or log. Give an error if a value is set to\ndo so.\n\nNote, the histogram code was not prepared to handle these modifiers for\nhistograms and caused a bug.\n\nMark Rutland reported:\n\n # echo \u0026apos;p:copy_to_user __arch_copy_to_user n=$arg2\u0026apos; \u0026gt;\u0026gt; /sys/kernel/tracing/kprobe_events\n # echo \u0026apos;hist:keys=n:vals=hitcount.buckets=8:sort=hitcount\u0026apos; \u0026gt; /sys/kernel/tracing/events/kprobes/copy_to_user/trigger\n # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist\n[  143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  143.695190] Mem abort info:\n[  143.695362]   ESR = 0x0000000096000004\n[  143.695604]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  143.695889]   SET = 0, FnV = 0\n[  143.696077]   EA = 0, S1PTW = 0\n[  143.696302]   FSC = 0x04: level 0 translation fault\n[  143.702381] Data abort info:\n[  143.702614]   ISV = 0, ISS = 0x00000004\n[  143.702832]   CM = 0, WnR = 0\n[  143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000\n[  143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[  143.704714] Modules linked in:\n[  143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3\n[  143.706138] Hardware name: linux,dummy-virt (DT)\n[  143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  143.707120] pc : hist_field_name.part.0+0x14/0x140\n[  143.707504] lr : hist_field_name.part.0+0x104/0x140\n[  143.707774] sp : ffff800008333a30\n[  143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0\n[  143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800\n[  143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001\n[  143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000\n[  143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[  143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023\n[  143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c\n[  143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c\n[  143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d\n[  143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000\n[  143.711746] Call trace:\n[  143.712115]  hist_field_name.part.0+0x14/0x140\n[  143.712642]  hist_field_name.part.0+0x104/0x140\n[  143.712925]  hist_field_print+0x28/0x140\n[  143.713125]  event_hist_trigger_print+0x174/0x4d0\n[  143.713348]  hist_show+0xf8/0x980\n[  143.713521]  seq_read_iter+0x1bc/0x4b0\n[  143.713711]  seq_read+0x8c/0xc4\n[  143.713876]  vfs_read+0xc8/0x2a4\n[  143.714043]  ksys_read+0x70/0xfc\n[  143.714218]  __arm64_sys_read+0x24/0x30\n[  143.714400]  invoke_syscall+0x50/0x120\n[  143.714587]  el0_svc_common.constprop.0+0x4c/0x100\n[  143.714807]  do_el0_svc+0x44/0xd0\n[  143.714970]  el0_svc+0x2c/0x84\n[  143.715134]  el0t_64_sync_handler+0xbc/0x140\n[  143.715334]  el0t_64_sync+0x190/0x194\n[  143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000)\n[  143.716510] ---[ end trace 0000000000000000 ]---\nSegmentation fault(CVE-2023-53093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: fix UAF in proc_get_inode()\n\nFix race between rmmod and /proc/XXX\u0026apos;s inode instantiation.\n\nThe bug is that pde-\u0026gt;proc_ops don\u0026apos;t belong to /proc, it belongs to a\nmodule, therefore dereferencing it after /proc entry has been registered\nis a bug unless use_pde/unuse_pde() pair has been used.\n\nuse_pde/unuse_pde can be avoided (2 atomic ops!) because pde-\u0026gt;proc_ops\nnever changes so information necessary for inode instantiation can be\nsaved _before_ proc_register() in PDE itself and used later, avoiding\npde-\u0026gt;proc_ops-\u0026gt;...  dereference.\n\n      rmmod                         lookup\nsys_delete_module\n                         proc_lookup_de\n\t\t\t   pde_get(de);\n\t\t\t   proc_get_inode(dir-\u0026gt;i_sb, de);\n  mod-\u0026gt;exit()\n    proc_remove\n      remove_proc_subtree\n       proc_entry_rundown(de);\n  free_module(mod);\n\n                               if (S_ISREG(inode-\u0026gt;i_mode))\n\t                         if (de-\u0026gt;proc_ops-\u0026gt;proc_read_iter)\n                           --\u0026gt; As module is already freed, will trigger UAF\n\nBUG: unable to handle page fault for address: fffffbfff80a702b\nPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:proc_get_inode+0x302/0x6e0\nRSP: 0018:ffff88811c837998 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007\nRDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158\nRBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20\nR10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0\nR13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001\nFS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_lookup_de+0x11f/0x2e0\n __lookup_slow+0x188/0x350\n walk_component+0x2ab/0x4f0\n path_lookupat+0x120/0x660\n filename_lookup+0x1ce/0x560\n vfs_statx+0xac/0x150\n __do_sys_newstat+0x96/0x110\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[adobriyan@gmail.com: don\u0026apos;t do 2 atomic ops on the common path](CVE-2025-21999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbacklight: led_bl: Hold led_access lock when calling led_sysfs_disable()\n\nLockdep detects the following issue on led-backlight removal:\n  [  142.315935] ------------[ cut here ]------------\n  [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80\n  ...\n  [  142.500725] Call trace:\n  [  142.503176]  led_sysfs_enable+0x54/0x80 (P)\n  [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]\n  [  142.511742]  platform_remove+0x30/0x58\n  [  142.515501]  device_remove+0x54/0x90\n  ...\n\nIndeed, led_sysfs_enable() has to be called with the led_access\nlock held.\n\nHold the lock when calling led_sysfs_disable().(CVE-2025-23144)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-263.0.0.165.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","perf-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-263.0.0.165.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-263.0.0.165.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","perf-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-263.0.0.165.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1514"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53093"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23144"}],"database_specific":{"severity":"High"}}