Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ut() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is released in an unexpected state. Fix this by removing the extra pci_dev_put(). References: - https://git.kernel.org/stable/c/c488f8b53e156d6dcc0514ef0afa3a33376b8f9e - https://git.kernel.org/stable/c/957529baef142d95e0d1b1bea786675bd47dbe53 - https://git.kernel.org/stable/c/05a2538f2b48500cf4e8a0a0ce76623cc5bafcf1
CVE ID: CVE-2025-37947 State: PUBLISHED Published: 2025-05-20T16:01:43.788Z Last Updated: 2025-11-03T19:57:37.368Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned. Additional Analyst Notes: - CISA ADP Vulnrichment: - CV
before proceeding. If the condition fails, -EINVAL is returned. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/7f61da79df86fd140c7768e668ad846bfa7ec8e1 - https://git.kernel.org/stable/c/04c8a38c60346bb5a7c49b276de7233f703ce9cb - https://git.kernel.org/stable/c/d62ba16563a86aae052f96d270b3b6f78fca154c - https://git.kernel.org/stable/c/e6356499fd216ed6343ae0363f4c9303f02c5034 - https://git.kernel.org/stable/c/0ca6df4f40cf4c32487944aaf48319cb6c25accc
CVE ID: CVE-2025-37948 State: PUBLISHED Published: 2025-05-20T16:01:44.452Z Last Updated: 2025-11-03T19:57:38.769Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c6a8735d841bcb7649734bb3a787bb174c67c0d8 - https://gi
E Program Container: References: - https://git.kernel.org/stable/c/c6a8735d841bcb7649734bb3a787bb174c67c0d8 - https://git.kernel.org/stable/c/993f63239c219696aef8887a4e7d3a16bf5a8ece - https://git.kernel.org/stable/c/8fe5c37b0e08a97cf0210bb75970e945aaaeebab - https://git.kernel.org/stable/c/42a20cf51011788f04cf2adbcd7681f02bdb6c27 - https://git.kernel.org/stable/c/38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78 - https://git.kernel.org/stable/c/852b8ae934b5cbdc62496fa56ce9969aa2edda7f - https://git.kernel.org/stable/c/0dfefc2ea2f29ced2416017d7e5b1253a54c2735
CVE ID: CVE-2025-37949 State: PUBLISHED Published: 2025-05-20T16:01:45.242Z Last Updated: 2025-11-03T19:57:40.135Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xenbus: Use kref to track req lifetime Marek reported seeing a NULL pointer fault in the xenbus_thread callstack: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: <TASK> __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wak
eq->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wake_up() in this case. It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed data. Linux Device Drivers 2nd edition states: "Normally, a wake_up call can cause an immediate reschedule to happen, meaning that other processes might run before wake_up returns." ... which would match the behaviour observed. Change to keeping two krefs on each request. One for the caller, and one for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the descript
for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the description in Documentation/core-api/kref.rst Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5 - https://git.kernel.org/stable/c/f1bcac367bc95631afbb918348f30dec887d0e1b - https://git.kernel.org/stable/c/4d260a5558df4650eb87bc41b2c9ac2d6b2ba447 - https://git.kernel.org/stable/c/8b02f85e84dc6f7c150cef40ddb69af5a25659e5 - https://git.kernel.org/stable/c/cbfaf46b88a4c01b64c4186cdccd766c19ae644c - https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92 - https://git.kernel.org/sta
dccd766c19ae644c - https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92 - https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59 - https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
CVE ID: CVE-2025-37950 State: PUBLISHED Published: 2025-05-20T16:01:45.918Z Last Updated: 2025-05-26T05:24:22.776Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix panic in failed foilio allocation commit 7e119cff9d0a ("ocfs2: convert w_pages to w_folios") and commit 9a5e08652dc4b ("ocfs2: use an array of folios instead of an array of pages") save -ENOMEM in the folio array upon allocation failure and call the folio array free code. The folio array free code expects either valid folio pointers or NULL. Finding the -ENOMEM will result in a panic. Fix by NULLing the error folio entry. References: - https://git.kernel.org
. Finding the -ENOMEM will result in a panic. Fix by NULLing the error folio entry. References: - https://git.kernel.org/stable/c/80d18f060d5bdf2c5eb3d1d00dcb744d6a879222 - https://git.kernel.org/stable/c/31d4cd4eb2f8d9b87ebfa6a5e443a59e3b3d7b8c
CVE ID: CVE-2025-37951 State: PUBLISHED Published: 2025-05-20T16:01:46.555Z Last Updated: 2025-11-03T19:57:41.523Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, wh
ion is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5235b56b7e5449d990d21d78723b1a5e7bb5738e - https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767 - https://git.kerne
990d21d78723b1a5e7bb5738e - https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767 - https://git.kernel.org/stable/c/a5f162727b91e480656da1876247a91f651f76de - https://git.kernel.org/stable/c/422a8b10ba42097a704d6909ada2956f880246f2 - https://git.kernel.org/stable/c/35e4079bf1a2570abffce6ababa631afcf8ea0e5
CVE ID: CVE-2025-37952 State: PUBLISHED Published: 2025-05-20T16:01:47.164Z Last Updated: 2025-05-26T05:24:25.544Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from th
acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock. References: - https://git.kernel.org/stable/c/fec1f9e9a650e8e7011330a085c77e7bf2a08ea9 - https://git.kernel.org/stable/c/9e9841e232b51171ddf3bc4ee517d5d28dc8cad6 - https://git.kernel.org/stable/c/16727e442568a46d9cca69fe2595896de86e120d - https://git.kernel.org/stable/c/36991c1ccde2d5a521577c448ffe07fcccfe104d
CVE ID: CVE-2025-37953 State: PUBLISHED Published: 2025-05-20T16:01:47.818Z Last Updated: 2025-11-03T19:57:42.885Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sch_htb: make htb_deactivate() idempotent Alan reported a NULL pointer dereference in htb_next_rb_node() after we made htb_qlen_notify() idempotent. It turns out in the following case it introduced some regression: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be a
() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be already set to NULL, which means htb_next_rb_node() is vulnerable here. For htb_deactivate(), although we checked qlen before calling it, in case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again which triggers the warning inside. To fix the issues here, we need to: 1) Make htb_deactivate() idempotent, that is, simply return if we already call it before. 2) Make htb_next_rb_node() safe against ptr==NULL. Many thanks to Alan for testing and for the reproducer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/99f
for the reproducer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/99ff8a20fd61315bf9ae627440a5ff07d22ee153 - https://git.kernel.org/stable/c/a9945f7cf1709adc5d2d31cb6cfc85627ce299a8 - https://git.kernel.org/stable/c/c2d25fddd867ce20a266806634eeeb5c30cb520c - https://git.kernel.org/stable/c/c928dd4f6bf0c25c72b11824a1e9ac9bd37296a0 - https://git.kernel.org/stable/c/31ff70ad39485698cf779f2078132d80b57f6c07 - https://git.kernel.org/stable/c/98cd7ed92753090a714f0802d4434314526fe61d - https://git.kernel.org/stable/c/c4792b9e38d2f61b07eac72f10909fa76130314b - https://git.kernel.org/stable/c/3769478610135e82b262640252d90f6efb05be71
CVE ID: CVE-2025-37954 State: PUBLISHED Published: 2025-05-20T16:01:48.561Z Last Updated: 2025-05-26T05:24:28.211Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: Avoid race in open_cached_dir with lease breaks A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked. References: -
e by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked. References: - https://git.kernel.org/stable/c/2ed98e89ebc2e1bc73534dc3c18cb7843a889ff9 - https://git.kernel.org/stable/c/571dcf3d27b24800c171aea7b5e04ff06d10e2e9 - https://git.kernel.org/stable/c/2407265dc32bc8cc45b62a612c2a214ba9038e8b - https://git.kernel.org/stable/c/3ca02e63edccb78ef3659bebc68579c7224a6ca2
CVE ID: CVE-2025-37955 State: PUBLISHED Published: 2025-05-20T16:01:49.209Z Last Updated: 2025-05-26T05:24:29.422Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc
00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f References: - https://git.kernel.org/stable/c/94a6f6c204abb2b2dcd2ce287536cc924469cfb5 - https://git.kernel.org/stable/c/ba6917810bb4a5a32661fa941717399052b3f0d9 - https://git.kernel.org/stable/c/4397684a292a71fbc1e815c3e283f7490ddce5ae
CVE ID: CVE-2025-37956 State: PUBLISHED Published: 2025-05-20T16:01:49.865Z Last Updated: 2025-05-26T05:24:30.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent rename with empty string Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string. References: - https://git.kernel.org/stable/c/6ee551672c8cf36108b0cfba92ec0c7c28ac3439 - https://git.kernel.org/stable/c/c57301e332cc413fe0a7294a90725f4e21e9549d - https://git.kernel.org/stable/c/d7f2c00acb1ef64304fd40ac507e9213ff1d
stable/c/c57301e332cc413fe0a7294a90725f4e21e9549d - https://git.kernel.org/stable/c/d7f2c00acb1ef64304fd40ac507e9213ff1d9b5c - https://git.kernel.org/stable/c/53e3e5babc0963a92d856a5ec0ce92c59f54bc12
CVE ID: CVE-2025-37957 State: PUBLISHED Published: 2025-05-20T16:01:50.878Z Last Updated: 2025-05-26T05:24:32.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This
sion results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x
fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
in.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and
ically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [sean: massage changelog, make it clear this isn't architectural behavior] References: - https://git.kernel.org/stable/c/ec24e62a1dd3540ee696314422040180040c1e4a - https://git.kernel.org/stable/c/d362b21fefcef7eda8f1cd78a5925735d2b3287c - https://git.kernel.org/stable/c/e9b28bc65fd3a56755ba503258024608292b4ab1 - https://git.kernel.org/stable/c/a2620f8932fa9fdabc3d78ed6efb004ca409019f
CVE ID: CVE-2025-37958 State: PUBLISHED Published: 2025-05-20T16:01:51.740Z Last Updated: 2025-11-03T17:32:46.448Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix dereferencing invalid pmd migration entry When migrating a THP, concurrent access to the PMD migration entry during a deferred split scan can lead to an invalid address access, as illustrated below. To prevent this invalid access, it is necessary to check the PMD migration entry and return early. In this context, there is no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality of the target folio. Since the PMD migration en
o use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality of the target folio. Since the PMD migration entry is locked, it cannot be served as the target. Mailing list discussion and explanation from Hugh Dickins: "An anon_vma lookup points to a location which may contain the folio of interest, but might instead contain another folio: and weeding out those other folios is precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of replacing the wrong folio" comment a few lines above it) is for." BUG: unable to handle page fault for address: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9,
0001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60 Call Trace: <TASK> try_to_migrate_one+0x28c/0x3730 rmap_walk_anon+0x4f6/0x770 unmap_folio+0x196/0x1f0 split_huge_page_to_list_to_order+0x9f6/0x1560 deferred_split_scan+0xac5/0x12a0 shrinker_debugfs_scan_write+0x376/0x470 full_proxy_write+0x15c/0x220 vfs_write+0x2fc/0xcb0 ksys_write+0x146/0x250 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e The bug is found by syzkaller on an internal kernel, then confirmed on upstream. Additional Analyst Notes: - CVE Program Contain
is found by syzkaller on an internal kernel, then confirmed on upstream. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/753f142f7ff7d2223a47105b61e1efd91587d711 - https://git.kernel.org/stable/c/9468afbda3fbfcec21ac8132364dff3dab945faf - https://git.kernel.org/stable/c/ef5706bed97e240b4abf4233ceb03da7336bc775 - https://git.kernel.org/stable/c/22f6368768340260e862f35151d2e1c55cb1dc75 - https://git.kernel.org/stable/c/3977946f61cdba87b6b5aaf7d7094e96089583a5 - https://git.kernel.org/stable/c/6166c3cf405441f7147b322980144feb3cefc617 - https://git.kernel.org/stable/c/fbab262b0c8226c697af1851a424896ed47dedcc - https://git.kernel.org/stable/c/be6e8
fc617 - https://git.kernel.org/stable/c/fbab262b0c8226c697af1851a424896ed47dedcc - https://git.kernel.org/stable/c/be6e843fc51a584672dfd9c4a6a24c8cb81d5fb7
CVE ID: CVE-2025-37959 State: PUBLISHED Published: 2025-05-20T16:01:52.547Z Last Updated: 2025-11-03T19:57:44.271Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the
ust went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth
..] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .act
on .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy