Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5 - https://git.kernel.org/stable/c/df
erences: - https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5 - https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef - https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84 - https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4 - https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9 - https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8
CVE ID: CVE-2024-35872 State: PUBLISHED Published: 2024-05-19T08:34:30.096Z Last Updated: 2025-05-04T09:07:19.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might b
the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf
nrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e - https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48 - https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8 - https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5 - https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
CVE ID: CVE-2024-35873 State: PUBLISHED Published: 2024-05-19T08:34:30.928Z Last Updated: 2025-05-04T09:07:21.321Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Fix vector state restore in rt_sigreturn() The RISC-V Vector specification states in "Appendix D: Calling Convention for Vector State" [1] that "Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.". In the RISC-V kernel this is called "discarding the vstate". Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the v
gnal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard. The "live state" is the actual vector register in the running context, and the "vstate" is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch. When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state. An example when this go wrong: 1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is ent
: 1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as "dirty", indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the Vector registers, from the sigcontext 6. rt_sigreturn() restores the Vector registers, from the sigcontext, and now the vectorized user_from_copy() is used. The dirty live state from the discard is saved to the vstate, making the vstate corrupt.
rized user_from_copy() is used. The dirty live state from the discard is saved to the vstate, making the vstate corrupt. 7. rt_sigreturn() returns to the application, which crashes due to corrupted vstate. Note that the vectorized user_from_copy() is invoked depending on the value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which means that vlen has to be larger than 128b for this bug to trigger. The fix is simply to mark the live state as non-dirty/clean prior performing the vstate restore. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5b16d904e910183181b9d90efa957c787a8ac91b - https://git.kernel.org/stab
nt: References: - https://git.kernel.org/stable/c/5b16d904e910183181b9d90efa957c787a8ac91b - https://git.kernel.org/stable/c/c27fa53b858b4ee6552a719aa599c250cf98a586
CVE ID: CVE-2024-35874 State: PUBLISHED Published: 2024-05-19T08:34:31.937Z Last Updated: 2025-05-04T09:07:22.623Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: aio: Fix null ptr deref in aio_complete() wakeup list_del_init_careful() needs to be the last access to the wait queue entry - it effectively unlocks access. Previously, finish_wait() would see the empty list head and skip taking the lock, and then we'd return - but the completion path would still attempt to do the wakeup after the task_struct pointer had been overwritten. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https:/
had been overwritten. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9678bcc6234d83759fe091c197f5017a32b468da - https://git.kernel.org/stable/c/caeb4b0a11b3393e43f7fa8e0a5a18462acc66bd
CVE ID: CVE-2024-35875 State: PUBLISHED Published: 2024-05-19T08:34:32.767Z Last Updated: 2025-05-04T09:07:24.597Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- d
ve nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 dri
is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. Many device drivers and platforms have some desire to contribute something to the RNG, and add_device_randomness() is specifically meant for this purpose. Any driver can call it with seed data of any quality, or even garbage quality, and it can only possibly make the quality of the RNG better or have no effect, but can never make it worse. Rather than trying to build something into the core of the RNG, consider the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [
the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [ bp: Massage commit message. ] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374 - https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5 - https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e - https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584
CVE ID: CVE-2024-35876 State: REJECTED Published: 2024-05-19T08:34:33.602Z Last Updated: 2024-05-23T13:32:01.079Z Description: No description available.
CVE ID: CVE-2024-35877 State: PUBLISHED Published: 2024-05-19T08:34:34.604Z Last Updated: 2025-05-04T09:07:25.990Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() an
he address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an an
, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd =
h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553
ap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS:
8 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2
0c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b - https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173 - https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d495
table/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173 - https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4 - https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a - https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f - https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec - https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6 - https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221
CVE ID: CVE-2024-35878 State: PUBLISHED Published: 2024-05-19T08:34:35.622Z Last Updated: 2025-05-04T09:07:27.295Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) wit
nce snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b - https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898 - https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987
CVE ID: CVE-2024-35879 State: PUBLISHED Published: 2024-05-19T08:34:36.450Z Last Updated: 2025-05-04T12:55:59.140Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the remova
R: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf
DP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a - https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c - https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951 - https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82 - https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c - https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84
CVE ID: CVE-2024-35880 State: PUBLISHED Published: 2024-05-19T08:34:37.262Z Last Updated: 2025-05-04T09:07:30.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: hold io_buffer_list reference over mmap If we look up the kbuf, ensure that it doesn't get unregistered until after we're done with it. Since we're inside mmap, we cannot safely use the io_uring lock. Rely on the fact that we can lookup the buffer list under RCU now and grab a reference to it, preventing it from being unregistered until we're done with it. The lookup returns the io_buffer_list directly with it referenced. Additional Analyst Notes: - CISA
we're done with it. The lookup returns the io_buffer_list directly with it referenced. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/65938e81df2197203bda4b9a0c477e7987218d66 - https://git.kernel.org/stable/c/5fd8e2359498043e0b5329a05f02d10a9eb91eb9 - https://git.kernel.org/stable/c/561e4f9451d65fc2f7eef564e0064373e3019793
CVE ID: CVE-2024-35881 State: REJECTED Published: 2024-05-19T08:34:38.182Z Last Updated: 2024-05-23T13:35:34.916Z Description: No description available.
CVE ID: CVE-2024-35882 State: PUBLISHED Published: 2024-05-19T08:34:39.185Z Last Updated: 2025-05-04T09:07:31.310Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP Jan Schunk reports that his small NFS servers suffer from memory exhaustion after just a few days. A bisect shows that commit e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single sock_sendmsg() call") is the first bad commit. That commit assumed that sock_sendmsg() releases all the pages in the underlying bio_vec array, but the reality is that it doesn't. svc_xprt_release() releases the rqst's respons
ages in the underlying bio_vec array, but the reality is that it doesn't. svc_xprt_release() releases the rqst's response pages, but the record marker page fragment isn't one of those, so it is never released. This is a narrow fix that can be applied to stable kernels. A more extensive fix is in the works. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8 - https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882 - https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861
CVE ID: CVE-2024-35883 State: PUBLISHED Published: 2024-05-19T08:34:40.035Z Last Updated: 2025-05-04T09:07:32.530Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe In function pci1xxxx_spi_probe, there is a potential null pointer that may be caused by a failed memory allocation by the function devm_kzalloc. Hence, a null pointer check needs to be added to prevent null pointer dereferencing later in the code. To fix this issue, spi_bus->spi_int[iter] should be checked. The memory allocated by devm_kzalloc will be automatically released, so just directl
s->spi_int[iter] should be checked. The memory allocated by devm_kzalloc will be automatically released, so just directly return -ENOMEM without worrying about memory leaks. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4b31a226097cf8cc3c9de5e855d97757fdb2bf06 - https://git.kernel.org/stable/c/95e5d9eb26705a9a76d2ef8bcba9ee2e195d653d - https://git.kernel.org/stable/c/1f886a7bfb3faf4c1021e73f045538008ce7634e
CVE ID: CVE-2024-35884 State: PUBLISHED Published: 2024-05-19T08:34:40.948Z Last Updated: 2025-05-04T09:07:33.854Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the pac
n the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] trigger
depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the