Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-57922 State: PUBLISHED Published: 2025-01-19T11:52:41.156Z Last Updated: 2025-11-03T20:55:53.705Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8a9315e6f7b
alyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8a9315e6f7b2d94c65a1ba476481deddb20fc3ae - https://git.kernel.org/stable/c/497471baf53bb8fd3cd1529d65d4d7f7b81f1917 - https://git.kernel.org/stable/c/95793f9684e58d2aa56671b2d616b4f9f577a0a8 - https://git.kernel.org/stable/c/f3d1e4062ef251fa55ccfeca1e54a98b6818b3a1 - https://git.kernel.org/stable/c/ae9ab63a268be99a27a4720ca24f6be801744fee - https://git.kernel.org/stable/c/4f0dd09ed3001725ffd8cdc2868e71df585392fe - https://git.kernel.org/stable/c/0881fbc4fd62e00a2b8e102725f76d10351b2ea8
CVE ID: CVE-2024-57923 State: PUBLISHED Published: 2025-01-19T11:52:41.798Z Last Updated: 2025-05-04T10:06:43.567Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path Since the input data length passed to zlib_compress_folios() can be arbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may cause read-in bytes to exceed the input range. Currently this triggers an assert in btrfs_compress_folios() on the debug kernel (see below). Fix strm.avail_in calculation for S390 hardware acceleration path. assertion failed: *total_in <= orig_len, in fs/btrfs/compres
m.avail_in calculation for S390 hardware acceleration path. assertion failed: *total_in <= orig_len, in fs/btrfs/compression.c:1041 ------------[ cut here ]------------ kernel BUG at fs/btrfs/compression.c:1041! monitor event: 0040 ilc:2 [#1] PREEMPT SMP CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 Not tainted 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1 Hardware name: IBM 3931 A01 703 (z/VM 7.4.0) Workqueue: btrfs-delalloc btrfs_work_helper Krnl PSW : 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 0000000000000006
AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 0000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58 Krnl Code: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8 #0000021761df6534: af000000 mc 0,0 >0000021761df6538: 0707 bcr 0,%r7 0000021761df653a: 0707 bcr 0,%r7 0000021761df653c: 0707 bcr 0,%r7 0000021761df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Call Trace: [<0000021761df6538>] btrfs_com
df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Call Trace: [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0 ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0) [<0000021761d97788>] compress_file_range+0x3b8/0x6d0 [<0000021761dcee7c>] btrfs_work_helper+0x10c/0x160 [<0000021761645760>] process_one_work+0x2b0/0x5d0 [<000002176164637e>] worker_thread+0x20e/0x3e0 [<000002176165221a>] kthread+0x15a/0x170 [<00000217615b859c>] __ret_from_fork+0x3c/0x60 [<00000217626e72d2>] ret_from_fork+0xa/0x38 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000021761597924>] _printk+0x4c/0x58 Kernel panic - not syncing: Fatal exception: panic_on_oops Reference
ent-Address: [<0000021761597924>] _printk+0x4c/0x58 Kernel panic - not syncing: Fatal exception: panic_on_oops References: - https://git.kernel.org/stable/c/25adbb08aeadcff883ab801df99fd20fefbb6ca4 - https://git.kernel.org/stable/c/0ee4736c003daded513de0ff112d4a1e9c85bbab
CVE ID: CVE-2024-57924 State: PUBLISHED Published: 2025-01-19T11:52:42.458Z Last Updated: 2025-11-03T17:31:30.542Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: relax assertions on failure to encode file handles Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle. There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those ass
users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong. The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate. The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches. Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is
>encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit. Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/73697928c806fe4689939722184a86fc1c1957b4 - https://git.kernel.org/stable/c/f47c834a9131ae64bee3c462f4e610c67b0a000f - https://git.kernel.org/stable/c/adcde2872f8fc399b249758ae1990dcd53b694ea - https://gi
9131ae64bee3c462f4e610c67b0a000f - https://git.kernel.org/stable/c/adcde2872f8fc399b249758ae1990dcd53b694ea - https://git.kernel.org/stable/c/974e3fe0ac61de85015bbe5a4990cf4127b304b2
CVE ID: CVE-2024-57925 State: PUBLISHED Published: 2025-01-19T11:52:43.244Z Last Updated: 2025-11-03T20:55:55.097Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix a missing return value check bug In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct() fails to allocate a node, it returns a NULL pointer to the in_work pointer. This can lead to an illegal memory write of in_work->response_buf when allocate_interim_rsp_buf() attempts to perform a kzalloc() on it. To address this issue, incorporating a check for the return value of ksmbd_alloc_work_struct() ensures that the function returns immediately upon allocati
ng a check for the return value of ksmbd_alloc_work_struct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/781c743e18bfd9b7dc0383f036ae952bd1486f21 - https://git.kernel.org/stable/c/ee7e40f7fb17f08a8cbae50553e5c2e10ae32fce - https://git.kernel.org/stable/c/271ae0edbfc942795c162e6cf20d2bc02bd7fde4 - https://git.kernel.org/stable/c/2976e91a3e569cf2c92c9f71512c0ab1312fe965 - https://git.kernel.org/stable/c/4c16e1cadcbcaf3c82d5fc310fbd34d0f5d0db7c
CVE ID: CVE-2024-57926 State: PUBLISHED Published: 2025-01-19T11:52:43.915Z Last Updated: 2025-05-04T10:06:47.533Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err The pointer need to be set to NULL, otherwise KASAN complains about use-after-free. Because in mtk_drm_bind, all private's drm are set as follows. private->all_drm_private[i]->drm = drm; And drm will be released by drm_dev_put in case mtk_drm_kms_init returns failure. However, the shutdown path still accesses the previous allocated memory in drm_atomic_helper_shutdown. [ 84.874820] w
e. However, the shutdown path still accesses the previous allocated memory in drm_atomic_helper_shutdown. [ 84.874820] watchdog: watchdog0: watchdog did not stop! [ 86.512054] ================================================================== [ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378 [ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022 [ 86.517960] Call trace: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86
.10 10/01/2022 [ 86.517960] Call trace: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86.519443] print_report+0xf8/0x5b0 [ 86.519985] kasan_report+0xb4/0x100 [ 86.520526] __asan_report_load8_noabort+0x20/0x30 [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 [ 86.521966] mtk_drm_shutdown+0x54/0x80 [ 86.522546] platform_shutdown+0x64/0x90 [ 86.523137] device_shutdown+0x260/0x5b8 [ 86.523728] kernel_restart+0x78/0xf0 [ 86.524282] __do_sys_reboot+0x258/0x2f0 [ 86.524871] __arm64_sys_reboot+0x90/0xd8 [ 86.525473] invoke_syscall+0x74/0x268 [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.5277
526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.527719] el0t_64_sync_handler+0x144/0x168 [ 86.528367] el0t_64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] The buggy address belongs to the physical page: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000 [ 86.534511] page dumped because: kasan: bad access detected [ 86.535323] [ 86.53555
0 00000000ffffffff 0000000000000000 [ 86.534511] page dumped because: kasan: bad access detected [ 86.535323] [ 86.535559] Memory state around the buggy address: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ================================================================== [ 86.571093] Disabling lock debugging due to ke
3928] ================================================================== [ 86.571093] Disabling lock debugging due to kernel taint [ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b [ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f] ... Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7083b93e9755d60f0c2bcaa9d064308108280534 - https://git.kernel.org/stable/c/078b2ff7da200b7532398e668eef723ad40fb516 - https://git.kernel.org/stable/c/36684e9d88a2e2401ae26715a2e217cb4295cea7
CVE ID: CVE-2024-57927 State: PUBLISHED Published: 2025-01-19T11:52:44.567Z Last Updated: 2025-10-01T19:57:14.448Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfs: Fix oops in nfs_netfs_init_request() when copying to cache When netfslib wants to copy some data that has just been read on behalf of nfs, it creates a new write request and calls nfs_netfs_init_request() to initialise it, but with a NULL file pointer. This causes nfs_file_open_context() to oops - however, we don't actually need the nfs context as we're only going to write to the cache. Fix this by just returning if we aren't given a file pointer and emit a warnin
s we're only going to write to the cache. Fix this by just returning if we aren't given a file pointer and emit a warning if the request was for something other than copy-to-cache. Further, fix nfs_netfs_free_request() so that it doesn't try to free the context if the pointer is NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/13a07cc81e2d116cece727a83746c74b87a9d417 - https://git.kernel.org/stable/c/86ad1a58f6a9453f49e06ef957a40a8dac00a13f
CVE ID: CVE-2024-57928 State: PUBLISHED Published: 2025-01-19T11:52:45.427Z Last Updated: 2025-05-04T10:06:50.545Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix enomem handling in buffered reads If netfs_read_to_pagecache() gets an error from either ->prepare_read() or from netfs_prepare_read_iterator(), it needs to decrement ->nr_outstanding, cancel the subrequest and break out of the issuing loop. Currently, it only does this for two of the cases, but there are two more that aren't handled. Fix this by moving the handling to a common place and jumping to it from all four places. This is in preference to inserting
his by moving the handling to a common place and jumping to it from all four places. This is in preference to inserting a wrapper around netfs_prepare_read_iterator() as proposed by Dmitry Antipov[1]. References: - https://git.kernel.org/stable/c/88ecdfea1b333de5c51442b45cd549eeadf01852 - https://git.kernel.org/stable/c/105549d09a539a876b7c3330ab52d8aceedad358
CVE ID: CVE-2024-57929 State: PUBLISHED Published: 2025-01-19T11:52:46.096Z Last Updated: 2025-11-03T20:55:57.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm array: fix releasing a faulty array block twice in dm_array_cursor_end When dm_bm_read_lock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dm_bm_read_lock() should not operate on this invalid dm_block pointer, or it will lead to undefined result. For example, the dm_array_cursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double rel
xample, the dm_array_cursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double release in dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put(). Reproduce steps: 1. initialize a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. wipe the second array block offline dmsteup remove cache cmeta cdata corig mapping_
8 2 metadata2 writethrough smq 0" 2. wipe the second array block offline dmsteup remove cache cmeta cdata corig mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try reopen the cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2
44" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Kernel logs: (snip) device-mapper: array: array_block_check failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: get_ablock failed device-mapper: cache metadata: dm_array_cursor_next for mapping failed ------------[ cut here ]------------ kernel BUG at drivers/md/dm-bufio.c:638! Fix by setting the cached block pointer to NULL on errors. In addition to the reproducer described above, this fix can be verified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_c
r described above, this fix can be verified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir <KERNEL_DIR> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9c7c03d0e926762adf3a3a0ba86156fb5e19538b - https://git.kernel.org/stable/c/fc1ef07c3522e257e32702954f265debbcb096a7 - https://git.kernel.org/stable/c/738994872d77e189b2d13c501a1d145e95d98f46 - https://git.kernel.org/stable/c/e477021d252c007f0c6d45b5d13d341efed03979 - https://git.kernel.org/stable/c/6002bec5354f86d1a2df21468f68e3ec03ede9da - https://git.kernel.org/stable/c/017c4470bff53585370028fec9341247bad358ff - https://git.kernel.org/st
68f68e3ec03ede9da - https://git.kernel.org/stable/c/017c4470bff53585370028fec9341247bad358ff - https://git.kernel.org/stable/c/f2893c0804d86230ffb8f1c8703fdbb18648abc8
CVE ID: CVE-2024-57930 State: PUBLISHED Published: 2025-01-21T12:01:27.807Z Last Updated: 2025-11-03T20:55:59.231Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Have process_string() also allow arrays In order to catch a common bug where a TRACE_EVENT() TP_fast_assign() assigns an address of an allocated string to the ring buffer and then references it in TP_printk(), which can be executed hours later when the string is free, the function test_event_printk() runs on all events as they are registered to make sure there's no unwanted dereferencing. It calls process_string() to handle cases in TP_printk() format that has
to make sure there's no unwanted dereferencing. It calls process_string() to handle cases in TP_printk() format that has "%s". It returns whether or not the string is safe. But it can have some false positives. For instance, xe_bo_move() has: TP_printk("move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s", __entry->move_lacks_source ? "yes" : "no", __entry->bo, __entry->size, xe_mem_type_to_name[__entry->old_placement], xe_mem_type_to_name[__entry->new_placement], __get_str(device_id)) Where the "%s" references into xe_mem_type_to_name[]. This is an array of pointers that should be safe for the event to access. Instead of flagging this as a bad reference, if a refer
n array of pointers that should be safe for the event to access. Instead of flagging this as a bad reference, if a reference points to an array, where the record field is the index, consider it safe. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3bcdc9039a6e9e6e47ed689a37b8d57894a3c571 - https://git.kernel.org/stable/c/631b1e09e213c86d5a4ce23d45c81af473bb0ac7 - https://git.kernel.org/stable/c/a64e5295ebc4afdefe69cdf16cc286a60ff8ba4b - https://git.kernel.org/stable/c/92bd18c74624e5eb9f96e70076aa46293f4b626f - https://git.kernel.org/stable/c/afc6717628f959941d7b33728570568b4af1c4b8
CVE ID: CVE-2024-57931 State: PUBLISHED Published: 2025-01-21T12:01:28.539Z Last Updated: 2025-11-03T20:56:02.355Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: selinux: ignore unknown extended permissions When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f45a77dd24ae9ddb474303ec3975c376bd99fc51 - https://git.kernel.org/stable/c/712137b177b45f255ce5687e679d950fcb218256 - https://git.kernel.org/st
c3975c376bd99fc51 - https://git.kernel.org/stable/c/712137b177b45f255ce5687e679d950fcb218256 - https://git.kernel.org/stable/c/f70e4b9ec69d9a74b84c17767a9a4eda8c901021 - https://git.kernel.org/stable/c/c79324d42fa48372e0acb306a2761cc642bd4db0 - https://git.kernel.org/stable/c/c1dbd28a079553de0023e1c938c713efeeee400f - https://git.kernel.org/stable/c/efefe36c03a73bb81c0720ce397659a5051b73fa - https://git.kernel.org/stable/c/900f83cf376bdaf798b6f5dcb2eae0c822e908b6
CVE ID: CVE-2024-57932 State: PUBLISHED Published: 2025-01-21T12:01:29.212Z Last Updated: 2025-05-04T10:06:56.476Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gve: guard XDP xmit NDO on existence of xdp queues In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false. In the case of no loaded XDP program, priv->num_xdp_queues=0 which can cause a divide-by-zero error, and in the case of interface down, num_xdp_queues remains untouched to persist XDP queue count for the next interface up, but t
the case of interface down, num_xdp_queues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL. The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call, which waits for any RCU critical sections at call-time to complete. References: - https://git.kernel.org/stable/c/cbe9eb2c39d09f3c8574febcfa39d8c09d0c7cb5 - https://git.kernel.org/stable/c/35f44eed5828cf1bc7e760d1993ed8549ba41c7b - https://git.kernel.org/stable/c/ff7c2dea9dd1a436fc79d6273adffdcc4a7ffea3
CVE ID: CVE-2024-57933 State: PUBLISHED Published: 2025-01-21T12:01:29.882Z Last Updated: 2025-10-01T19:57:14.306Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gve: guard XSK operations on the existence of queues This patch predicates the enabling and disabling of XSK pools on the existence of queues. As it stands, if the interface is down, disabling or enabling XSK pools would result in a crash, as the RX queue pointer would be NULL. XSK pool registration will occur as part of the next interface up. Similarly, xsk_wakeup needs be guarded against queues disappearing while the function is executing, so a check against the GVE_
ly, xsk_wakeup needs be guarded against queues disappearing while the function is executing, so a check against the GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the disabling of the bit and the synchronize_net() in gve_turndown. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/771d66f2bd8c4dba1286a9163ab982cecd825718 - https://git.kernel.org/stable/c/8e8d7037c89437af12725f454e2eaf40e8166c0f - https://git.kernel.org/stable/c/40338d7987d810fcaa95c500b1068a52b08eec9b