Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-22065 State: PUBLISHED Published: 2025-04-16T14:12:19.492Z Last Updated: 2025-10-01T17:40:36.862Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: idpf: fix adapter NULL pointer dereference on reboot With SRIOV enabled, idpf ends up calling into idpf_remove() twice. First via idpf_shutdown() and then again when idpf_remove() calls into sriov_disable(), because the VF devices use the idpf driver, hence the same remove routine. When that happens, it is possible for the adapter to be NULL from the first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net/<netif>/device/sriov_numvfs
first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net/<netif>/device/sriov_numvfs reboot BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() c
utdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() call in idpf_shutdown() with idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform the bulk of the cleanup, such as stopping the init task, freeing IRQs, destroying the vports and freeing the mailbox. This avoids the calls to sriov_disable() in addition to a small netdev cleanup, and destroying workqueues, which don't seem to be required on shutdown. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/79618e952ef4dfa1a17ee0631d5549603fab58d8 - https://git.kernel.org/stable/c/88a6d562e92a295648f8636acf2a6aa714241771 - htt
9618e952ef4dfa1a17ee0631d5549603fab58d8 - https://git.kernel.org/stable/c/88a6d562e92a295648f8636acf2a6aa714241771 - https://git.kernel.org/stable/c/9fc9b3dc0d0c189ed205acf1e5fbd73e0becc4d6 - https://git.kernel.org/stable/c/4c9106f4906a85f6b13542d862e423bcdc118cc3
CVE ID: CVE-2025-22066 State: PUBLISHED Published: 2025-04-16T14:12:20.125Z Last Updated: 2025-11-03T19:41:49.509Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-card: Add NULL check in imx_card_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f - https://git.kernel.org/stable/c/3
ferences: - https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f - https://git.kernel.org/stable/c/38253922a89a742e7e622f626b41c64388367361 - https://git.kernel.org/stable/c/e283a5bf4337a7300ac5e6ae363cc8b242a0b4b7 - https://git.kernel.org/stable/c/4d8458e48ff135bddc402ad79821dc058ea163d0 - https://git.kernel.org/stable/c/b01700e08be99e3842570142ec5973ccd7e73eaf - https://git.kernel.org/stable/c/dd2bbb9564d0d24a2643ad90008a79840368c4b4 - https://git.kernel.org/stable/c/93d34608fd162f725172e780b1c60cc93a920719
CVE ID: CVE-2025-22067 State: PUBLISHED Published: 2025-04-16T14:12:20.795Z Last Updated: 2025-10-01T20:16:45.979Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock() If requested_clk > 128, cdns_mrvl_xspi_setup_clock() iterates over the entire cdns_mrvl_xspi_clk_div_list array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, clamping the clock to the minimum 6.25 MHz. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock:
um 6.25 MHz. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e50781bf7accc75883cb8a6a9921fb4e2fa8cca4 - https://git.kernel.org/stable/c/c1fb84e274cb6a2bce6ba5e65116c06e0b3ab275 - https://git.kernel.org/stable/c/645f1813fe0dc96381c36b834131e643b798fd73 - https://git.kernel.org/stable/c/7ba0847fa1c22e7801cebfe5f7b75aee4fae317e
CVE ID: CVE-2025-22068 State: PUBLISHED Published: 2025-04-16T14:12:21.436Z Last Updated: 2025-10-01T16:16:13.925Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ublk: make sure ubq->canceling is set when queue is frozen Now ublk driver depends on `ubq->canceling` for deciding if the request can be dispatched via uring_cmd & io_uring_cmd_complete_in_task(). Once ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd() and io_uring_cmd_done(). So set ubq->canceling when queue is frozen, this way makes sure that the flag can be observed from ublk_queue_rq() reliably, and avoids use-after-free on uring_cmd. Additiona
akes sure that the flag can be observed from ublk_queue_rq() reliably, and avoids use-after-free on uring_cmd. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7e3497d7dacb5aee69dd9be842b778083cae0e75 - https://git.kernel.org/stable/c/5491400589e7572c2d2627ed6384302f7672aa1d - https://git.kernel.org/stable/c/9158359015f0eda00e521e35b7bc7ebce176aebf - https://git.kernel.org/stable/c/8741d0737921ec1c03cf59aebf4d01400c2b461a
CVE ID: CVE-2025-22069 State: PUBLISHED Published: 2025-04-16T14:12:22.357Z Last Updated: 2025-05-26T05:17:47.622Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler Naresh Kamboju reported a "Bad frame pointer" kernel warning while running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the same issue with the following command: ``` $ cd /sys/kernel/debug/tracing $ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` And we can get the follow
$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` And we can get the following kernel warning: [ 127.692888] ------------[ cut here ]------------ [ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000 [ 127.693755] from func do_nanosleep return to ffffffff800ccb16 [ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be [ 127.699894] Modules linked in: [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32 [ 127.701453] Hardware name: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftr
3] Hardware name: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10 [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000 [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80 [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20 [ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000 [ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff
0000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0 [ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068 [ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001 [ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e [ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18 [ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 127.703292] [<ffffffff8013b5e0>] ftrace_return_to_handler+0x1b2/0x1be [ 127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26 [ 127.704009] [<ffffffff80017bb8>] return_t
r+0x1b2/0x1be [ 127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26 [ 127.704009] [<ffffffff80017bb8>] return_to_handler+0x0/0x26 [ 127.704057] [<ffffffff800d3352>] common_nsleep+0x42/0x54 [ 127.704117] [<ffffffff800d44a2>] __riscv_sys_clock_nanosleep+0xba/0x10a [ 127.704176] [<ffffffff80901c56>] do_trap_ecall_u+0x188/0x218 [ 127.704295] [<ffffffff8090cc3e>] handle_exception+0x14a/0x156 [ 127.705436] ---[ end trace 0000000000000000 ]--- The reason is that the stack layout for constructing argument for the ftrace_return_to_handler in the return_to_handler does not match the __arch_ftrace_regs structure of riscv, leading to unexpected results. References: - https://git.kernel.org/stab
atch the __arch_ftrace_regs structure of riscv, leading to unexpected results. References: - https://git.kernel.org/stable/c/78b39c587b8f6c69140177108f9c08a75b1c7c37 - https://git.kernel.org/stable/c/67a5ba8f742f247bc83e46dd2313c142b1383276
CVE ID: CVE-2025-22070 State: PUBLISHED Published: 2025-04-16T14:12:23.295Z Last Updated: 2025-10-01T16:16:00.918Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/9p: fix NULL pointer dereference on mkdir When a 9p tree was mounted with option 'posixacl', parent directory had a default ACL set for its subdirectories, e.g.: setfacl -m default:group:simpsons:rwx parentdir then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer: [ 3
LL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer: [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 37.322338] Call Trace: [ 37.323043] <TASK> [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) [ 37.3301
42] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x
7.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by simply swapping the sequence of these two calls in v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before v9fs_fid_add(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8522051c58d68146b93e8a5ba9987e83b3d64e7b - https://git.kernel.org/stable/c/2139dea5c53e3bb63ac49a6901c85e525a80ee8a - https://git.kernel.org/stable/c/6517b395cb1e43fbf3962dd93e6fb4a5e5ab100e - https://git.kernel.or
49a6901c85e525a80ee8a - https://git.kernel.org/stable/c/6517b395cb1e43fbf3962dd93e6fb4a5e5ab100e - https://git.kernel.org/stable/c/3f61ac7c65bdb26accb52f9db66313597e759821
CVE ID: CVE-2025-22071 State: PUBLISHED Published: 2025-04-16T14:12:23.933Z Last Updated: 2025-11-03T19:41:50.908Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak in spufs_create_context() Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/829bd6139968e2e759f3928cf65ad0db1e302fe3 - https://git.kernel.org/stable/c/410c787d89c92df4215d7b1a338e2c1a8aba6b9b - https://git.kernel.org/stable/c/c4e72a0d75442237b6f3bcca10a7d81b89376d1
ble/c/410c787d89c92df4215d7b1a338e2c1a8aba6b9b - https://git.kernel.org/stable/c/c4e72a0d75442237b6f3bcca10a7d81b89376d16 - https://git.kernel.org/stable/c/a333f223e555d27609f8b45d75a08e8e1d36c432 - https://git.kernel.org/stable/c/239ea3c34673b3244a499fd65771c47e5bffcbb0 - https://git.kernel.org/stable/c/d04600f43569d48262e1328eaa1592fcefa2c19c - https://git.kernel.org/stable/c/5a90b699844a5bb96961e5892e51cc59255444a3 - https://git.kernel.org/stable/c/4a7448c83e117ed68597952ecaede1cebc4427a7 - https://git.kernel.org/stable/c/0f5cce3fc55b08ee4da3372baccf4bcd36a98396
CVE ID: CVE-2025-22072 State: PUBLISHED Published: 2025-04-16T14:12:24.571Z Last Updated: 2025-11-03T19:41:52.282Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spufs: fix gang directory lifetimes prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer
led and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed. Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not
e, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/880e7b3da2e765c1f90c94c0539be039e96c7062 - https://git.kernel.org/stable/c/324f280806aab28ef757aecc18df419676c10ef8 - https://git.kernel.org/stable/c/029d8c711f5e5fe8cf63e8a4a1a140a06e224e45 - https://git.kernel.org/stable/c/903733782f3ae28a2f7fe4dfb47c7fe3e079a528 - https://git.kernel.org/stable/c/fc646a6c6d14b5d581f162a7e32999f789e3a3ac - https://git.kernel.org/stable/c/c134deabf47
- https://git.kernel.org/stable/c/fc646a6c6d14b5d581f162a7e32999f789e3a3ac - https://git.kernel.org/stable/c/c134deabf4784e155d360744d4a6a835b9de4dd4
CVE ID: CVE-2025-22073 State: PUBLISHED Published: 2025-04-16T14:12:25.308Z Last Updated: 2025-11-03T19:41:53.661Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak on spufs_new_file() failure It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b1eef06d10c1a9848e3a762919bbbe315a0a7cb4 - https://git.kernel.org/stable/c/132925bd6772d7614340fb
it.kernel.org/stable/c/b1eef06d10c1a9848e3a762919bbbe315a0a7cb4 - https://git.kernel.org/stable/c/132925bd6772d7614340fb755ac5415462ac8edd - https://git.kernel.org/stable/c/53b189651c33b5f1fb3b755e6a37a8206978514e - https://git.kernel.org/stable/c/96de7fbdc2dcadeebc17c3cb89e7cdab487bfce0 - https://git.kernel.org/stable/c/90d1b276d1b1379d20ad27d1f6349ba9f44a2e00 - https://git.kernel.org/stable/c/35f789ccebd69f6f9a1e0a9b85435003b2450065 - https://git.kernel.org/stable/c/d791985ceeb081155b4e96d314ca54c7605dcbe0 - https://git.kernel.org/stable/c/0bd56e4e72c354b65c0a7e5ac1c09eca81949d5b - https://git.kernel.org/stable/c/d1ca8698ca1332625d83ea0d753747be66f9906d
CVE ID: CVE-2025-22074 State: PUBLISHED Published: 2025-04-16T14:12:25.921Z Last Updated: 2025-05-26T05:17:54.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix r_count dec/increment mismatch r_count is only increased when there is an oplock break wait, so r_count inc/decrement are not paired. This can cause r_count to become negative, which can lead to a problem where the ksmbd thread does not terminate. References: - https://git.kernel.org/stable/c/4790bcb269e5d6d88200a67c54ae6d627332a3be - https://git.kernel.org/stable/c/457db486203c90e10c3efc87fd45cc7000b1cd36 - https://git.kernel.org/stable/c/20378cf48359f39dee
://git.kernel.org/stable/c/457db486203c90e10c3efc87fd45cc7000b1cd36 - https://git.kernel.org/stable/c/20378cf48359f39dee0ef9b61470ebe77bd49c0d - https://git.kernel.org/stable/c/c2ec33d46b4d1c8085dab5d02e00b21f4f0fb8a9 - https://git.kernel.org/stable/c/ddb7ea36ba7129c2ed107e2186591128618864e1
CVE ID: CVE-2025-22075 State: PUBLISHED Published: 2025-04-16T14:12:26.566Z Last Updated: 2025-11-03T19:41:56.461Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Allocate vfinfo size for VF GUIDs when supported Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link s
age is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long Kernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + I
fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: fff
0 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50
__warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_w
rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0
9/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0f5489707cf528f9df2f39a3045c1ee713ec90e7 - https://git.kernel.org/stable
: References: - https://git.kernel.org/stable/c/0f5489707cf528f9df2f39a3045c1ee713ec90e7 - https://git.kernel.org/stable/c/bb7bdf636cef74cdd7a7d548bdc7457ae161f617 - https://git.kernel.org/stable/c/5fed5f6de3cf734b231a11775748a6871ee3020f - https://git.kernel.org/stable/c/15f150771e0ec97f8ab1657e7d2568e593c7fa04 - https://git.kernel.org/stable/c/28b21ee8e8fb326ba961a4bbce04ec04c65e705a - https://git.kernel.org/stable/c/365c1ae819455561d4746aafabad673e4bcb0163 - https://git.kernel.org/stable/c/5f39454468329bb7fc7fc4895a6ba6ae3b95027e - https://git.kernel.org/stable/c/23f00807619d15063d676218f36c5dfeda1eb420