{"schema_version":"1.7.2","id":"OESA-2025-1408","modified":"2025-04-11T13:43:56Z","published":"2025-04-11T13:43:56Z","upstream":["CVE-2022-49059","CVE-2022-49085","CVE-2022-49100","CVE-2022-49313","CVE-2022-49370","CVE-2022-49374","CVE-2022-49389","CVE-2022-49390","CVE-2022-49396","CVE-2022-49441","CVE-2022-49450","CVE-2022-49451","CVE-2022-49467","CVE-2022-49481","CVE-2022-49491","CVE-2022-49621","CVE-2022-49711","CVE-2022-49746","CVE-2022-49753","CVE-2022-49757","CVE-2023-52988","CVE-2023-53015","CVE-2023-53024","CVE-2024-57980","CVE-2024-57996","CVE-2025-21772"],"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\nnfc: nci: add flush_workqueue to prevent uaf\n\nOur detector found a concurrent use-after-free bug when detaching an\nNCI device. The main reason for this bug is the unexpected scheduling\nbetween the used delayed mechanism (timer and workqueue).\n\nThe race can be demonstrated below:\n\nThread-1                           Thread-2\n                                 | nci_dev_up()\n                                 |   nci_open_device()\n                                 |     __nci_request(nci_reset_req)\n                                 |       nci_send_cmd\n                                 |         queue_work(cmd_work)\nnci_unregister_device()          |\n  nci_close_device()             | ...\n    del_timer_sync(cmd_timer)[1] |\n...                              | Worker\nnci_free_device()                | nci_cmd_work()\n  kfree(ndev)[3]                 |   mod_timer(cmd_timer)[2]\n\nIn short, the cleanup routine thought that the cmd_timer has already\nbeen detached by [1] but the mod_timer can re-attach the timer [2], even\nit is already released [3], resulting in UAF.\n\nThis UAF is easy to trigger, crash trace by POC is like below\n\n[   66.703713] ==================================================================\n[   66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490\n[   66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33\n[   66.703974]\n[   66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5\n[   66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work\n[   66.703974] Call Trace:\n[   66.703974]  \u0026lt;TASK\u0026gt;\n[   66.703974]  dump_stack_lvl+0x57/0x7d\n[   66.703974]  print_report.cold+0x5e/0x5db\n[   66.703974]  ? enqueue_timer+0x448/0x490\n[   66.703974]  kasan_report+0xbe/0x1c0\n[   66.703974]  ? enqueue_timer+0x448/0x490\n[   66.703974]  enqueue_timer+0x448/0x490\n[   66.703974]  __mod_timer+0x5e6/0xb80\n[   66.703974]  ? mark_held_locks+0x9e/0xe0\n[   66.703974]  ? try_to_del_timer_sync+0xf0/0xf0\n[   66.703974]  ? lockdep_hardirqs_on_prepare+0x17b/0x410\n[   66.703974]  ? queue_work_on+0x61/0x80\n[   66.703974]  ? lockdep_hardirqs_on+0xbf/0x130\n[   66.703974]  process_one_work+0x8bb/0x1510\n[   66.703974]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   66.703974]  ? pwq_dec_nr_in_flight+0x230/0x230\n[   66.703974]  ? rwlock_bug.part.0+0x90/0x90\n[   66.703974]  ? _raw_spin_lock_irq+0x41/0x50\n[   66.703974]  worker_thread+0x575/0x1190\n[   66.703974]  ? process_one_work+0x1510/0x1510\n[   66.703974]  kthread+0x2a0/0x340\n[   66.703974]  ? kthread_complete_and_exit+0x20/0x20\n[   66.703974]  ret_from_fork+0x22/0x30\n[   66.703974]  \u0026lt;/TASK\u0026gt;\n[   66.703974]\n[   66.703974] Allocated by task 267:\n[   66.703974]  kasan_save_stack+0x1e/0x40\n[   66.703974]  __kasan_kmalloc+0x81/0xa0\n[   66.703974]  nci_allocate_device+0xd3/0x390\n[   66.703974]  nfcmrvl_nci_register_dev+0x183/0x2c0\n[   66.703974]  nfcmrvl_nci_uart_open+0xf2/0x1dd\n[   66.703974]  nci_uart_tty_ioctl+0x2c3/0x4a0\n[   66.703974]  tty_ioctl+0x764/0x1310\n[   66.703974]  __x64_sys_ioctl+0x122/0x190\n[   66.703974]  do_syscall_64+0x3b/0x90\n[   66.703974]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[   66.703974]\n[   66.703974] Freed by task 406:\n[   66.703974]  kasan_save_stack+0x1e/0x40\n[   66.703974]  kasan_set_track+0x21/0x30\n[   66.703974]  kasan_set_free_info+0x20/0x30\n[   66.703974]  __kasan_slab_free+0x108/0x170\n[   66.703974]  kfree+0xb0/0x330\n[   66.703974]  nfcmrvl_nci_unregister_dev+0x90/0xd0\n[   66.703974]  nci_uart_tty_close+0xdf/0x180\n[   66.703974]  tty_ldisc_kill+0x73/0x110\n[   66.703974]  tty_ldisc_hangup+0x281/0x5b0\n[   66.703974]  __tty_hangup.part.0+0x431/0x890\n[   66.703974]  tty_release+0x3a8/0xc80\n[   66.703974]  __fput+0x1f0/0x8c0\n[   66.703974]  task_work_run+0xc9/0x170\n[   66.703974]  exit_to_user_mode_prepare+0x194/0x1a0\n[   66.703974]  syscall_exit_to_user_mode+0x19/0x50\n[   66.703974]  do_syscall_64+0x48/0x90\n[   66.703974]  entry_SYSCALL_64_after_hwframe+0x44/0x\n---truncated---(CVE-2022-49059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: Fix five use after free bugs in get_initial_state\n\nIn get_initial_state, it calls notify_initial_state_done(skb,..) if\ncb-\u0026gt;args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),\nthe skb will be freed by nlmsg_free(skb).\nThen get_initial_state will goto out and the freed skb will be used by\nreturn value skb-\u0026gt;len, which is a uaf bug.\n\nWhat\u0026apos;s worse, the same problem goes even further: skb can also be\nfreed in the notify_*_state_change -\u0026gt; notify_*_state calls below.\nThus 4 additional uaf bugs happened.\n\nMy patch lets the problem callee functions: notify_initial_state_done\nand notify_*_state_change return an error code if errors happen.\nSo that the error codes could be propagated and the uaf bugs can be avoid.\n\nv2 reports a compilation warning. This v3 fixed this warning and built\nsuccessfully in my local environment with no additional warnings.\nv2: https://lore.kernel.org/patchwork/patch/1435218/(CVE-2022-49085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_console: eliminate anonymous module_init \u0026amp; module_exit\n\nEliminate anonymous module_init() and module_exit(), which can lead to\nconfusion or ambiguity when reading System.map, crashes/oops/bugs,\nor an initcall_debug log.\n\nGive each of these init and exit functions unique driver-specific\nnames to eliminate the anonymous names.\n\nExample 1: (System.map)\n ffffffff832fc78c t init\n ffffffff832fc79e t init\n ffffffff832fc8f8 t init\n\nExample 2: (initcall_debug log)\n calling  init+0x0/0x12 @ 1\n initcall init+0x0/0x12 returned 0 after 15 usecs\n calling  init+0x0/0x60 @ 1\n initcall init+0x0/0x60 returned 0 after 2 usecs\n calling  init+0x0/0x9a @ 1\n initcall init+0x0/0x9a returned 0 after 74 usecs(CVE-2022-49100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: usb: host: Fix deadlock in oxu_bus_suspend()\n\nThere is a deadlock in oxu_bus_suspend(), which is shown below:\n\n   (Thread 1)              |      (Thread 2)\n                           | timer_action()\noxu_bus_suspend()          |  mod_timer()\n spin_lock_irq() //(1)     |  (wait a time)\n ...                       | oxu_watchdog()\n del_timer_sync()          |  spin_lock_irq() //(2)\n (wait timer to stop)      |  ...\n\nWe hold oxu-\u0026gt;lock in position (1) of thread 1, and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need oxu-\u0026gt;lock in position (2) of thread 2. As a result,\noxu_bus_suspend() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irq(), which could let timer handler to obtain\nthe needed lock.(CVE-2022-49313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle\n\nkobject_init_and_add() takes reference even when it fails.\nAccording to the doc of kobject_init_and_add()\n\n   If this function returns an error, kobject_put() must be called to\n   properly clean up the memory associated with the object.\n\nFix this issue by calling kobject_put().(CVE-2022-49370)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: check attribute length for bearer name\n\nsyzbot reported uninit-value:\n=====================================================\nBUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]\nBUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725\n string_nocheck lib/vsprintf.c:644 [inline]\n string+0x4f9/0x6f0 lib/vsprintf.c:725\n vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806\n vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158\n vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256\n vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283\n vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50\n _printk+0x18d/0x1cf kernel/printk/printk.c:2293\n tipc_enable_bearer net/tipc/bearer.c:371 [inline]\n __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033\n tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042\n genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n\n- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.\n- Do not use \u0026apos;illegal name\u0026apos; in printing message.(CVE-2022-49374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: usbip: fix a refcount leak in stub_probe()\n\nusb_get_dev() is called in stub_device_alloc(). When stub_probe() fails\nafter that, usb_put_dev() needs to be called to release the reference.\n\nFix this by moving usb_put_dev() to sdev_free error path handling.\n\nFind this by code review.(CVE-2022-49389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom-qmp: fix reset-controller leak on probe errors\n\nMake sure to release the lane reset controller in case of a late probe\nerror (e.g. probe deferral).\n\nNote that due to the reset controller being defined in devicetree in\n\u0026quot;lane\u0026quot; child nodes, devm_reset_control_get_exclusive() cannot be used\ndirectly.(CVE-2022-49396)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix deadlock caused by calling printk() under tty_port-\u0026gt;lock\n\npty_write() invokes kmalloc() which may invoke a normal printk() to print\nfailure message.  This can cause a deadlock in the scenario reported by\nsyz-bot below:\n\n       CPU0              CPU1                    CPU2\n       ----              ----                    ----\n                         lock(console_owner);\n                                                 lock(\u0026amp;port_lock_key);\n  lock(\u0026amp;port-\u0026gt;lock);\n                         lock(\u0026amp;port_lock_key);\n                                                 lock(\u0026amp;port-\u0026gt;lock);\n  lock(console_owner);\n\nAs commit dbdda842fe96 (\u0026quot;printk: Add console owner and waiter logic to\nload balance console writes\u0026quot;) said, such deadlock can be prevented by\nusing printk_deferred() in kmalloc() (which is invoked in the section\nguarded by the port-\u0026gt;lock).  But there are too many printk() on the\nkmalloc() path, and kmalloc() can be called from anywhere, so changing\nprintk() to printk_deferred() is too complicated and inelegant.\n\nTherefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so\nthat printk() will not be called, and this deadlock problem can be\navoided.\n\nSyzbot reported the following lockdep error:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.4.143-00237-g08ccc19a-dirty #10 Not tainted\n------------------------------------------------------\nsyz-executor.4/29420 is trying to acquire lock:\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023\n\nbut task is already holding lock:\nffff8880119c9158 (\u0026amp;port-\u0026gt;lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;port-\u0026gt;lock){-.-.}-{2:2}:\n       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n       tty_port_tty_get drivers/tty/tty_port.c:288 [inline]          \t\t\u0026lt;-- lock(\u0026amp;port-\u0026gt;lock);\n       tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47\n       serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767\n       serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854\n       serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] \t\u0026lt;-- lock(\u0026amp;port_lock_key);\n       serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870\n       serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126\n       __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156\n       [...]\n\n-\u0026gt; #1 (\u0026amp;port_lock_key){-.-.}-{2:2}:\n       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n       serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198\n\t\t\t\t\t\t\t\t\t\t\u0026lt;-- lock(\u0026amp;port_lock_key);\n       call_console_drivers kernel/printk/printk.c:1819 [inline]\n       console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504\n       vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024\t\t\t\u0026lt;-- lock(console_owner);\n       vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394\n       printk+0xba/0xed kernel/printk/printk.c:2084\n       register_console+0x8b3/0xc10 kernel/printk/printk.c:2829\n       univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681\n       console_init+0x49d/0x6d3 kernel/printk/printk.c:2915\n       start_kernel+0x5e9/0x879 init/main.c:713\n       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241\n\n-\u0026gt; #0 (console_owner){....}-{0:0}:\n       [...]\n       lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734\n       console_trylock_spinning kernel/printk/printk.c:1773 \n---truncated---(CVE-2022-49441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix listen() setting the bar too high for the prealloc rings\n\nAF_RXRPC\u0026apos;s listen() handler lets you set the backlog up to 32 (if you bump\nup the sysctl), but whilst the preallocation circular buffers have 32 slots\nin them, one of them has to be a dead slot because we\u0026apos;re using CIRC_CNT().\n\nThis means that listen(rxrpc_sock, 32) will cause an oops when the socket\nis closed because rxrpc_service_prealloc_one() allocated one too many calls\nand rxrpc_discard_prealloc() won\u0026apos;t then be able to get rid of them because\nit\u0026apos;ll think the ring is empty.  rxrpc_release_calls_on_socket() then tries\nto abort them, but oopses because call-\u0026gt;peer isn\u0026apos;t yet set.\n\nFix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match\nthe ring capacity.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000086\n ...\n RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __wake_up_common_lock+0x7a/0x90\n  ? rxrpc_notify_socket+0x8e/0x140 [rxrpc]\n  ? rxrpc_abort_call+0x4c/0x60 [rxrpc]\n  rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]\n  rxrpc_release+0xc9/0x1c0 [rxrpc]\n  __sock_release+0x37/0xa0\n  sock_close+0x11/0x20\n  __fput+0x89/0x240\n  task_work_run+0x59/0x90\n  do_exit+0x319/0xaa0(CVE-2022-49450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scmi: Fix list protocols enumeration in the base protocol\n\nWhile enumerating protocols implemented by the SCMI platform using\nBASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is\ncurrently validated in an improper way since the check employs a sum\nbetween unsigned integers that could overflow and cause the check itself\nto be silently bypassed if the returned value \u0026apos;loop_num_ret\u0026apos; is big\nenough.\n\nFix the validation avoiding the addition.(CVE-2022-49451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: msm: fix possible memory leak in mdp5_crtc_cursor_set()\n\ndrm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo\nneeds to be put when msm_gem_get_and_pin_iova fails.(CVE-2022-49467)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt\n\nof_node_get() returns a node with refcount incremented.\nCalling of_node_put() to drop the reference when not needed anymore.(CVE-2022-49481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/rockchip: vop: fix possible null-ptr-deref in vop_bind()\n\nIt will cause null-ptr-deref in resource_size(), if platform_get_resource()\nreturns NULL, move calling resource_size() after devm_ioremap_resource() that\nwill check \u0026apos;res\u0026apos; to avoid null-ptr-deref.(CVE-2022-49491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: pmac32-cpufreq: Fix refcount leak bug\n\nIn pmac_cpufreq_init_MacRISC3(), we need to add corresponding\nof_node_put() for the three node pointers whose refcount have\nbeen incremented by of_find_node_by_name().(CVE-2022-49621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()\n\nIn fsl_mc_bus_remove(), mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io is passed to\nfsl_destroy_mc_io(). However, mc-\u0026gt;root_mc_bus_dev is already freed in\nfsl_mc_device_remove(). Then reference to mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io\ntriggers KASAN use-after-free. To avoid the use-after-free, keep the\nreference to mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io in a local variable and pass to\nfsl_destroy_mc_io().\n\nThis patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init\n\nIf the function sdma_load_context() fails, the sdma_desc will be\nfreed, but the allocated desc-\u0026gt;bd is forgot to be freed.\n\nWe already met the sdma_load_context() failure case and the log as\nbelow:\n[ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready\n...\n\nIn this case, the desc-\u0026gt;bd will not be freed without this change.(CVE-2022-49746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix double increment of client_count in dma_chan_get()\n\nThe first time dma_chan_get() is called for a channel the channel\nclient_count is incorrectly incremented twice for public channels,\nfirst in balance_ref_count(), and again prior to returning. This\nresults in an incorrect client count which will lead to the\nchannel resources not being freed when they should be. A simple\n test of repeated module load and unload of async_tx on a Dell\n Power Edge R7425 also shows this resulting in a kref underflow\n warning.\n\n[  124.329662] async_tx: api initialized (async)\n[  129.000627] async_tx: api initialized (async)\n[  130.047839] ------------[ cut here ]------------\n[  130.052472] refcount_t: underflow; use-after-free.\n[  130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28\nrefcount_warn_saturate+0xba/0x110\n[  130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr\nintel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm\nmgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si\nsyscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops\nk10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat\nfat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul\nlibahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas\ni40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash\ndm_log dm_mod [last unloaded: async_tx]\n[  130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not\ntainted 5.14.0-185.el9.x86_64 #1\n[  130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS\n1.18.0 01/17/2022\n[  130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110\n[  130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d\n26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a\nbd 55 00 \u0026lt;0f\u0026gt; 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff\n48 c7\n[  130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286\n[  130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000\n[  130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0\n[  130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff\n[  130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970\n[  130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  130.198739] FS:  00007f646435c740(0000) GS:ffff9daf9de00000(0000)\nknlGS:0000000000000000\n[  130.206832] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0\n[  130.219729] Call Trace:\n[  130.222192]  \u0026lt;TASK\u0026gt;\n[  130.224305]  dma_chan_put+0x10d/0x110\n[  130.227988]  dmaengine_put+0x7a/0xa0\n[  130.231575]  __do_sys_delete_module.constprop.0+0x178/0x280\n[  130.237157]  ? syscall_trace_enter.constprop.0+0x145/0x1d0\n[  130.242652]  do_syscall_64+0x5c/0x90\n[  130.246240]  ? exc_page_fault+0x62/0x150\n[  130.250178]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  130.255243] RIP: 0033:0x7f6463a3f5ab\n[  130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48\n83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00\n00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89\n01 48\n[  130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:\n00000000000000b0\n[  130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab\n[  130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8\n[  130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000\n[  130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8\n[  130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8\n[  130.320875]  \u0026lt;/TASK\u0026gt;\n[  130.323081] ---[ end trace eff7156d56b5cf25 ]---\n\ncat /sys/class/dma/dma0chan*/in_use would get the wrong result.\n2\n2\n2\n\nTest-by: Jie Hai \u0026lt;haijie1@huawei.com\u0026gt;(CVE-2022-49753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/highbank: Fix memory leak in highbank_mc_probe()\n\nWhen devres_open_group() fails, it returns -ENOMEM without freeing memory\nallocated by edac_mc_alloc().\n\nCall edac_mc_free() on the error handling path to avoid a memory leak.\n\n  [ bp: Massage commit message. ](CVE-2022-49757)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()\n\nsnd_hda_get_connections() can return a negative error code.\nIt may lead to accessing \u0026apos;conn\u0026apos; array at a negative index.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: betop: check shape of output reports\n\nbetopff_init() only checks the total sum of the report counts for each\nreport field to be at least 4, but hid_betopff_play() expects 4 report\nfields.\nA device advertising an output report with one field and 4 report counts\nwould pass the check but crash the kernel with a NULL pointer dereference\nin hid_betopff_play().(CVE-2023-53015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix pointer-leak due to insufficient speculative store bypass mitigation\n\nTo mitigate Spectre v4, 2039f26f3aca (\u0026quot;bpf: Fix leakage due to\ninsufficient speculative store bypass mitigation\u0026quot;) inserts lfence\ninstructions after 1) initializing a stack slot and 2) spilling a\npointer to the stack.\n\nHowever, this does not cover cases where a stack slot is first\ninitialized with a pointer (subject to sanitization) but then\noverwritten with a scalar (not subject to sanitization because\nthe slot was already initialized). In this case, the second write\nmay be subject to speculative store bypass (SSB) creating a\nspeculative pointer-as-scalar type confusion. This allows the\nprogram to subsequently leak the numerical pointer value using,\nfor example, a branch-based cache side channel.\n\nTo fix this, also sanitize scalars if they write a stack slot\nthat previously contained a pointer. Assuming that pointer-spills\nare only generated by LLVM on register-pressure, the performance\nimpact on most real-world BPF programs should be small.\n\nThe following unprivileged BPF bytecode drafts a minimal exploit\nand the mitigation:\n\n  [...]\n  // r6 = 0 or 1 (skalar, unknown user input)\n  // r7 = accessible ptr for side channel\n  // r10 = frame pointer (fp), to be leaked\n  //\n  r9 = r10 # fp alias to encourage ssb\n  *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked\n  // lfence added here because of pointer spill to stack.\n  //\n  // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor\n  // for no r9-r10 dependency.\n  //\n  *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr\n  // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,\n  // store may be subject to SSB\n  //\n  // fix: also add an lfence when the slot contained a ptr\n  //\n  r8 = *(u64 *)(r9 - 8)\n  // r8 = architecturally a scalar, speculatively a ptr\n  //\n  // leak ptr using branch-based cache side channel:\n  r8 \u0026amp;= 1 // choose bit to leak\n  if r8 == 0 goto SLOW // no mispredict\n  // architecturally dead code if input r6 is 0,\n  // only executes speculatively iff ptr bit is 1\n  r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)\nSLOW:\n  [...]\n\nAfter running this, the program can time the access to *(r7 + 0) to\ndetermine whether the chosen pointer bit was 0 or 1. Repeat this 64\ntimes to recover the whole address on amd64.\n\nIn summary, sanitization can only be skipped if one scalar is\noverwritten with another scalar. Scalar-confusion due to speculative\nstore bypass can not lead to invalid accesses because the pointer\nbounds deducted during verification are enforced using branchless\nlogic. See 979d63d50c0c (\u0026quot;bpf: prevent out of bounds speculation on\npointer arithmetic\u0026quot;) for details.\n\nDo not make the mitigation depend on !env-\u0026gt;allow_{uninit_stack,ptr_leaks}\nbecause speculative leaks are likely unexpected if these were enabled.\nFor example, leaking the address to a protected log file may be acceptable\nwhile disabling the mitigation might unintentionally leak the address\ninto the cached-state of a map that is accessible to unprivileged\nprocesses.(CVE-2023-53024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix double free in error path\n\nIf the uvc_status_init() function fails to allocate the int_urb, it will\nfree the dev-\u0026gt;status pointer but doesn\u0026apos;t reset the pointer to NULL. This\nresults in the kfree() call in uvc_status_cleanup() trying to\ndouble-free the memory. Fix it by resetting the dev-\u0026gt;status pointer to\nNULL after freeing it.\n\nReviewed by: Ricardo Ribalda \u0026lt;ribalda@chromium.org\u0026gt;(CVE-2024-57980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: don\u0026apos;t allow 1 packet limit\n\nThe current implementation does not work correctly with a limit of\n1. iproute2 actually checks for this and this patch adds the check in\nkernel as well.\n\nThis fixes the following syzkaller reported crash:\n\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n  __dump_stack lib/dump_stack.c:79 [inline]\n  dump_stack+0x125/0x19f lib/dump_stack.c:120\n  ubsan_epilogue lib/ubsan.c:148 [inline]\n  __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347\n  sfq_link net/sched/sch_sfq.c:210 [inline]\n  sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238\n  sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500\n  sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525\n  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n  tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319\n  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n  dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296\n  netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]\n  dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362\n  __dev_close_many+0x214/0x350 net/core/dev.c:1468\n  dev_close_many+0x207/0x510 net/core/dev.c:1506\n  unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738\n  unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695\n  unregister_netdevice include/linux/netdevice.h:2893 [inline]\n  __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689\n  tun_detach drivers/net/tun.c:705 [inline]\n  tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640\n  __fput+0x203/0x840 fs/file_table.c:280\n  task_work_run+0x129/0x1b0 kernel/task_work.c:185\n  exit_task_work include/linux/task_work.h:33 [inline]\n  do_exit+0x5ce/0x2200 kernel/exit.c:931\n  do_group_exit+0x144/0x310 kernel/exit.c:1046\n  __do_sys_exit_group kernel/exit.c:1057 [inline]\n  __se_sys_exit_group kernel/exit.c:1055 [inline]\n  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055\n do_syscall_64+0x6c/0xd0\n entry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fe5e7b52479\nCode: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.\nRSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000\nRBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0\nR13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270\n\nThe crash can be also be reproduced with the following (with a tc\nrecompiled to allow for sfq limits of 1):\n\ntc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s\n../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1\nifconfig dummy0 up\nping -I dummy0 -f -c2 -W0.1 8.8.8.8\nsleep 1\n\nScenario that triggers the crash:\n\n* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1\n\n* TBF dequeues: it peeks from SFQ which moves the packet to the\n  gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so\n  it schedules itself for later.\n\n* the second packet is sent and TBF tries to queues it to SFQ. qdisc\n  qlen is now 2 and because the SFQ limit is 1 the packet is dropped\n  by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,\n  however q-\u0026gt;tail is not NULL.\n\nAt this point, assuming no more packets are queued, when sch_dequeue\nruns again it will decrement the qlen for the current empty slot\ncausing an underflow and the subsequent out of bounds access.(CVE-2024-57996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npartitions: mac: fix handling of bogus partition table\n\nFix several issues in partition probing:\n\n - The bailout for a bad partoffset must use put_dev_sector(), since the\n   preceding read_part_sector() succeeded.\n - If the partition table claims a silly sector size like 0xfff bytes\n   (which results in partition table entries straddling sector boundaries),\n   bail out instead of accessing out-of-bounds memory.\n - We must not assume that the partition table contains proper NUL\n   termination - use strnlen() and strncmp() instead of strlen() and\n   strcmp().(CVE-2025-21772)","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-2504.2.0.0323.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2504.2.0.0323.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49100"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49370"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49390"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49396"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49441"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49451"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49467"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49481"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49491"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49621"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49711"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49746"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49757"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52988"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53024"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21772"}],"database_specific":{"severity":"High"}}