Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-53420 State: PUBLISHED Published: 2025-09-18T16:04:03.754Z Last Updated: 2025-09-18T16:04:03.754Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr() Here is a BUG report from syzbot: BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632 Call Trace: ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 vfs_listxattr fs/xattr.c:457 [inline] li
a fs/ntfs3/xattr.c:191 [inline] ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 vfs_listxattr fs/xattr.c:457 [inline] listxattr+0x293/0x2d0 fs/xattr.c:804 Fix the logic of ea_all iteration. When the ea->name_len is 0, return immediately, or Add2Ptr() would visit invalid memory in the next loop. [almaz.alexandrovich@paragon-software.com: lines of the patch have changed] References: - https://git.kernel.org/stable/c/f3380d895e28a32632eb3609f5bd515adee4e5a1 - https://git.kernel.org/stable/c/c86a2517df6c9304db8fb12b77136ec7a5d85994 - https://git.kernel.org/stable/c/721b75ea2dfce53a8890dff92ae01afca8e74f88 - https://git.kernel.org/stable/c/3c675ddffb17a8b1e32efad5c983254af18b12c2
CVE ID: CVE-2023-53421 State: PUBLISHED Published: 2025-09-18T16:04:04.526Z Last Updated: 2025-09-18T16:04:04.526Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") while the later one was introduced by commit f73316482977 ("blk-cgroup: reimplement basic IO stats using cg
at_flush()") while the later one was introduced by commit f73316482977 ("blk-cgroup: reimplement basic IO stats using cgroup rstat"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing. References: - https://git.kernel.org/stable/c/b0d26283af612b9e0cc3188b0b88ad7fdea447e8 - https://git.kernel.org/stable/c/abbce7f82613ea5eeefd0fc3c1c8e44
.org/stable/c/b0d26283af612b9e0cc3188b0b88ad7fdea447e8 - https://git.kernel.org/stable/c/abbce7f82613ea5eeefd0fc3c1c8e449b9cef2a2 - https://git.kernel.org/stable/c/3d2af77e31ade05ff7ccc3658c3635ec1bea0979
CVE ID: CVE-2023-53422 State: PUBLISHED Published: 2025-09-18T16:04:05.224Z Last Updated: 2025-09-18T16:04:05.224Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fw: fix memory leak in debugfs Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object. References: - https://git.kernel.org/stable/c/89496d6cff297c88fe0286a440c380ceb172da2b - https://git.kernel.org/stable/c/e302e9ca14a86a80eadfb24a34d8675aadaf3ef3 - https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4 - https://git.kernel.org/sta
34d8675aadaf3ef3 - https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4 - https://git.kernel.org/stable/c/fe17124282da055cb2e53f0131521459b5c7866c - https://git.kernel.org/stable/c/b830ba20b43be52eae7d4087b61a0079dec56820 - https://git.kernel.org/stable/c/3d90d2f4a018fe8cfd65068bc6350b6222be4852
CVE ID: CVE-2023-53423 State: PUBLISHED Published: 2025-09-18T16:04:05.957Z Last Updated: 2025-09-18T16:04:05.957Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: objtool: Fix memory leak in create_static_call_sections() strdup() allocates memory for key_name. We need to release the memory in the following error paths. Add free() to avoid memory leak. References: - https://git.kernel.org/stable/c/a1368eaea058e451d20ea99ca27e72d9df0d16dd - https://git.kernel.org/stable/c/3a75866a5ceff5d4fdd5471e06c4c4d03e0298b3 - https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5 - https://git.kernel.org/stable/c/d131718d9c4
- https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5 - https://git.kernel.org/stable/c/d131718d9c45d559951f57c4b88209ca407433c4 - https://git.kernel.org/stable/c/3da73f102309fe29150e5c35acd20dd82063ff67
CVE ID: CVE-2023-53424 State: PUBLISHED Published: 2025-09-18T16:04:06.635Z Last Updated: 2025-09-18T16:04:06.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: fix of_iomap memory leak Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn: 'base' from of_iomap() not released on lines: 496. This problem was also found in linux-next. In mtk_clk_simple_probe(), base is not released when handling errors if clk_data is not existed, which may cause a leak. So free_base should be added here to release base. References: - https://git.kernel.org/stable/c/2cae6a28d8c12c597e8656962271520434c61c48
d be added here to release base. References: - https://git.kernel.org/stable/c/2cae6a28d8c12c597e8656962271520434c61c48 - https://git.kernel.org/stable/c/47234e19b00816a8a7b278c7173f6d4e928c43c7 - https://git.kernel.org/stable/c/3db7285e044144fd88a356f5b641b9cd4b231a77
CVE ID: CVE-2023-53425 State: PUBLISHED Published: 2025-09-18T16:04:07.335Z Last Updated: 2025-09-18T16:04:07.335Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: platform: mediatek: vpu: fix NULL ptr dereference If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev' References: - https://git.kernel.org/stable/c/099e929e7477f37ca16738fc158d7101c0189ca1 - https://git.kernel.org/stable/c/1b3f25d3894a091abc247eadab266a2c9be64389 - https://git.kernel.org/stable/c/c1c5826223ae05a48d21f6708c6f34ee9
rg/stable/c/1b3f25d3894a091abc247eadab266a2c9be64389 - https://git.kernel.org/stable/c/c1c5826223ae05a48d21f6708c6f34ee9006238c - https://git.kernel.org/stable/c/2caeb722f0ea5d2d24af30bb1753a89d449b6aa0 - https://git.kernel.org/stable/c/776b34615a29551d69d82a0082e7319d5ea284bd - https://git.kernel.org/stable/c/b7bd48f0be84e24d21aa3a8f59a8a9cb8633a1c4 - https://git.kernel.org/stable/c/4d299e6e0ac3cf8ab4517dc29c9294bc4bf72398 - https://git.kernel.org/stable/c/3df55cd773e8603b623425cc97b05e542854ad27
CVE ID: CVE-2023-53426 State: PUBLISHED Published: 2025-09-18T16:04:08.192Z Last Updated: 2025-09-18T16:04:08.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: Fix xsk_diag use-after-free error during socket cleanup Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was intr
evice was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND. The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the sta
e old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic's netlink operation. References: - https://git.kernel.org/stable/c/5979985f2d6b565b6cf0f79a62670a2855c0e96c - https://git.kernel.org/stable/c/6436973164ea5506a495f39e56be5aea375e7832 - https://git.kernel.org/stable/c/595931912357fa3507e522a7f8a0a76e423c23e4 - https://git.kernel.org/stable/c/3e019d8a05a38abb5c85d4f1e85fda964610aa14
CVE ID: CVE-2023-53427 State: PUBLISHED Published: 2025-09-18T16:04:08.917Z Last Updated: 2025-09-18T16:04:08.917Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: Fix warning and UAF when destroy the MR list If the MR allocate failed, the MR recovery work not initialized and list not cleared. Then will be warning and UAF when release the MR: WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110 CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82 RIP: 0010:__flush_work.isra.0+0xf7/0x110 Call Trace: <TASK> __cancel_work_timer+0x2ba/0x2e0 smbd_destroy+0x4e1/0x990 _smbd_get_connection+0x1cb
isra.0+0xf7/0x110 Call Trace: <TASK> __cancel_work_timer+0x2ba/0x2e0 smbd_destroy+0x4e1/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990 Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824 CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82 Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x1
unt.cifs Tainted: G W 6.1.0-rc5+ #82 Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 smbd_destroy+0x4fc/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Allocated by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7a/0x90 _smbd_get_connection+0x1b6f/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_ge
loc+0x7a/0x90 _smbd_get_connection+0x1b6f/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 __kmem_cache_free+0xc8/0x330 _smbd_get_connection+0x1c6a/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0
1/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Let's initialize the MR recovery work before MR allocate to prevent the warning, remove the MRs from the list to prevent the UAF. References: - https://git.kernel.org/stable/c/275a3d2b9408fc4895e342f772cab9a89960546e - https://git.kernel.org/stable/c/3524d6da0fe88aee79f06be6572955d16ad76b39 - https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834 - https://git.kernel.org/stable/c/7cbd5bdb5bd44
https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834 - https://git.kernel.org/stable/c/7cbd5bdb5bd4404a5da4309521134b42c65846c0 - https://git.kernel.org/stable/c/41832c62a75dad530dc5a2856c92ae5459d497e5 - https://git.kernel.org/stable/c/2d0c4f5f618f58eba03385363717703bee873c64 - https://git.kernel.org/stable/c/3e161c2791f8e661eed24a2c624087084d910215
CVE ID: CVE-2023-53428 State: PUBLISHED Published: 2025-09-18T16:04:09.580Z Last Updated: 2025-09-18T16:04:09.580Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powercap: arm_scmi: Remove recursion while parsing zones Powercap zones can be defined as arranged in a hierarchy of trees and when registering a zone with powercap_register_zone(), the kernel powercap subsystem expects this to happen starting from the root zones down to the leaves; on the other side, de-registration by powercap_deregister_zone() must begin from the leaf zones. Available SCMI powercap zones are retrieved dynamically from the platform at probe time and,
begin from the leaf zones. Available SCMI powercap zones are retrieved dynamically from the platform at probe time and, while any defined hierarchy between the zones is described properly in the zones descriptor, the platform returns the availables zones with no particular well-defined order: as a consequence, the trees possibly composing the hierarchy of zones have to be somehow walked properly to register the retrieved zones from the root. Currently the ARM SCMI Powercap driver walks the zones using a recursive algorithm; this approach, even though correct and tested can lead to kernel stack overflow when processing a returned hierarchy of zones composed by particularly high trees. Avoid
lead to kernel stack overflow when processing a returned hierarchy of zones composed by particularly high trees. Avoid possible kernel stack overflow by substituting the recursive approach with an iterative one supported by a dynamically allocated stack-like data structure. References: - https://git.kernel.org/stable/c/b427c23cebc5c926516f20304bf1acc05a33d147 - https://git.kernel.org/stable/c/8022b64fb7daa6135d9f7b0e2f7b5b8e9e5179c9 - https://git.kernel.org/stable/c/3e767d6850f867cc33ac16ca097350a1d2417982
CVE ID: CVE-2023-53429 State: PUBLISHED Published: 2025-09-18T16:04:10.298Z Last Updated: 2025-09-18T16:04:10.298Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: don't check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and
ror handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context. References: - https://git.kernel.org/stable/c/d40be032ecd8ee1ca033bee43c7755d21fb4d72a - https://git.kernel.org/stable/c/3e92499e3b004baffb479d61e191b41b604ece9a
CVE ID: CVE-2023-53430 State: PUBLISHED Published: 2025-09-18T16:04:11.035Z Last Updated: 2025-09-18T16:04:11.035Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: dma: fix memory leak running mt76_dma_tx_cleanup Fix device unregister memory leak and alway cleanup all configured rx queues in mt76_dma_tx_cleanup routine. References: - https://git.kernel.org/stable/c/604990fee0a6d608a6cca179ae474f2a1c6add8a - https://git.kernel.org/stable/c/3f7dda36e0b6dfa2cd26191f754ba061ab8191f2
CVE ID: CVE-2023-53431 State: PUBLISHED Published: 2025-09-18T16:04:11.748Z Last Updated: 2025-10-02T07:04:20.059Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Handle enclosure with just a primary component gracefully This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <dinghui@sangfor.com.cn>. Completely ignoring devices that have one primary enclosure and no secondary one result
ng Hui <dinghui@sangfor.com.cn>. Completely ignoring devices that have one primary enclosure and no secondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such even on valid configurations with 1 primary and 0 secondary enclosures as below: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor l
SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1 The changelog for the original fix follows ===== We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [
l trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, com
[ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process ===== References: - https://git.kernel.org/stable/c/4e7c498c3713b09bef20c76c7319555637
ray in ses_enclosure_data_process ===== References: - https://git.kernel.org/stable/c/4e7c498c3713b09bef20c76c7319555637e8bbd5 - https://git.kernel.org/stable/c/110d425cdfb15006f3c4fde5264e786a247b6b36 - https://git.kernel.org/stable/c/176d7345b89ced72020a313bfa4e7f345d1c3aed - https://git.kernel.org/stable/c/05143d90ac90b7abc6692285895a1ef460e008ee - https://git.kernel.org/stable/c/f8e702c54413eee2d8f94f61d18adadac7c87e87 - https://git.kernel.org/stable/c/eabc4872f172ecb8dd8536bc366a51868154a450 - https://git.kernel.org/stable/c/c8e22b7a1694bb8d025ea636816472739d859145
CVE ID: CVE-2023-53432 State: PUBLISHED Published: 2025-09-18T16:04:12.446Z Last Updated: 2025-09-18T16:04:12.446Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firewire: net: fix use after free in fwnet_finish_incoming_packet() The netif_rx() function frees the skb so we can't dereference it to save the skb->len. References: - https://git.kernel.org/stable/c/2ea70379e4f4efa95c9daa7f3f9bdd4d40aec927 - https://git.kernel.org/stable/c/9040adc38cf6bfbb77034d558ac2c52f70d840ac - https://git.kernel.org/stable/c/9860921ab4521252dc39bb21b9c936bd09a00982 - https://git.kernel.org/stable/c/3ff256751a2853e1ffaa36958ff933ccc98c6cb5
CVE ID: CVE-2023-53433 State: PUBLISHED Published: 2025-09-18T16:04:13.126Z Last Updated: 2025-09-18T16:04:13.126Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: add vlan_get_protocol_and_depth() helper Before blamed commit, pskb_may_pull() was used instead of skb_header_pointer() in __vlan_get_protocol() and friends. Few callers depended on skb->head being populated with MAC header, syzbot caught one of them (skb_mac_gso_segment()) Add vlan_get_protocol_and_depth() to make the intent clearer and use it where sensible. This is a more generic fix than commit e9d3f80935b6 ("net/af_packet: make sure to pull mac header") which
here sensible. This is a more generic fix than commit e9d3f80935b6 ("net/af_packet: make sure to pull mac header") which was dealing with a similar issue. kernel BUG at include/linux/skbuff.h:2655 ! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline] RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136 Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286 RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9 R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012 R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7 FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0
0000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> [<ffffffff847018dd>] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419 [<ffffffff8470398a>] skb_gso_segment include/linux/netdevice.h:4819 [inline] [<ffffffff8470398a>] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725 [<ffffffff84707042>] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313 [<ffffffff851a9ec7>] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029 [<ffffffff851b4a82>] packet_snd net/packet/af_packet.c:3111 [