{"schema_version":"1.7.2","id":"OESA-2025-1432","modified":"2025-04-18T13:49:49Z","published":"2025-04-18T13:49:49Z","upstream":["CVE-2021-47407","CVE-2022-49280","CVE-2022-49307","CVE-2022-49399","CVE-2022-49525","CVE-2022-49674","CVE-2022-49740","CVE-2023-52973","CVE-2024-40998","CVE-2024-58002","CVE-2025-21796","CVE-2025-21858"],"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\nKVM: x86: Handle SRCU initialization failure during page track init\n\nCheck the return of init_srcu_struct(), which can fail due to OOM, when\ninitializing the page track mechanism.  Lack of checking leads to a NULL\npointer deref found by a modified syzkaller.\n\n[Move the call towards the beginning of kvm_arch_init_vm. - Paolo](CVE-2021-47407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: prevent underflow in nfssvc_decode_writeargs()\n\nSmatch complains:\n\n\tfs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()\n\twarn: no lower bound on \u0026apos;args-\u0026gt;len\u0026apos;\n\nChange the type to unsigned to prevent this issue.(CVE-2022-49280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: synclink_gt: Fix null-pointer-dereference in slgt_clean()\n\nWhen the driver fails at alloc_hdlcdev(), and then we remove the driver\nmodule, we will get the following splat:\n\n[   25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI\n[   25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]\n[   25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0\n[   25.077709] Call Trace:\n[   25.077924]  \u0026lt;TASK\u0026gt;\n[   25.078108]  unregister_hdlc_device+0x16/0x30\n[   25.078481]  slgt_cleanup+0x157/0x9f0 [synclink_gt]\n\nFix this by checking whether the \u0026apos;info-\u0026gt;netdev\u0026apos; is a null pointer first.(CVE-2022-49307)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: goldfish: Use tty_port_destroy() to destroy port\n\nIn goldfish_tty_probe(), the port initialized through tty_port_init()\nshould be destroyed in error paths.In goldfish_tty_remove(), qtty-\u0026gt;port\nalso should be destroyed or else might leak resources.\n\nFix the above by calling tty_port_destroy().(CVE-2022-49399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx25821: Fix the warning when removing the module\n\nWhen removing the module, we will get the following warning:\n\n[   14.746697] remove_proc_entry: removing non-empty directory \u0026apos;irq/21\u0026apos;, leaking at least \u0026apos;cx25821[1]\u0026apos;\n[   14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0\n[   14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0\n[   14.759589] Call Trace:\n[   14.759792]  \u0026lt;TASK\u0026gt;\n[   14.759975]  unregister_irq_proc+0x14c/0x170\n[   14.760340]  irq_free_descs+0x94/0xe0\n[   14.760640]  mp_unmap_irq+0xb6/0x100\n[   14.760937]  acpi_unregister_gsi_ioapic+0x27/0x40\n[   14.761334]  acpi_pci_irq_disable+0x1d3/0x320\n[   14.761688]  pci_disable_device+0x1ad/0x380\n[   14.762027]  ? _raw_spin_unlock_irqrestore+0x2d/0x60\n[   14.762442]  ? cx25821_shutdown+0x20/0x9f0 [cx25821]\n[   14.762848]  cx25821_finidev+0x48/0xc0 [cx25821]\n[   14.763242]  pci_device_remove+0x92/0x240\n\nFix this by freeing the irq before call pci_disable_device().(CVE-2022-49525)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm raid: fix accesses beyond end of raid member array\n\nOn dm-raid table load (using raid_ctr), dm-raid allocates an array\nrs-\u0026gt;devs[rs-\u0026gt;raid_disks] for the raid device members. rs-\u0026gt;raid_disks\nis defined by the number of raid metadata and image tupples passed\ninto the target\u0026apos;s constructor.\n\nIn the case of RAID layout changes being requested, that number can be\ndifferent from the current number of members for existing raid sets as\ndefined in their superblocks. Example RAID layout changes include:\n- raid1 legs being added/removed\n- raid4/5/6/10 number of stripes changed (stripe reshaping)\n- takeover to higher raid level (e.g. raid5 -\u0026gt; raid6)\n\nWhen accessing array members, rs-\u0026gt;raid_disks must be used in control\nloops instead of the potentially larger value in rs-\u0026gt;md.raid_disks.\nOtherwise it will cause memory access beyond the end of the rs-\u0026gt;devs\narray.\n\nFix this by changing code that is prone to out-of-bounds access.\nAlso fix validate_raid_redundancy() to validate all devices that are\nadded. Also, use braces to help clean up raid_iterate_devices().\n\nThe out-of-bounds memory accesses was discovered using KASAN.\n\nThis commit was verified to pass all LVM2 RAID tests (with KASAN\nenabled).(CVE-2022-49674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads\n\nThis patch fixes slab-out-of-bounds reads in brcmfmac that occur in\nbrcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count\nvalue of channel specifications provided by the device is greater than\nthe length of \u0026apos;list-\u0026gt;element[]\u0026apos;, decided by the size of the \u0026apos;list\u0026apos;\nallocated with kzalloc(). The patch adds checks that make the functions\nfree the buffer and return -EINVAL if that is the case. Note that the\nnegative return is handled by the caller, brcmf_setup_wiphybands() or\nbrcmf_cfg80211_attach().\n\nFound by a modified version of syzkaller.\n\nCrash Report from brcmf_construct_chaninfo():\n==================================================================\nBUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430\nRead of size 4 at addr ffff888115f24600 by task kworker/0:2/1896\n\nCPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G        W  O      5.14.0+ #132\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n dump_stack_lvl+0x57/0x7d\n print_address_description.constprop.0.cold+0x93/0x334\n kasan_report.cold+0x83/0xdf\n brcmf_setup_wiphybands+0x1238/0x1430\n brcmf_cfg80211_attach+0x2118/0x3fd0\n brcmf_attach+0x389/0xd40\n brcmf_usb_probe+0x12de/0x1690\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_set_configuration+0x984/0x1770\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_new_device.cold+0x463/0xf66\n hub_event+0x10d5/0x3330\n process_one_work+0x873/0x13e0\n worker_thread+0x8b/0xd10\n kthread+0x379/0x450\n ret_from_fork+0x1f/0x30\n\nAllocated by task 1896:\n kasan_save_stack+0x1b/0x40\n __kasan_kmalloc+0x7c/0x90\n kmem_cache_alloc_trace+0x19e/0x330\n brcmf_setup_wiphybands+0x290/0x1430\n brcmf_cfg80211_attach+0x2118/0x3fd0\n brcmf_attach+0x389/0xd40\n brcmf_usb_probe+0x12de/0x1690\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_set_configuration+0x984/0x1770\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_new_device.cold+0x463/0xf66\n hub_event+0x10d5/0x3330\n process_one_work+0x873/0x13e0\n worker_thread+0x8b/0xd10\n kthread+0x379/0x450\n ret_from_fork+0x1f/0x30\n\nThe buggy address belongs to the object at ffff888115f24000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1536 bytes inside of\n 2048-byte region [ffff888115f24000, ffff888115f24800)\n\nMemory state around the buggy address:\n ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n\u0026gt;ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                   ^\n ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n==================================================================\n\nCrash Report from brcmf_enable_bw40_2g():\n==========\n---truncated---(CVE-2022-49740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF\n\nAfter a call to console_unlock() in vcs_read() the vc_data struct can be\nfreed by vc_deallocate(). Because of that, the struct vc_data pointer\nload must be done at the top of while loop in vcs_read() to avoid a UAF\nwhen vcs_size() is called.\n\nSyzkaller reported a UAF in vcs_size().\n\nBUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)\nRead of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537\n\nCPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module\nCall Trace:\n  \u0026lt;TASK\u0026gt;\n__asan_report_load4_noabort (mm/kasan/report_generic.c:350)\nvcs_size (drivers/tty/vt/vc_screen.c:215)\nvcs_read (drivers/tty/vt/vc_screen.c:415)\nvfs_read (fs/read_write.c:468 fs/read_write.c:450)\n...\n  \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1191:\n...\nkmalloc_trace (mm/slab_common.c:1069)\nvc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720\n     drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)\ncon_install (drivers/tty/vt/vt.c:3383)\ntty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413\n     drivers/tty/tty_io.c:1390)\ntty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)\nchrdev_open (fs/char_dev.c:415)\ndo_dentry_open (fs/open.c:883)\nvfs_open (fs/open.c:1014)\n...\n\nFreed by task 1548:\n...\nkfree (mm/slab_common.c:1021)\nvc_port_destruct (drivers/tty/vt/vt.c:1094)\ntty_port_destructor (drivers/tty/tty_port.c:296)\ntty_port_put (drivers/tty/tty_port.c:312)\nvt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))\nvt_ioctl (drivers/tty/vt/vt_ioctl.c:903)\ntty_ioctl (drivers/tty/tty_io.c:2776)\n...\n\nThe buggy address belongs to the object at ffff888113747800\n  which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 424 bytes inside of\n  1024-byte region [ffff888113747800, ffff888113747c00)\n\nThe buggy address belongs to the physical page:\npage:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000\n     index:0x0 pfn:0x113740\nhead:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0\n     compound_pincount:0\nanon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)\nraw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001\nraw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n  ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n\u0026gt; ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                   ^\n  ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\nDisabling lock debugging due to kernel taint(CVE-2023-52973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix uninitialized ratelimit_state-\u0026gt;lock access in __ext4_fill_super()\n\nIn the following concurrency we will access the uninitialized rs-\u0026gt;lock:\n\next4_fill_super\n  ext4_register_sysfs\n   // sysfs registered msg_ratelimit_interval_ms\n                             // Other processes modify rs-\u0026gt;interval to\n                             // non-zero via msg_ratelimit_interval_ms\n  ext4_orphan_cleanup\n    ext4_msg(sb, KERN_INFO, \u0026quot;Errors on filesystem, \u0026quot;\n      __ext4_msg\n        ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state)\n          if (!rs-\u0026gt;interval)  // do nothing if interval is 0\n            return 1;\n          raw_spin_trylock_irqsave(\u0026amp;rs-\u0026gt;lock, flags)\n            raw_spin_trylock(lock)\n              _raw_spin_trylock\n                __raw_spin_trylock\n                  spin_acquire(\u0026amp;lock-\u0026gt;dep_map, 0, 1, _RET_IP_)\n                    lock_acquire\n                      __lock_acquire\n                        register_lock_class\n                          assign_lock_key\n                            dump_stack();\n  ratelimit_state_init(\u0026amp;sbi-\u0026gt;s_msg_ratelimit_state, 5 * HZ, 10);\n    raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock);\n    // init rs-\u0026gt;lock here\n\nand get the following dump_stack:\n\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0026apos;t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\n\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u0026gt;lock, so it is possible to change rs-\u0026gt;interval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u0026gt;lock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u0026gt;lock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.(CVE-2024-40998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Remove dangling pointers\n\nWhen an async control is written, we copy a pointer to the file handle\nthat started the operation. That pointer will be used when the device is\ndone. Which could be anytime in the future.\n\nIf the user closes that file descriptor, its structure will be freed,\nand there will be one dangling pointer per pending async control, that\nthe driver will try to use.\n\nClean all the dangling pointers during release().\n\nTo avoid adding a performance penalty in the most common case (no async\noperation), a counter has been introduced with some logic to make sure\nthat it is properly handled.(CVE-2024-58002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clear acl_access/acl_default after releasing them\n\nIf getting acl_default fails, acl_access and acl_default will be released\nsimultaneously. However, acl_access will still retain a pointer pointing\nto the released posix_acl, which will trigger a WARNING in\nnfs3svc_release_getacl like this:\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 26 PID: 3199 at lib/refcount.c:28\nrefcount_warn_saturate+0xb5/0x170\nModules linked in:\nCPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted\n6.12.0-rc6-00079-g04ae226af01f-dirty #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb5/0x170\nCode: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75\ne4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff \u0026lt;0f\u0026gt; 0b eb\ncd 0f b6 1d 8a3\nRSP: 0018:ffffc90008637cd8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380\nRBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56\nR10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0\nFS:  0000000000000000(0000) GS:ffff88871ed00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xb5/0x170\n ? __warn+0xa5/0x140\n ? refcount_warn_saturate+0xb5/0x170\n ? report_bug+0x1b1/0x1e0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? tick_nohz_tick_stopped+0x1e/0x40\n ? refcount_warn_saturate+0xb5/0x170\n ? refcount_warn_saturate+0xb5/0x170\n nfs3svc_release_getacl+0xc9/0xe0\n svc_process_common+0x5db/0xb60\n ? __pfx_svc_process_common+0x10/0x10\n ? __rcu_read_unlock+0x69/0xa0\n ? __pfx_nfsd_dispatch+0x10/0x10\n ? svc_xprt_received+0xa1/0x120\n ? xdr_init_decode+0x11d/0x190\n svc_process+0x2a7/0x330\n svc_handle_xprt+0x69d/0x940\n svc_recv+0x180/0x2d0\n nfsd+0x168/0x200\n ? __pfx_nfsd+0x10/0x10\n kthread+0x1a2/0x1e0\n ? kthread+0xf4/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nClear acl_access/acl_default after posix_acl_release is called to prevent\nUAF from being triggered.(CVE-2025-21796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: Fix use-after-free in geneve_find_dev().\n\nsyzkaller reported a use-after-free in geneve_find_dev() [0]\nwithout repro.\n\ngeneve_configure() links struct geneve_dev.next to\nnet_generic(net, geneve_net_id)-\u0026gt;geneve_list.\n\nThe net here could differ from dev_net(dev) if IFLA_NET_NS_PID,\nIFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.\n\nWhen dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally\ncalls unregister_netdevice_queue() for each dev in the netns,\nand later the dev is freed.\n\nHowever, its geneve_dev.next is still linked to the backend UDP\nsocket netns.\n\nThen, use-after-free will occur when another geneve dev is created\nin the netns.\n\nLet\u0026apos;s call geneve_dellink() instead in geneve_destroy_tunnels().\n\n[0]:\nBUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]\nBUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343\nRead of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441\n\nCPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x16c/0x6f0 mm/kasan/report.c:489\n kasan_report+0xc0/0x120 mm/kasan/report.c:602\n __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379\n geneve_find_dev drivers/net/geneve.c:1295 [inline]\n geneve_configure+0x234/0x858 drivers/net/geneve.c:1343\n geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634\n rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795\n __rtnl_newlink net/core/rtnetlink.c:3906 [inline]\n rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021\n rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911\n netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543\n rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892\n sock_sendmsg_nosec net/socket.c:713 [inline]\n __sock_sendmsg net/socket.c:728 [inline]\n ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568\n ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622\n __sys_sendmsg net/socket.c:2654 [inline]\n __do_sys_sendmsg net/socket.c:2659 [inline]\n __se_sys_sendmsg net/socket.c:2657 [inline]\n __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151\n el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600\n\nAllocated by task 13247:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x30/0x68 mm/kasan/common.c:68\n kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4298 [inline]\n __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304\n __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645\n alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470\n rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604\n rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780\n __rtnl_newlink net/core/rtnetlink.c:3906 [inline]\n rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021\n rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911\n netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543\n rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938\n netlink_unicast_kernel net/netlink/af_n\n---truncated---(CVE-2025-21858)","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.3.0.0324.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","perf-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2504.3.0.0324.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","perf-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2504.3.0.0324.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1432"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49307"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49525"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49674"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40998"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21796"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21858"}],"database_specific":{"severity":"High"}}