{"schema_version":"1.7.2","id":"OESA-2025-1513","modified":"2025-05-16T13:24:37Z","published":"2025-05-16T13:24:37Z","upstream":["CVE-2022-49111","CVE-2022-49505","CVE-2022-49755","CVE-2022-49771","CVE-2022-49826","CVE-2022-49842","CVE-2022-49850","CVE-2022-49915","CVE-2023-53090","CVE-2023-53116","CVE-2025-21999"],"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\nBluetooth: Fix use after free in hci_send_acl\n\nThis fixes the following trace caused by receiving\nHCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without\nfirst checking if conn-\u0026gt;type is in fact AMP_LINK and in case it is\ndo properly cleanup upper layers with hci_disconn_cfm:\n\n ==================================================================\n    BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50\n    Read of size 8 at addr ffff88800e404818 by task bluetoothd/142\n\n    CPU: 0 PID: 142 Comm: bluetoothd Not tainted\n    5.17.0-rc5-00006-gda4022eeac1a #7\n    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n    rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n    Call Trace:\n     \u0026lt;TASK\u0026gt;\n     dump_stack_lvl+0x45/0x59\n     print_address_description.constprop.0+0x1f/0x150\n     kasan_report.cold+0x7f/0x11b\n     hci_send_acl+0xaba/0xc50\n     l2cap_do_send+0x23f/0x3d0\n     l2cap_chan_send+0xc06/0x2cc0\n     l2cap_sock_sendmsg+0x201/0x2b0\n     sock_sendmsg+0xdc/0x110\n     sock_write_iter+0x20f/0x370\n     do_iter_readv_writev+0x343/0x690\n     do_iter_write+0x132/0x640\n     vfs_writev+0x198/0x570\n     do_writev+0x202/0x280\n     do_syscall_64+0x38/0x90\n     entry_SYSCALL_64_after_hwframe+0x44/0xae\n    RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014\n    Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3\n    0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05\n    \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10\n    RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015\n    RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77\n    R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580\n    RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001\n    \u0026lt;/TASK\u0026gt;\n    R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0\n\n    Allocated by task 45:\n        kasan_save_stack+0x1e/0x40\n        __kasan_kmalloc+0x81/0xa0\n        hci_chan_create+0x9a/0x2f0\n        l2cap_conn_add.part.0+0x1a/0xdc0\n        l2cap_connect_cfm+0x236/0x1000\n        le_conn_complete_evt+0x15a7/0x1db0\n        hci_le_conn_complete_evt+0x226/0x2c0\n        hci_le_meta_evt+0x247/0x450\n        hci_event_packet+0x61b/0xe90\n        hci_rx_work+0x4d5/0xc50\n        process_one_work+0x8fb/0x15a0\n        worker_thread+0x576/0x1240\n        kthread+0x29d/0x340\n        ret_from_fork+0x1f/0x30\n\n    Freed by task 45:\n        kasan_save_stack+0x1e/0x40\n        kasan_set_track+0x21/0x30\n        kasan_set_free_info+0x20/0x30\n        __kasan_slab_free+0xfb/0x130\n        kfree+0xac/0x350\n        hci_conn_cleanup+0x101/0x6a0\n        hci_conn_del+0x27e/0x6c0\n        hci_disconn_phylink_complete_evt+0xe0/0x120\n        hci_event_packet+0x812/0xe90\n        hci_rx_work+0x4d5/0xc50\n        process_one_work+0x8fb/0x15a0\n        worker_thread+0x576/0x1240\n        kthread+0x29d/0x340\n        ret_from_fork+0x1f/0x30\n\n    The buggy address belongs to the object at ffff88800c0f0500\n    The buggy address is located 24 bytes inside of\n    which belongs to the cache kmalloc-128 of size 128\n    The buggy address belongs to the page:\n    128-byte region [ffff88800c0f0500, ffff88800c0f0580)\n    flags: 0x100000000000200(slab|node=0|zone=1)\n    page:00000000fe45cd86 refcount:1 mapcount:0\n    mapping:0000000000000000 index:0x0 pfn:0xc0f0\n    raw: 0000000000000000 0000000080100010 00000001ffffffff\n    0000000000000000\n    raw: 0100000000000200 ffffea00003a2c80 dead000000000004\n    ffff8880078418c0\n    page dumped because: kasan: bad access detected\n    ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc\n    Memory state around the buggy address:\n    \u0026gt;ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n    ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                   \n---truncated---(CVE-2022-49111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFC: NULL out the dev-\u0026gt;rfkill to prevent UAF\n\nCommit 3e3b5dfcd16a (\u0026quot;NFC: reorder the logic in nfc_{un,}register_device\u0026quot;)\nassumes the device_is_registered() in function nfc_dev_up() will help\nto check when the rfkill is unregistered. However, this check only\ntake effect when device_del(\u0026amp;dev-\u0026gt;dev) is done in nfc_unregister_device().\nHence, the rfkill object is still possible be dereferenced.\n\nThe crash trace in latest kernel (5.18-rc2):\n\n[   68.760105] ==================================================================\n[   68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750\n[   68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313\n[   68.760756]\n[   68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4\n[   68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[   68.760756] Call Trace:\n[   68.760756]  \u0026lt;TASK\u0026gt;\n[   68.760756]  dump_stack_lvl+0x57/0x7d\n[   68.760756]  print_report.cold+0x5e/0x5db\n[   68.760756]  ? __lock_acquire+0x3ec1/0x6750\n[   68.760756]  kasan_report+0xbe/0x1c0\n[   68.760756]  ? __lock_acquire+0x3ec1/0x6750\n[   68.760756]  __lock_acquire+0x3ec1/0x6750\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  ? register_lock_class+0x18d0/0x18d0\n[   68.760756]  lock_acquire+0x1ac/0x4f0\n[   68.760756]  ? rfkill_blocked+0xe/0x60\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  ? mutex_lock_io_nested+0x12c0/0x12c0\n[   68.760756]  ? nla_get_range_signed+0x540/0x540\n[   68.760756]  ? _raw_spin_lock_irqsave+0x4e/0x50\n[   68.760756]  _raw_spin_lock_irqsave+0x39/0x50\n[   68.760756]  ? rfkill_blocked+0xe/0x60\n[   68.760756]  rfkill_blocked+0xe/0x60\n[   68.760756]  nfc_dev_up+0x84/0x260\n[   68.760756]  nfc_genl_dev_up+0x90/0xe0\n[   68.760756]  genl_family_rcv_msg_doit+0x1f4/0x2f0\n[   68.760756]  ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230\n[   68.760756]  ? security_capable+0x51/0x90\n[   68.760756]  genl_rcv_msg+0x280/0x500\n[   68.760756]  ? genl_get_cmd+0x3c0/0x3c0\n[   68.760756]  ? lock_acquire+0x1ac/0x4f0\n[   68.760756]  ? nfc_genl_dev_down+0xe0/0xe0\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  netlink_rcv_skb+0x11b/0x340\n[   68.760756]  ? genl_get_cmd+0x3c0/0x3c0\n[   68.760756]  ? netlink_ack+0x9c0/0x9c0\n[   68.760756]  ? netlink_deliver_tap+0x136/0xb00\n[   68.760756]  genl_rcv+0x1f/0x30\n[   68.760756]  netlink_unicast+0x430/0x710\n[   68.760756]  ? memset+0x20/0x40\n[   68.760756]  ? netlink_attachskb+0x740/0x740\n[   68.760756]  ? __build_skb_around+0x1f4/0x2a0\n[   68.760756]  netlink_sendmsg+0x75d/0xc00\n[   68.760756]  ? netlink_unicast+0x710/0x710\n[   68.760756]  ? netlink_unicast+0x710/0x710\n[   68.760756]  sock_sendmsg+0xdf/0x110\n[   68.760756]  __sys_sendto+0x19e/0x270\n[   68.760756]  ? __ia32_sys_getpeername+0xa0/0xa0\n[   68.760756]  ? fd_install+0x178/0x4c0\n[   68.760756]  ? fd_install+0x195/0x4c0\n[   68.760756]  ? kernel_fpu_begin_mask+0x1c0/0x1c0\n[   68.760756]  __x64_sys_sendto+0xd8/0x1b0\n[   68.760756]  ? lockdep_hardirqs_on+0xbf/0x130\n[   68.760756]  ? syscall_enter_from_user_mode+0x1d/0x50\n[   68.760756]  do_syscall_64+0x3b/0x90\n[   68.760756]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[   68.760756] RIP: 0033:0x7f67fb50e6b3\n...\n[   68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\n[   68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3\n[   68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003\n[   68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c\n[   68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e\n[   68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003\n\n[   68.760756]  \u0026lt;/TASK\u0026gt;\n[   68.760756]\n[   68.760756] Allocated by task 279:\n[   68.760756]  kasan_save_stack+0x1e/0x40\n[\n---truncated---(CVE-2022-49505)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait\n\nWhile performing fast composition switch, there is a possibility that the\nprocess of ffs_ep0_write/ffs_ep0_read get into a race condition\ndue to ep0req being freed up from functionfs_unbind.\n\nConsider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait\nby taking a lock \u0026amp;ffs-\u0026gt;ev.waitq.lock. However, the functionfs_unbind isn\u0026apos;t\nbounded so it can go ahead and mark the ep0req to NULL, and since there\nis no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.\n\nFix this by making a serialized execution between the two functions using\na mutex_lock(ffs-\u0026gt;mutex).(CVE-2022-49755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm ioctl: fix misbehavior if list_versions races with module loading\n\n__list_versions will first estimate the required space using the\n\u0026quot;dm_target_iterate(list_version_get_needed, \u0026amp;needed)\u0026quot; call and then will\nfill the space using the \u0026quot;dm_target_iterate(list_version_get_info,\n\u0026amp;iter_info)\u0026quot; call. Each of these calls locks the targets using the\n\u0026quot;down_read(\u0026amp;_lock)\u0026quot; and \u0026quot;up_read(\u0026amp;_lock)\u0026quot; calls, however between the first\nand second \u0026quot;dm_target_iterate\u0026quot; there is no lock held and the target\nmodules can be loaded at this point, so the second \u0026quot;dm_target_iterate\u0026quot;\ncall may need more space than what was the first \u0026quot;dm_target_iterate\u0026quot;\nreturned.\n\nThe code tries to handle this overflow (see the beginning of\nlist_version_get_info), however this handling is incorrect.\n\nThe code sets \u0026quot;param-\u0026gt;data_size = param-\u0026gt;data_start + needed\u0026quot; and\n\u0026quot;iter_info.end = (char *)vers+len\u0026quot; - \u0026quot;needed\u0026quot; is the size returned by the\nfirst dm_target_iterate call; \u0026quot;len\u0026quot; is the size of the buffer allocated by\nuserspace.\n\n\u0026quot;len\u0026quot; may be greater than \u0026quot;needed\u0026quot;; in this case, the code will write up\nto \u0026quot;len\u0026quot; bytes into the buffer, however param-\u0026gt;data_size is set to\n\u0026quot;needed\u0026quot;, so it may write data past the param-\u0026gt;data_size value. The ioctl\ninterface copies only up to param-\u0026gt;data_size into userspace, thus part of\nthe result will be truncated.\n\nFix this bug by setting \u0026quot;iter_info.end = (char *)vers + needed;\u0026quot; - this\nguarantees that the second \u0026quot;dm_target_iterate\u0026quot; call will write only up to\nthe \u0026quot;needed\u0026quot; buffer and it will exit with \u0026quot;DM_BUFFER_FULL_FLAG\u0026quot; if it\noverflows the \u0026quot;needed\u0026quot; space - in this case, userspace will allocate a\nlarger buffer and retry.\n\nNote that there is also a bug in list_version_get_needed - we need to add\n\u0026quot;strlen(tt-\u0026gt;name) + 1\u0026quot; to the needed size, not \u0026quot;strlen(tt-\u0026gt;name)\u0026quot;.(CVE-2022-49771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix double ata_host_put() in ata_tport_add()\n\nIn the error path in ata_tport_add(), when calling put_device(),\nata_tport_release() is called, it will put the refcount of \u0026apos;ap-\u0026gt;host\u0026apos;.\n\nAnd then ata_host_put() is called again, the refcount is decreased\nto 0, ata_host_release() is called, all ports are freed and set to\nnull.\n\nWhen unbinding the device after failure, ata_host_stop() is called\nto release the resources, it leads a null-ptr-deref(), because all\nthe ports all freed and null.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G            E      6.1.0-rc3+ #8\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ata_host_stop+0x3c/0x84 [libata]\nlr : release_nodes+0x64/0xd0\nCall trace:\n ata_host_stop+0x3c/0x84 [libata]\n release_nodes+0x64/0xd0\n devres_release_all+0xbc/0x1b0\n device_unbind_cleanup+0x20/0x70\n really_probe+0x158/0x320\n __driver_probe_device+0x84/0x120\n driver_probe_device+0x44/0x120\n __driver_attach+0xb4/0x220\n bus_for_each_dev+0x78/0xdc\n driver_attach+0x2c/0x40\n bus_add_driver+0x184/0x240\n driver_register+0x80/0x13c\n __pci_register_driver+0x4c/0x60\n ahci_pci_driver_init+0x30/0x1000 [ahci]\n\nFix this by removing redundant ata_host_put() in the error path.(CVE-2022-49826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix use-after-free in snd_soc_exit()\n\nKASAN reports a use-after-free:\n\nBUG: KASAN: use-after-free in device_del+0xb5b/0xc60\nRead of size 8 at addr ffff888008655050 by task rmmod/387\nCPU: 2 PID: 387 Comm: rmmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x79/0x9a\nprint_report+0x17f/0x47b\nkasan_report+0xbb/0xf0\ndevice_del+0xb5b/0xc60\nplatform_device_del.part.0+0x24/0x200\nplatform_device_unregister+0x2e/0x40\nsnd_soc_exit+0xa/0x22 [snd_soc_core]\n__do_sys_delete_module.constprop.0+0x34f/0x5b0\ndo_syscall_64+0x3a/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n...\n\u0026lt;/TASK\u0026gt;\n\nIt\u0026apos;s bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,\nbut its ret is ignored, which makes soc_dummy_dev unregistered twice.\n\nsnd_soc_init()\n    snd_soc_util_init()\n        platform_device_register_simple(soc_dummy_dev)\n        platform_driver_register() # fail\n    \tplatform_device_unregister(soc_dummy_dev)\n    platform_driver_register() # success\n...\nsnd_soc_exit()\n    snd_soc_util_exit()\n    # soc_dummy_dev will be unregistered for second time\n\nTo fix it, handle error and stop snd_soc_init() when util_init() fail.\nAlso clean debugfs when util_init() or driver_register() fail.(CVE-2022-49842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix deadlock in nilfs_count_free_blocks()\n\nA semaphore deadlock can occur if nilfs_get_block() detects metadata\ncorruption while locating data blocks and a superblock writeback occurs at\nthe same time:\n\ntask 1                               task 2\n------                               ------\n* A file operation *\nnilfs_truncate()\n  nilfs_get_block()\n    down_read(rwsem A) \u0026lt;--\n    nilfs_bmap_lookup_contig()\n      ...                            generic_shutdown_super()\n                                       nilfs_put_super()\n                                         * Prepare to write superblock *\n                                         down_write(rwsem B) \u0026lt;--\n                                         nilfs_cleanup_super()\n      * Detect b-tree corruption *         nilfs_set_log_cursor()\n      nilfs_bmap_convert_error()             nilfs_count_free_blocks()\n        __nilfs_error()                        down_read(rwsem A) \u0026lt;--\n          nilfs_set_error()\n            down_write(rwsem B) \u0026lt;--\n\n                           *** DEADLOCK ***\n\nHere, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)-\u0026gt;mi_sem)\nand then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata\ncorruption, __nilfs_error() is called from nilfs_bmap_convert_error()\ninside the lock section.\n\nSince __nilfs_error() calls nilfs_set_error() unless the filesystem is\nread-only and nilfs_set_error() attempts to writelock rwsem B (=\nnilfs-\u0026gt;ns_sem) to write back superblock exclusively, hierarchical lock\nacquisition occurs in the order rwsem A -\u0026gt; rwsem B.\n\nNow, if another task starts updating the superblock, it may writelock\nrwsem B during the lock sequence above, and can deadlock trying to\nreadlock rwsem A in nilfs_count_free_blocks().\n\nHowever, there is actually no need to take rwsem A in\nnilfs_count_free_blocks() because it, within the lock section, only reads\na single integer data on a shared struct with\nnilfs_sufile_get_ncleansegs().  This has been the case after commit\naa474a220180 (\u0026quot;nilfs2: add local variable to cache the number of clean\nsegments\u0026quot;), that is, even before this bug was introduced.\n\nSo, this resolves the deadlock problem by just not taking the semaphore in\nnilfs_count_free_blocks().(CVE-2022-49850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix possible memory leak in mISDN_register_device()\n\nAfer commit 1fa5ae857bb1 (\u0026quot;driver core: get rid of struct device\u0026apos;s\nbus_id string array\u0026quot;), the name of device is allocated dynamically,\nadd put_device() to give up the reference, so that the name can be\nfreed in kobject_cleanup() when the refcount is 0.\n\nSet device class before put_device() to avoid null release() function\nWARN message in device_release().(CVE-2022-49915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix an illegal memory access\n\nIn the kfd_wait_on_events() function, the kfd_event_waiter structure is\nallocated by alloc_event_waiters(), but the event field of the waiter\nstructure is not initialized; When copy_from_user() fails in the\nkfd_wait_on_events() function, it will enter exception handling to\nrelease the previously allocated memory of the waiter structure;\nDue to the event field of the waiters structure being accessed\nin the free_waiters() function, this results in illegal memory access\nand system crash, here is the crash log:\n\nlocalhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0\nlocalhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082\nlocalhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000\nlocalhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0\nlocalhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64\nlocalhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002\nlocalhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698\nlocalhost kernel: FS:  0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000\nlocalhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nlocalhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0\nlocalhost kernel: Call Trace:\nlocalhost kernel: _raw_spin_lock_irqsave+0x30/0x40\nlocalhost kernel: remove_wait_queue+0x12/0x50\nlocalhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]\nlocalhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]\nlocalhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: __x64_sys_ioctl+0x8e/0xd0\nlocalhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0\nlocalhost kernel: do_syscall_64+0x33/0x80\nlocalhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9\nlocalhost kernel: RIP: 0033:0x152a4dff68d7\n\nAllocate the structure with kcalloc, and remove redundant 0-initialization\nand a redundant loop condition check.(CVE-2023-53090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: avoid potential UAF in nvmet_req_complete()\n\nAn nvme target -\u0026gt;queue_response() operation implementation may free the\nrequest passed as argument. Such implementation potentially could result\nin a use after free of the request pointer when percpu_ref_put() is\ncalled in nvmet_req_complete().\n\nAvoid such problem by using a local variable to save the sq pointer\nbefore calling __nvmet_req_complete(), thus avoiding dereferencing the\nreq pointer after that function call.(CVE-2023-53116)\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)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2505.3.0.0327.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2505.3.0.0327.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1513"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49505"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49755"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49771"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49826"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49842"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49850"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49915"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53116"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21999"}],"database_specific":{"severity":"High"}}