{"schema_version":"1.7.2","id":"OESA-2025-1340","modified":"2025-03-29T06:23:56Z","published":"2025-03-29T06:23:56Z","upstream":["CVE-2024-56642","CVE-2024-56648","CVE-2024-56670","CVE-2024-57973","CVE-2024-57978","CVE-2024-57986","CVE-2024-57993","CVE-2024-57997","CVE-2024-57998","CVE-2024-58006","CVE-2024-58034","CVE-2024-58051","CVE-2024-58052","CVE-2024-58053","CVE-2024-58054","CVE-2024-58056","CVE-2024-58058","CVE-2024-58061","CVE-2024-58063","CVE-2024-58068","CVE-2024-58071","CVE-2024-58072","CVE-2025-21687","CVE-2025-21705","CVE-2025-21707","CVE-2025-21708","CVE-2025-21710","CVE-2025-21711","CVE-2025-21715","CVE-2025-21716","CVE-2025-21720","CVE-2025-21724","CVE-2025-21725","CVE-2025-21726","CVE-2025-21727","CVE-2025-21728","CVE-2025-21745","CVE-2025-21799","CVE-2025-21803","CVE-2025-21804","CVE-2025-21806","CVE-2025-21808","CVE-2025-21810","CVE-2025-21811","CVE-2025-21812","CVE-2025-21828","CVE-2025-21853"],"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\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count.  However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n     sk_alloc+0x438/0x608\n     inet_create+0x4c8/0xcb0\n     __sock_create+0x350/0x6b8\n     sock_create_kern+0x58/0x78\n     udp_sock_create4+0x68/0x398\n     udp_sock_create+0x88/0xc8\n     tipc_udp_enable+0x5e8/0x848\n     __tipc_nl_bearer_enable+0x84c/0xed8\n     tipc_nl_bearer_enable+0x38/0x60\n     genl_family_rcv_msg_doit+0x170/0x248\n     genl_rcv_msg+0x400/0x5b0\n     netlink_rcv_skb+0x1dc/0x398\n     genl_rcv+0x44/0x68\n     netlink_unicast+0x678/0x8b0\n     netlink_sendmsg+0x5e4/0x898\n     ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n  xmit_one net/core/dev.c:3590 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n  dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3146 [inline]\n  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4091 [inline]\n  slab_alloc_node mm/slub.c:4134 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n  alloc_skb include/linux/skbuff.h:1323 [inline]\n  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n  packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n  packet_snd net/packet/af_packet.c:3089 [inline]\n  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer\n\nConsidering that in some extreme cases,\nwhen u_serial driver is accessed by multiple threads,\nThread A is executing the open operation and calling the gs_open,\nThread B is executing the disconnect operation and calling the\ngserial_disconnect function,The port-\u0026gt;port_usb pointer will be set to NULL.\n\nE.g.\n    Thread A                                 Thread B\n    gs_open()                                gadget_unbind_driver()\n    gs_start_io()                            composite_disconnect()\n    gs_start_rx()                            gserial_disconnect()\n    ...                                      ...\n    spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n    status = usb_ep_queue()                  spin_lock(\u0026amp;port-\u0026gt;port_lock)\n    spin_lock(\u0026amp;port-\u0026gt;port_lock)              port-\u0026gt;port_usb = NULL\n    gs_free_requests(port-\u0026gt;port_usb-\u0026gt;in)     spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n    Crash\n\nThis causes thread A to access a null pointer (port-\u0026gt;port_usb is null)\nwhen calling the gs_free_requests function, causing a crash.\n\nIf port_usb is NULL, the release request will be skipped as it\nwill be done by gserial_disconnect.\n\nSo add a null pointer check to gs_start_io before attempting\nto access the value of the pointer port-\u0026gt;port_usb.\n\nCall trace:\n gs_start_io+0x164/0x25c\n gs_open+0x108/0x13c\n tty_open+0x314/0x638\n chrdev_open+0x1b8/0x258\n do_dentry_open+0x2c4/0x700\n vfs_open+0x2c/0x3c\n path_openat+0xa64/0xc60\n do_filp_open+0xb8/0x164\n do_sys_openat2+0x84/0xf0\n __arm64_sys_openat+0x70/0x9c\n invoke_syscall+0x58/0x114\n el0_svc_common+0x80/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x38/0x68(CVE-2024-56670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrdma/cxgb4: Prevent potential integer overflow on 32bit\n\nThe \u0026quot;gl-\u0026gt;tot_len\u0026quot; variable is controlled by the user.  It comes from\nprocess_responses().  On 32bit systems, the \u0026quot;gl-\u0026gt;tot_len + sizeof(struct\ncpl_pass_accept_req) + sizeof(struct rss_header)\u0026quot; addition could have an\ninteger wrapping bug.  Use size_add() to prevent this.(CVE-2024-57973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imx-jpeg: Fix potential error pointer dereference in detach_pm()\n\nThe proble is on the first line:\n\n\tif (jpeg-\u0026gt;pd_dev[i] \u0026amp;\u0026amp; !pm_runtime_suspended(jpeg-\u0026gt;pd_dev[i]))\n\nIf jpeg-\u0026gt;pd_dev[i] is an error pointer, then passing it to\npm_runtime_suspended() will lead to an Oops.  The other conditions\ncheck for both error pointers and NULL, but it would be more clear to\nuse the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Fix assumption that Resolution Multipliers must be in Logical Collections\n\nA report in 2019 by the syzbot fuzzer was found to be connected to two\nerrors in the HID core associated with Resolution Multipliers.  One of\nthe errors was fixed by commit ea427a222d8b (\u0026quot;HID: core: Fix deadloop\nin hid_apply_multiplier.\u0026quot;), but the other has not been fixed.\n\nThis error arises because hid_apply_multipler() assumes that every\nResolution Multiplier control is contained in a Logical Collection,\ni.e., there\u0026apos;s no way the routine can ever set multiplier_collection to\nNULL.  This is in spite of the fact that the function starts with a\nbig comment saying:\n\n\t * \u0026quot;The Resolution Multiplier control must be contained in the same\n\t * Logical Collection as the control(s) to which it is to be applied.\n\t   ...\n\t *  If no Logical Collection is\n\t * defined, the Resolution Multiplier is associated with all\n\t * controls in the report.\u0026quot;\n\t * HID Usage Table, v1.12, Section 4.3.1, p30\n\t *\n\t * Thus, search from the current collection upwards until we find a\n\t * logical collection...\n\nThe comment and the code overlook the possibility that none of the\ncollections found may be a Logical Collection.\n\nThe fix is to set the multiplier_collection pointer to NULL if the\ncollection found isn\u0026apos;t a Logical Collection.(CVE-2024-57986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check\n\nsyzbot has found a type mismatch between a USB pipe and the transfer\nendpoint, which is triggered by the hid-thrustmaster driver[1].\nThere is a number of similar, already fixed issues [2].\nIn this case as in others, implementing check for endpoint type fixes the issue.\n\n[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470\n[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wcn36xx: fix channel survey memory allocation size\n\nKASAN reported a memory allocation issue in wcn-\u0026gt;chan_survey\ndue to incorrect size calculation.\nThis commit uses kcalloc to allocate memory for wcn-\u0026gt;chan_survey,\nensuring proper initialization and preventing the use of uninitialized\nvalues when there are no frames on the channel.(CVE-2024-57997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: add index check to assert to avoid buffer overflow in _read_freq()\n\nPass the freq index to the assert function to make sure\nwe do not read a freq out of the opp-\u0026gt;rates[] table when called\nfrom the indexed variants:\ndev_pm_opp_find_freq_exact_indexed() or\ndev_pm_opp_find_freq_ceil/floor_indexed().\n\nAdd a secondary parameter to the assert function, unused\nfor assert_single_clk() then add assert_clk_index() which\nwill check for the clock index when called from the _indexed()\nfind functions.(CVE-2024-57998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()\n\nIn commit 4284c88fff0e (\u0026quot;PCI: designware-ep: Allow pci_epc_set_bar() update\ninbound map address\u0026quot;) set_bar() was modified to support dynamically\nchanging the backing physical address of a BAR that was already configured.\n\nThis means that set_bar() can be called twice, without ever calling\nclear_bar() (as calling clear_bar() would clear the BAR\u0026apos;s PCI address\nassigned by the host).\n\nThis can only be done if the new BAR size/flags does not differ from the\nexisting BAR configuration. Add these missing checks.\n\nIf we allow set_bar() to set e.g. a new BAR size that differs from the\nexisting BAR size, the new address translation range will be smaller than\nthe BAR size already determined by the host, which would mean that a read\npast the new BAR size would pass the iATU untranslated, which could allow\nthe host to read memory not belonging to the new struct pci_epf_bar.\n\nWhile at it, add comments which clarifies the support for dynamically\nchanging the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi: ipmb: Add check devm_kasprintf() returned value\n\ndevm_kasprintf() can return a NULL pointer on failure but this\nreturned value is not checked.(CVE-2024-58051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table\n\nThe function atomctrl_get_smc_sclk_range_table() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to\nretrieve SMU_Info table, it returns NULL which is later dereferenced.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\nIn practice this should never happen as this code only gets called\non polaris chips and the vbios data table will always be present on\nthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix handling of received connection abort\n\nFix the handling of a connection abort that we\u0026apos;ve received.  Though the\nabort is at the connection level, it needs propagating to the calls on that\nconnection.  Whilst the propagation bit is performed, the calls aren\u0026apos;t then\nwoken up to go and process their termination, and as no further input is\nforthcoming, they just hang.\n\nAlso add some tracing for the logging of connection aborts.(CVE-2024-58053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: media: max96712: fix kernel oops when removing module\n\nThe following kernel oops is thrown when trying to remove the max96712\nmodule:\n\nUnable to handle kernel paging request at virtual address 00007375746174db\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000\n[00007375746174db] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan\n    snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2\n    imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev\n    snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils\n    max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse\n    [last unloaded: imx8_isi]\nCPU: 0 UID: 0 PID: 754 Comm: rmmod\n\t    Tainted: G         C    6.12.0-rc6-06364-g327fec852c31 #17\nTainted: [C]=CRAP\nHardware name: NXP i.MX95 19X19 board (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : led_put+0x1c/0x40\nlr : v4l2_subdev_put_privacy_led+0x48/0x58\nsp : ffff80008699bbb0\nx29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000\nx26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8\nx20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000\nx11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010\nx8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\nx5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1\nx2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473\nCall trace:\n led_put+0x1c/0x40\n v4l2_subdev_put_privacy_led+0x48/0x58\n v4l2_async_unregister_subdev+0x2c/0x1a4\n max96712_remove+0x1c/0x38 [max96712]\n i2c_device_remove+0x2c/0x9c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x228\n driver_detach+0x4c/0x98\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n i2c_del_driver+0x54/0x64\n max96712_i2c_driver_exit+0x18/0x1d0 [max96712]\n __arm64_sys_delete_module+0x1a4/0x290\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xd8\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x190/0x194\nCode: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)\n---[ end trace 0000000000000000 ]---\n\nThis happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()\nis called again and the data is overwritten to point to sd, instead of\npriv. So, in remove(), the wrong pointer is passed to\nv4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Fix ida_free call while not allocated\n\nIn the rproc_alloc() function, on error, put_device(\u0026amp;rproc-\u0026gt;dev) is\ncalled, leading to the call of the rproc_type_release() function.\nAn error can occurs before ida_alloc is called.\n\nIn such case in rproc_type_release(), the condition (rproc-\u0026gt;index \u0026gt;= 0) is\ntrue as rproc-\u0026gt;index has been  initialized to 0.\nida_free() is called reporting a warning:\n[    4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164\n[    4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0\n[    4.188854] ida_free called for id=0 which is not allocated.\n[    4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000\n[    4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)\n[    4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442\n[    4.231481] Hardware name: STM32 (Device Tree Support)\n[    4.236627] Workqueue: events_unbound deferred_probe_work_func\n[    4.242504] Call trace:\n[    4.242522]  unwind_backtrace from show_stack+0x10/0x14\n[    4.250218]  show_stack from dump_stack_lvl+0x50/0x64\n[    4.255274]  dump_stack_lvl from __warn+0x80/0x12c\n[    4.260134]  __warn from warn_slowpath_fmt+0x114/0x188\n[    4.265199]  warn_slowpath_fmt from ida_free+0x100/0x164\n[    4.270565]  ida_free from rproc_type_release+0x38/0x60\n[    4.275832]  rproc_type_release from device_release+0x30/0xa0\n[    4.281601]  device_release from kobject_put+0xc4/0x294\n[    4.286762]  kobject_put from rproc_alloc.part.0+0x208/0x28c\n[    4.292430]  rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4\n[    4.298393]  devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]\n[    4.305575]  stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc\n\nCalling ida_alloc earlier in rproc_alloc ensures that the rproc-\u0026gt;index is\nproperly set.(CVE-2024-58056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubifs: skip dumping tnc tree when zroot is null\n\nClearing slab cache will free all znode in memory and make\nc-\u0026gt;zroot.znode = NULL, then dumping tnc tree will access\nc-\u0026gt;zroot.znode which cause null pointer dereference.(CVE-2024-58058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: prohibit deactivating all links\n\nIn the internal API this calls this is a WARN_ON, but that\nshould remain since internally we want to know about bugs\nthat may cause this. Prevent deactivating all links in the\ndebugfs write directly.(CVE-2024-58061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: fix memory leaks and invalid access at probe error path\n\nDeinitialize at reverse order when probe fails.\n\nWhen init_sw_vars fails, rtl_deinit_core should not be called, specially\nnow that it destroys the rtl_wq workqueue.\n\nAnd call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be\nleaked.\n\nRemove pci_set_drvdata call as it will already be cleaned up by the core\ndriver code and could lead to memory leaks too. cf. commit 8d450935ae7f\n(\u0026quot;wireless: rtlwifi: remove unnecessary pci_set_drvdata()\u0026quot;) and\ncommit 3d86b93064c7 (\u0026quot;rtlwifi: Fix PCI probe error path orphaned memory\u0026quot;).(CVE-2024-58063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized\n\nIf a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth\nfrom the OPP table but the bandwidth table was not created because the\ninterconnect properties were missing in the OPP consumer node, the\nkernel will crash with:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n...\npc : _read_bw+0x8/0x10\nlr : _opp_table_find_key+0x9c/0x174\n...\nCall trace:\n  _read_bw+0x8/0x10 (P)\n  _opp_table_find_key+0x9c/0x174 (L)\n  _find_key+0x98/0x168\n  dev_pm_opp_find_bw_ceil+0x50/0x88\n...\n\nIn order to fix the crash, create an assert function to check\nif the bandwidth table was created before trying to get a\nbandwidth with _read_bw().(CVE-2024-58068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: prevent adding a device which is already a team device lower\n\nPrevent adding a device which is already a team device lower,\ne.g. adding veth0 if vlan1 was already added and veth0 is a lower of\nvlan1.\n\nThis is not useful in practice and can lead to recursive locking:\n\n$ ip link add veth0 type veth peer name veth1\n$ ip link set veth0 up\n$ ip link set veth1 up\n$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1\n$ ip link add team0 type team\n$ ip link set veth0.1 down\n$ ip link set veth0.1 master team0\nteam0: Port device veth0.1 added\n$ ip link set veth0 down\n$ ip link set veth0 master team0\n\n============================================\nWARNING: possible recursive locking detected\n6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted\n--------------------------------------------\nip/7684 is trying to acquire lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n\nbut task is already holding lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\n\nCPU0\n----\nlock(team-\u0026gt;team_lock_key);\nlock(team-\u0026gt;team_lock_key);\n\n*** DEADLOCK ***\n\nMay be due to missing lock nesting notation\n\n2 locks held by ip/7684:\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:122)\nprint_deadlock_bug.cold (kernel/locking/lockdep.c:3040)\n__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)\n? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)\nlock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? lock_acquire (kernel/locking/lockdep.c:5822)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? fib_sync_up (net/ipv4/fib_semantics.c:2167)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nteam_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\n__dev_notify_flags (net/core/dev.c:8993)\n? __dev_change_flags (net/core/dev.c:8975)\ndev_change_flags (net/core/dev.c:9027)\nvlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)\n? br_device_event (net/bridge/br.c:143)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\ndev_open (net/core/dev.c:1519 net/core/dev.c:1505)\nteam_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)\n? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)\ndo_set_master (net/core/rtnetlink.c:2917)\ndo_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: remove unused check_buddy_priv\n\nCommit 2461c7d60f9f (\u0026quot;rtlwifi: Update header file\u0026quot;) introduced a global\nlist of private data structures.\n\nLater on, commit 26634c4b1868 (\u0026quot;rtlwifi Modify existing bits to match\nvendor version 2013.02.07\u0026quot;) started adding the private data to that list at\nprobe time and added a hook, check_buddy_priv to find the private data from\na similar device.\n\nHowever, that function was never used.\n\nBesides, though there is a lock for that list, it is never used. And when\nthe probe fails, the private data is never removed from the list. This\nwould cause a second probe to access freed memory.\n\nRemove the unused hook, structures and members, which will prevent the\npotential race condition on the list and its corruption during a second\nprobe when probe fails.(CVE-2024-58072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: handle fastopen disconnect correctly\n\nSyzbot was able to trigger a data stream corruption:\n\n  WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0\n  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n  RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n  Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 \u0026lt;0f\u0026gt; 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07\n  RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293\n  RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000\n  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n  RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928\n  R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000\n  R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000\n  FS:  00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074\n   mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493\n   release_sock+0x1aa/0x1f0 net/core/sock.c:3640\n   inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]\n   __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703\n   mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755\n   mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830\n   sock_sendmsg_nosec net/socket.c:711 [inline]\n   __sock_sendmsg+0x1a6/0x270 net/socket.c:726\n   ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583\n   ___sys_sendmsg net/socket.c:2637 [inline]\n   __sys_sendmsg+0x269/0x350 net/socket.c:2669\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f6e86ebfe69\n  Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n  RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69\n  RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003\n  RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc\n  R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508\n   \u0026lt;/TASK\u0026gt;\n\nThe root cause is the bad handling of disconnect() generated internally\nby the MPTCP protocol in case of connect FASTOPEN errors.\n\nAddress the issue increasing the socket disconnect counter even on such\na case, to allow other threads waiting on the same socket lock to\nproperly error out.(CVE-2025-21705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: consolidate suboption status\n\nMPTCP maintains the received sub-options status is the bitmask carrying\nthe received suboptions and in several bitfields carrying per suboption\nadditional info.\n\nZeroing the bitmask before parsing is not enough to ensure a consistent\nstatus, and the MPTCP code has to additionally clear some bitfiled\ndepending on the actually parsed suboption.\n\nThe above schema is fragile, and syzbot managed to trigger a path where\na relevant bitfield is not cleared/initialized:\n\n  BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n  BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n  BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]\n  BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n   __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n   mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n   ack_update_msk net/mptcp/options.c:1060 [inline]\n   mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n   tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233\n   tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264\n   tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916\n   tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351\n   ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205\n   ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233\n   NF_HOOK include/linux/netfilter.h:314 [inline]\n   ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n   dst_input include/net/dst.h:460 [inline]\n   ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447\n   NF_HOOK include/linux/netfilter.h:314 [inline]\n   ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567\n   __netif_receive_skb_one_core net/core/dev.c:5704 [inline]\n   __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817\n   process_backlog+0x4ad/0xa50 net/core/dev.c:6149\n   __napi_poll+0xe7/0x980 net/core/dev.c:6902\n   napi_poll net/core/dev.c:6971 [inline]\n   net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093\n   handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561\n   __do_softirq+0x14/0x1a kernel/softirq.c:595\n   do_softirq+0x9a/0x100 kernel/softirq.c:462\n   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389\n   local_bh_enable include/linux/bottom_half.h:33 [inline]\n   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n   __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493\n   dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n   neigh_hh_output include/net/neighbour.h:523 [inline]\n   neigh_output include/net/neighbour.h:537 [inline]\n   ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236\n   __ip_finish_output+0x287/0x810\n   ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324\n   NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n   ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434\n   dst_output include/net/dst.h:450 [inline]\n   ip_local_out net/ipv4/ip_output.c:130 [inline]\n   __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536\n   ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550\n   __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468\n   tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]\n   tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829\n   __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012\n   tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618\n   __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130\n   __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496\n   mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550\n   mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889\n   mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]\n   mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]\n   mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]\n   mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750\n   genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n \n---truncated---(CVE-2025-21707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: enable basic endpoint checking\n\nSyzkaller reports [1] encountering a common issue of utilizing a wrong\nusb endpoint type during URB submitting stage. This, in turn, triggers\na warning shown below.\n\nFor now, enable simple endpoint checking (specifically, bulk and\ninterrupt eps, testing control one is not essential) to mitigate\nthe issue with a view to do other related cosmetic changes later,\nif they are necessary.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv\u0026gt;\nModules linked in:\nCPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617\u0026gt;\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nCode: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8\u0026gt;\nRSP: 0018:ffffc9000441f740 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9\nRDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001\nRBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c\nFS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733\n __dev_open+0x2d4/0x4e0 net/core/dev.c:1474\n __dev_change_flags+0x561/0x720 net/core/dev.c:8838\n dev_change_flags+0x8f/0x160 net/core/dev.c:8910\n devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177\n inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003\n sock_do_ioctl+0x116/0x280 net/socket.c:1222\n sock_ioctl+0x22e/0x6c0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fc04ef73d49\n...\n\nThis change has not been tested on real hardware.(CVE-2025-21708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \u0026quot;pasta\u0026quot; protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0026apos;t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0026apos;s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n//              tcp_v4_rcv(-\u0026gt;)\n//                tcp_rcv_established(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u0026lt;-\u0026gt;39222]:     tcp_data_queue(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n                       [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                       [copied_seq 259909392-\u0026gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n                       [OFO queue: gap: 65480, len: 0]\n[5201\u0026lt;-\u0026gt;39222]:     tcp_data_queue(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]:     __tcp_transmit_skb(-\u0026gt;)\n                        [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]:       tcp_select_window(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]:         (inet_csk(sk)-\u0026gt;icsk_ack.pending \u0026amp; ICSK_ACK_NOMEM) ? --\u0026gt; TRUE\n                        [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n                        returning 0\n[5201\u0026lt;-\u0026gt;39222]:       tcp_select_window(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u0026lt;-\u0026gt;39222]:     [__tcp_transmit_skb(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]:   tcp_rcv_established(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_v4_rcv(\u0026lt;-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0026apos;t update tp-\u0026gt;rcv_wnd and tp-\u0026gt;rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]:   __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u0026lt;-\u0026gt;39222]:     [new_win \u0026gt;= (2 * win_now) ? --\u0026gt; time_to_ack = 0]\n[5201\u0026lt;-\u0026gt;39222]:     NOT calling tcp_send_ack()\n                    [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]:   __tcp_cleanup_rbuf(\u0026lt;-)\n                  [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                  [copied_seq 260040464-\u0026gt;260040464 (0), unread 5559696, qlen 85, ofoq 0]\n                  returning 6104 bytes\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(\u0026lt;-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u0026gt;rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]:   __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]:     [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---(CVE-2025-21710)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rose: prevent integer overflows in rose_setsockopt()\n\nIn case of possible unpredictably large arguments passed to\nrose_setsockopt() and multiplied by extra values on top of that,\ninteger overflows may occur.\n\nDo the safest minimum and fix these issues by checking the\ncontents of \u0026apos;opt\u0026apos; and returning -EINVAL if they are too large. Also,\nswitch to unsigned int and remove useless check for negative \u0026apos;opt\u0026apos;\nin ROSE_IDLE case.(CVE-2025-21711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix uninit-value in vxlan_vnifilter_dump()\n\nKMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].\n\nIf the length of the netlink message payload is less than\nsizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes\nbeyond the message. This can lead to uninit-value access. Fix this by\nreturning an error in such situations.\n\n[1]\nBUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786\n netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317\n __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432\n netlink_dump_start include/linux/netlink.h:340 [inline]\n rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]\n rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882\n netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542\n rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4110 [inline]\n slab_alloc_node mm/slub.c:4153 [inline]\n kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205\n kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587\n __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196\n netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete intermediate secpath entry in packet offload mode\n\nPackets handled by hardware have added secpath as a way to inform XFRM\ncore code that this path was already handled. That secpath is not needed\nat all after policy is checked and it is removed later in the stack.\n\nHowever, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),\nthat secpath is not removed and packets which already were handled are reentered\nto the driver TX path with xfrm_offload set.\n\nThe following kernel panic is observed in mlx5 in such case:\n\n mlx5_core 0000:04:00.0 enp4s0f0np0: Link up\n mlx5_core 0000:04:00.1 enp4s0f1np1: Link up\n Initializing XFRM netlink socket\n IPsec XFRM device driver\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor instruction fetch in kernel mode\n #PF: error_code(0x0010) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0010 [#1] PREEMPT SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 0018:ffffb87380003800 EFLAGS: 00010206\n RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf\n RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00\n RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010\n R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00\n R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e\n FS:  0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  ? show_regs+0x63/0x70\n  ? __die_body+0x20/0x60\n  ? __die+0x2b/0x40\n  ? page_fault_oops+0x15c/0x550\n  ? do_user_addr_fault+0x3ed/0x870\n  ? exc_page_fault+0x7f/0x190\n  ? asm_exc_page_fault+0x27/0x30\n  mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]\n  mlx5e_xmit+0x58e/0x1980 [mlx5_core]\n  ? __fib_lookup+0x6a/0xb0\n  dev_hard_start_xmit+0x82/0x1d0\n  sch_direct_xmit+0xfe/0x390\n  __dev_queue_xmit+0x6d8/0xee0\n  ? __fib_lookup+0x6a/0xb0\n  ? internal_add_timer+0x48/0x70\n  ? mod_timer+0xe2/0x2b0\n  neigh_resolve_output+0x115/0x1b0\n  __neigh_update+0x26a/0xc50\n  neigh_update+0x14/0x20\n  arp_process+0x2cb/0x8e0\n  ? __napi_build_skb+0x5e/0x70\n  arp_rcv+0x11e/0x1c0\n  ? dev_gro_receive+0x574/0x820\n  __netif_receive_skb_list_core+0x1cf/0x1f0\n  netif_receive_skb_list_internal+0x183/0x2a0\n  napi_complete_done+0x76/0x1c0\n  mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]\n  __napi_poll+0x2d/0x1f0\n  net_rx_action+0x1a6/0x370\n  ? atomic_notifier_call_chain+0x3b/0x50\n  ? irq_int_handler+0x15/0x20 [mlx5_core]\n  handle_softirqs+0xb9/0x2f0\n  ? handle_irq_event+0x44/0x60\n  irq_exit_rcu+0xdb/0x100\n  common_interrupt+0x98/0xc0\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  asm_common_interrupt+0x27/0x40\n RIP: 0010:pv_native_safe_halt+0xb/0x10\n Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22\n 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb\n40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8\n RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680\n RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4\n RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70\n R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40\n R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8\n  ? default_idle+0x9/0x20\n  arch_cpu_idle+0x9/0x10\n  default_idle_call+0x29/0xf0\n  do_idle+0x1f2/0x240\n  cpu_startup_entry+0x2c/0x30\n  rest_init+0xe7/0x100\n  start_kernel+0x76b/0xb90\n  x86_64_start_reservations+0x18/0x30\n  x86_64_start_kernel+0xc0/0x110\n  ? setup_ghcb+0xe/0x130\n  common_startup_64+0x13e/0x141\n  \u0026lt;/TASK\u0026gt;\n Modules linked in: esp4_offload esp4 xfrm_interface\nxfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf\n---truncated---(CVE-2025-21720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()\n\nResolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()\nwhere shifting the constant \u0026quot;1\u0026quot; (of type int) by bitmap-\u0026gt;mapped.pgshift\n(an unsigned long value) could result in undefined behavior.\n\nThe constant \u0026quot;1\u0026quot; defaults to a 32-bit \u0026quot;int\u0026quot;, and when \u0026quot;pgshift\u0026quot; exceeds\n31 (e.g., pgshift = 63) the shift operation overflows, as the result\ncannot be represented in a 32-bit type.\n\nTo resolve this, the constant is updated to \u0026quot;1UL\u0026quot;, promoting it to an\nunsigned long type to match the operand\u0026apos;s type.(CVE-2025-21724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix oops due to unset link speed\n\nIt isn\u0026apos;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always\nbe set by the server, so the client must handle any values and then\nprevent oopses like below from happening:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nRIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48\n89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8\ne7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 \u0026lt;48\u0026gt; f7 74 24 18 48 89\nc3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24\nRSP: 0018:ffffc90001817be0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99\nRDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228\nRBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac\nR10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200\nR13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58\nFS: 00007fe27119e740(0000) GS:ffff888148600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0x159/0x1b0\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? do_error_trap+0x90/0x130\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? exc_divide_error+0x39/0x50\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? asm_exc_divide_error+0x1a/0x20\n ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? seq_read_iter+0x42e/0x790\n seq_read_iter+0x19a/0x790\n proc_reg_read_iter+0xbe/0x110\n ? __pfx_proc_reg_read_iter+0x10/0x10\n vfs_read+0x469/0x570\n ? do_user_addr_fault+0x398/0x760\n ? __pfx_vfs_read+0x10/0x10\n ? find_held_lock+0x8a/0xa0\n ? __pfx_lock_release+0x10/0x10\n ksys_read+0xd3/0x170\n ? __pfx_ksys_read+0x10/0x10\n ? __rcu_read_unlock+0x50/0x270\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe271288911\nCode: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8\n20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d\n00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911\nRDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003\nRBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\n\nFix this by setting cifs_server_iface::speed to a sane value (1Gbps)\nby default when link speed is unset.(CVE-2025-21725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n  ...\n  padata_reorder\n    // processes all remaining\n    // requests then breaks\n    while (1) {\n      if (!padata)\n        break;\n      ...\n    }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t  // new request added\n\t\t\t\t  list_add\n    // sees the new request\n    queue_work(reorder_work)\n\t\t\t\t  padata_reorder\n\t\t\t\t    queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t  // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n  // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Send signals asynchronously if !preemptible\n\nBPF programs can execute in all kinds of contexts and when a program\nrunning in a non-preemptible context uses the bpf_send_signal() kfunc,\nit will cause issues because this kfunc can sleep.\nChange `irqs_disabled()` to `!preemptible()`.(CVE-2025-21728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Fix class @block_class\u0026apos;s subsystem refcount leakage\n\nblkcg_fill_root_iostats() iterates over @block_class\u0026apos;s devices by\nclass_dev_iter_(init|next)(), but does not end iterating with\nclass_dev_iter_exit(), so causes the class\u0026apos;s subsystem refcount leakage.\n\nFix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()\n\nWhen getting the IRQ we use k3_udma_glue_tx_get_irq() which returns\nnegative error value on error. So not NULL check is not sufficient\nto deteremine if IRQ is valid. Check that IRQ is greater then zero\nto ensure it is valid.\n\nThere is no issue at probe time but at runtime user can invoke\n.set_channels which results in the following call chain.\nam65_cpsw_set_channels()\n am65_cpsw_nuss_update_tx_rx_chns()\n  am65_cpsw_nuss_remove_tx_chns()\n  am65_cpsw_nuss_init_tx_chns()\n\nAt this point if am65_cpsw_nuss_init_tx_chns() fails due to\nk3_udma_glue_tx_get_irq() then tx_chn-\u0026gt;irq will be set to a\nnegative value.\n\nThen, at subsequent .set_channels with higher channel count we\nwill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()\nleading to a kernel warning.\n\nThe issue is present in the original commit that introduced this driver,\nalthough there, am65_cpsw_nuss_update_tx_rx_chns() existed as\nam65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix warnings during S3 suspend\n\nThe enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),\nand the later one may call the preempt_schedule_common() function,\nresulting in a thread switch and causing the CPU to be in an interrupt\nenabled state after the enable_gpe_wakeup() function returns, leading\nto the warnings as follow.\n\n[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8\n[ C0]          ...\n[ C0] Call Trace:\n[ C0] [\u0026lt;90000000002243b4\u0026gt;] show_stack+0x64/0x188\n[ C0] [\u0026lt;900000000164673c\u0026gt;] dump_stack_lvl+0x60/0x88\n[ C0] [\u0026lt;90000000002687e4\u0026gt;] __warn+0x8c/0x148\n[ C0] [\u0026lt;90000000015e9978\u0026gt;] report_bug+0x1c0/0x2b0\n[ C0] [\u0026lt;90000000016478e4\u0026gt;] do_bp+0x204/0x3b8\n[ C0] [\u0026lt;90000000025b1924\u0026gt;] exception_handlers+0x1924/0x10000\n[ C0] [\u0026lt;9000000000343bbc\u0026gt;] ktime_get+0xbc/0xc8\n[ C0] [\u0026lt;9000000000354c08\u0026gt;] tick_sched_timer+0x30/0xb0\n[ C0] [\u0026lt;90000000003408e0\u0026gt;] __hrtimer_run_queues+0x160/0x378\n[ C0] [\u0026lt;9000000000341f14\u0026gt;] hrtimer_interrupt+0x144/0x388\n[ C0] [\u0026lt;9000000000228348\u0026gt;] constant_timer_interrupt+0x38/0x48\n[ C0] [\u0026lt;90000000002feba4\u0026gt;] __handle_irq_event_percpu+0x64/0x1e8\n[ C0] [\u0026lt;90000000002fed48\u0026gt;] handle_irq_event_percpu+0x20/0x80\n[ C0] [\u0026lt;9000000000306b9c\u0026gt;] handle_percpu_irq+0x5c/0x98\n[ C0] [\u0026lt;90000000002fd4a0\u0026gt;] generic_handle_domain_irq+0x30/0x48\n[ C0] [\u0026lt;9000000000d0c7b0\u0026gt;] handle_cpu_irq+0x70/0xa8\n[ C0] [\u0026lt;9000000001646b30\u0026gt;] handle_loongarch_irq+0x30/0x48\n[ C0] [\u0026lt;9000000001646bc8\u0026gt;] do_vint+0x80/0xe0\n[ C0] [\u0026lt;90000000002aea1c\u0026gt;] finish_task_switch.isra.0+0x8c/0x2a8\n[ C0] [\u0026lt;900000000164e34c\u0026gt;] __schedule+0x314/0xa48\n[ C0] [\u0026lt;900000000164ead8\u0026gt;] schedule+0x58/0xf0\n[ C0] [\u0026lt;9000000000294a2c\u0026gt;] worker_thread+0x224/0x498\n[ C0] [\u0026lt;900000000029d2f0\u0026gt;] kthread+0xf8/0x108\n[ C0] [\u0026lt;9000000000221f28\u0026gt;] ret_from_kernel_thread+0xc/0xa4\n[ C0]\n[ C0] ---[ end trace 0000000000000000 ]---\n\nThe root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect\nacpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause\na thread switch. Since there is no longer concurrent execution during\nloongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()\ndirectly in enable_gpe_wakeup().\n\nThe solution is similar to commit 22db06337f590d01 (\u0026quot;ACPI: sleep: Avoid\nbreaking S3 wakeup due to might_sleep()\u0026quot;).(CVE-2025-21803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n  $ cat /proc/iomem\n  30000000-37ffffff :\n  38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n  $ cat /proc/iomem\n  30000000-37ffffff : memory2\n  38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n  sysctl -w net.core.dev_weight=0\n  ping 127.0.0.1\n\nThis is because when the napi\u0026apos;s weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi\u0026apos;s weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: xdp: Disallow attaching device-bound programs in generic mode\n\nDevice-bound programs are used to support RX metadata kfuncs. These\nkfuncs are driver-specific and rely on the driver context to read the\nmetadata. This means they can\u0026apos;t work in generic XDP mode. However, there\nis no check to disallow such programs from being attached in generic\nmode, in which case the metadata kfuncs will be called in an invalid\ncontext, leading to crashes.\n\nFix this by adding a check to disallow attaching device-bound programs\nin generic mode.(CVE-2025-21808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: class: Fix wild pointer dereferences in API class_dev_iter_next()\n\nThere are a potential wild pointer dereferences issue regarding APIs\nclass_dev_iter_(init|next|exit)(), as explained by below typical usage:\n\n// All members of @iter are wild pointers.\nstruct class_dev_iter iter;\n\n// class_dev_iter_init(@iter, @class, ...) checks parameter @class for\n// potential class_to_subsys() error, and it returns void type and does\n// not initialize its output parameter @iter, so caller can not detect\n// the error and continues to invoke class_dev_iter_next(@iter) even if\n// @iter still contains wild pointers.\nclass_dev_iter_init(\u0026amp;iter, ...);\n\n// Dereference these wild pointers in @iter here once suffer the error.\nwhile (dev = class_dev_iter_next(\u0026amp;iter)) { ... };\n\n// Also dereference these wild pointers here.\nclass_dev_iter_exit(\u0026amp;iter);\n\nActually, all callers of these APIs have such usage pattern in kernel tree.\nFix by:\n- Initialize output parameter @iter by memset() in class_dev_iter_init()\n  and give callers prompt by pr_crit() for the error.\n- Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: protect access to buffers with no active references\n\nnilfs_lookup_dirty_data_buffers(), which iterates through the buffers\nattached to dirty data folios/pages, accesses the attached buffers without\nlocking the folios/pages.\n\nFor data cache, nilfs_clear_folio_dirty() may be called asynchronously\nwhen the file system degenerates to read only, so\nnilfs_lookup_dirty_data_buffers() still has the potential to cause use\nafter free issues when buffers lose the protection of their dirty state\nmidway due to this asynchronous clearing and are unintentionally freed by\ntry_to_free_buffers().\n\nEliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: rcu protect dev-\u0026gt;ax25_ptr\n\nsyzbot found a lockdep issue [1].\n\nWe should remove ax25 RTNL dependency in ax25_setsockopt()\n\nThis should also fix a variety of possible UAF in ax25.\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted\n------------------------------------------------------\nsyz.5.1818/12806 is trying to acquire lock:\n ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n\nbut task is already holding lock:\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n        lock_sock_nested+0x48/0x100 net/core/sock.c:3642\n        lock_sock include/net/sock.h:1618 [inline]\n        ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]\n        ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146\n        notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85\n       __dev_notify_flags+0x207/0x400\n        dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026\n        dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563\n        dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820\n        sock_do_ioctl+0x240/0x460 net/socket.c:1234\n        sock_ioctl+0x626/0x8e0 net/socket.c:1339\n        vfs_ioctl fs/ioctl.c:51 [inline]\n        __do_sys_ioctl fs/ioctl.c:906 [inline]\n        __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-\u0026gt; #0 (rtnl_mutex){+.+.}-{4:4}:\n        check_prev_add kernel/locking/lockdep.c:3161 [inline]\n        check_prevs_add kernel/locking/lockdep.c:3280 [inline]\n        validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904\n        __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n        __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n        __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735\n        ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n        do_sock_setsockopt+0x3af/0x720 net/socket.c:2324\n        __sys_setsockopt net/socket.c:2349 [inline]\n        __do_sys_setsockopt net/socket.c:2355 [inline]\n        __se_sys_setsockopt net/socket.c:2352 [inline]\n        __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(sk_lock-AF_AX25);\n                               lock(rtnl_mutex);\n                               lock(sk_lock-AF_AX25);\n  lock(rtnl_mutex);\n\n *** DEADLOCK ***\n\n1 lock held by syz.5.1818/12806:\n  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074\n  check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206\n  check_prev_add kernel/locking/lockdep.c:3161 [inline]\n  check_prevs_add kernel/lockin\n---truncated---(CVE-2025-21812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don\u0026apos;t flush non-uploaded STAs\n\nIf STA state is pre-moved to AUTHORIZED (such as in IBSS\nscenarios) and insertion fails, the station is freed.\nIn this case, the driver never knew about the station,\nso trying to flush it is unexpected and may crash.\n\nCheck if the sta was uploaded to the driver before and\nfix this.(CVE-2025-21828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: avoid holding freeze_mutex during mmap operation\n\nWe use map-\u0026gt;freeze_mutex to prevent races between map_freeze() and\nmemory mapping BPF map contents with writable permissions. The way we\nnaively do this means we\u0026apos;ll hold freeze_mutex for entire duration of all\nthe mm and VMA manipulations, which is completely unnecessary. This can\npotentially also lead to deadlocks, as reported by syzbot in [0].\n\nSo, instead, hold freeze_mutex only during writeability checks, bump\n(proactively) \u0026quot;write active\u0026quot; count for the map, unlock the mutex and\nproceed with mmap logic. And only if something went wrong during mmap\nlogic, then undo that \u0026quot;write active\u0026quot; counter increment.\n\n  [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-84.0.0.89.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","perf-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-84.0.0.89.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","perf-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1340"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56648"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56670"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57986"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57997"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57998"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58056"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58068"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58071"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21687"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21707"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21708"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21710"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21711"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21715"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21716"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21720"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21724"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21728"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21745"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21799"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21803"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21806"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21808"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21810"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21811"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21812"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21853"}],"database_specific":{"severity":"High"}}