Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
- https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902 - https://git.kernel.org/stable/c/af6cfcd0efb7f051af221c418ec8b37a10211947 - https://git.kernel.org/stable/c/9cf5b2a3b72c23fb7b84736d5d19ee6ea718762b - https://git.kernel.org/stable/c/8a21d5584826f4880f45bbf8f72375f4e6c0ff2a - https://git.kernel.org/stable/c/081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0 - https://project-zero.issues.chromium.org/issues/420715744
CVE ID: CVE-2025-38085 State: PUBLISHED Published: 2025-06-28T07:44:26.178Z Last Updated: 2025-11-03T17:33:54.315Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to k
could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/952596b08c74e8fe9e2883d1dc8a8f54a37384ec - https://git.kernel.org/stable/c/a3d864c901a300c295692d129159fc3001a56185 - https://git.kernel.org/stable/c/b7754d3aa7bf9f62218d096c0c8f6c13698fac8b - https://git.kernel.org/stable/c/fe684290418ef9ef76630072086ee530b92f02b8 - http
754d3aa7bf9f62218d096c0c8f6c13698fac8b - https://git.kernel.org/stable/c/fe684290418ef9ef76630072086ee530b92f02b8 - https://git.kernel.org/stable/c/034a52b5ef57c9c8225d94e9067f3390bb33922f - https://git.kernel.org/stable/c/a6bfeb97941a9187833b526bc6cc4ff5706d0ce9 - https://git.kernel.org/stable/c/1013af4f585fccc4d3e5c5824d174de2257f7d6d - https://project-zero.issues.chromium.org/issues/420715744
CVE ID: CVE-2025-38086 State: PUBLISHED Published: 2025-06-28T07:52:58.293Z Last Updated: 2025-11-03T17:33:56.167Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uni
buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/119766de4930ff40db9f36b960cb53b0c400e81b - https://git.kernel.org/stable/c/33163c68d2e3061fa3935b5f0a1867958b1cdbd2 - https://git.kernel.org/stable/c/9da3e
0e81b - https://git.kernel.org/stable/c/33163c68d2e3061fa3935b5f0a1867958b1cdbd2 - https://git.kernel.org/stable/c/9da3e442714f7f4393ff01c265c4959c03e88c2f - https://git.kernel.org/stable/c/9a350f30d65197354706b7759b5c89d6c267b1a9 - https://git.kernel.org/stable/c/6bd2569d0b2f918e9581f744df0263caf73ee76c - https://git.kernel.org/stable/c/4da7fcc098218ff92b2e83a43f545c02f714cedd - https://git.kernel.org/stable/c/cdaa6d1cb2ff1219c6c822b27655dd170ffb0f72 - https://git.kernel.org/stable/c/9ad0452c0277b816a435433cca601304cfac7c21
CVE ID: CVE-2025-38087 State: PUBLISHED Published: 2025-06-30T07:29:43.325Z Last Updated: 2025-07-28T04:12:01.642Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this. References: - https://git.kernel.org/stable/c/8c5713ce1ced75f9e9ed5c642ea3d2ba06ead69c - https://git.kernel.org/stable/c/8a008c89e5e5c5332e4c0a33d707db9ddd529f8a - https://git.kernel.org/stable/c/b1547d28
9c - https://git.kernel.org/stable/c/8a008c89e5e5c5332e4c0a33d707db9ddd529f8a - https://git.kernel.org/stable/c/b1547d28ba468bc3b88764efd13e4319bab63be8 - https://git.kernel.org/stable/c/b160766e26d4e2e2d6fe2294e0b02f92baefcec5
CVE ID: CVE-2025-38088 State: PUBLISHED Published: 2025-06-30T07:29:44.086Z Last Updated: 2025-11-03T17:33:57.119Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/81260c41b518b6f32c701425f1427562fa92f293 - https://git.kernel.org/stable/c/620b77b23c41a6546e5548ffe2ea3ad71880dde4 - https://git.kernel.org/st
5f1427562fa92f293 - https://git.kernel.org/stable/c/620b77b23c41a6546e5548ffe2ea3ad71880dde4 - https://git.kernel.org/stable/c/8635e325b85dfb9ddebdfaa6b5605d40d16cd147 - https://git.kernel.org/stable/c/9c340b56d60545e4a159e41523dd8b23f81d3261 - https://git.kernel.org/stable/c/bbd5a9ddb0f9750783a48a871c9e12c0b68c5f39 - https://git.kernel.org/stable/c/cd097df4596f3a1e9d75eb8520162de1eb8485b2
CVE ID: CVE-2025-38089 State: PUBLISHED Published: 2025-06-30T07:29:44.836Z Last Updated: 2025-11-04T21:10:10.064Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the
lue stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. Additional Analyst Notes: -
ole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/599c489eea793821232a2f69a00fa57d82b0ac98 - https://git.kernel.org/stable/c/353e75b55e583635bf71cde6abcec274dba05edd - https://git.kernel.org/stable/c/c90459cd58bb421d275337093d8e901e0ba748dd - https://git.kernel.org/stable/c/94d10a4dba0bc482f2b01e39f06d5513d0f75742 - https://www.openwall.com/lists/oss-security/2025/07/02/2 - https://github.com/keymaker-arch/NFSundown
CVE ID: CVE-2025-38090 State: PUBLISHED Published: 2025-06-30T07:29:45.565Z Last Updated: 2025-11-03T17:33:59.041Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send(
r which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a8b5ea2e302aa5cd00fc7addd8df53c9bde7b5f6 - https://git.kernel.org/stable/c/c03ddc183249f03fc7e057e02cae6f89144d0123 - https://git.kernel.org/stable/c/58f664614f8c3d6142ab81ae551e466dc6e092e8 - https://git.kernel.org/stable/c/ecf5ee280b702270afb02f61b299d3dfe3ec7730 - https://git.kernel.org/stable/c/1921781ec4a8824bd0c520bf9363e28a880d14ec - https://git.kernel.org/stable/c/1cce6ac47f4a2ac1766b8a188dc8c8f6d8d
/stable/c/1921781ec4a8824bd0c520bf9363e28a880d14ec - https://git.kernel.org/stable/c/1cce6ac47f4a2ac1766b8a188dc8c8f6d8df2a53 - https://git.kernel.org/stable/c/6d5c6711a55c35ce09b90705546050408d9d4b61 - https://git.kernel.org/stable/c/50695153d7ddde3b1696dbf0085be0033bf3ddb3
CVE ID: CVE-2025-38091 State: PUBLISHED Published: 2025-07-02T14:43:30.118Z Last Updated: 2025-07-07T08:45:54.144Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check stream id dml21 wrapper to get plane_id [Why & How] Fix a false positive warning which occurs due to lack of correct checks when querying plane_id in DML21. This fixes the warning when performing a mode1 reset (cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover): [ 35.751250] WARNING: CPU: 11 PID: 326 at /tmp/amd.PHpyAl7v/amd/amdgpu/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu] [ 35.751434] Modules linked in:
/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu] [ 35.751434] Modules linked in: amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_ttm_helper ttm drm_display_helper cec rc_core i2c_algo_bit rfcomm qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi snd_hda_intel edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_amd snd_hda_core snd_hwdep snd_pcm kvm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3
nt snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3 snd_seq btintel aesni_intel btbcm btmtk snd_seq_device crypto_simd sunrpc cryptd bluetooth snd_timer ccp binfmt_misc rapl snd i2c_piix4 wmi_bmof gigabyte_wmi k10temp i2c_smbus soundcore gpio_amdpt mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul igc ahci xhci_pci libahci xhci_pci_renesas video wmi [ 35.751501] CPU: 11 UID: 0 PID: 326 Comm: kworker/u64:9 Tainted: G OE 6.11.0-21-generic #21~24.04.1-Ubuntu [ 35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 35.751505] Hard
d: G OE 6.11.0-21-generic #21~24.04.1-Ubuntu [ 35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 35.751505] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F30 05/22/2024 [ 35.751506] Workqueue: amdgpu-reset-dev amdgpu_debugfs_reset_work [amdgpu] [ 35.751638] RIP: 0010:dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu] [ 35.751794] Code: 6d 0c 00 00 8b 84 24 88 00 00 00 41 3b 44 9c 20 0f 84 fc 07 00 00 48 83 c3 01 48 83 fb 06 75 b3 4c 8b 64 24 68 4c 8b 6c 24 40 <0f> 0b b8 06 00 00 00 49 8b 94 24 a0 49 00 00 89 c3 83 f8 07 0f 87 [ 35.751796] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246 [ 35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000
96] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246 [ 35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000000000 [ 35.751799] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000 [ 35.751800] RBP: ffffbfa3805d78f0 R08: 0000000000000000 R09: 0000000000000000 [ 35.751801] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbfa383249000 [ 35.751802] R13: ffffa0e68f280000 R14: ffffbfa383249658 R15: 0000000000000000 [ 35.751803] FS: 0000000000000000(0000) GS:ffffa0edbe580000(0000) knlGS:0000000000000000 [ 35.751804] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0 [ 35.751806] PKRU: 55555554
0000080050033 [ 35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0 [ 35.751806] PKRU: 55555554 [ 35.751807] Call Trace: [ 35.751810] <TASK> [ 35.751816] ? show_regs+0x6c/0x80 [ 35.751820] ? __warn+0x88/0x140 [ 35.751822] ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu] [ 35.751964] ? report_bug+0x182/0x1b0 [ 35.751969] ? handle_bug+0x6e/0xb0 [ 35.751972] ? exc_invalid_op+0x18/0x80 [ 35.751974] ? asm_exc_invalid_op+0x1b/0x20 [ 35.751978] ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu] [ 35.752117] ? math_pow+0x48/0xa0 [amdgpu] [ 35.752256] ? srso_alias_return_thunk+0x5/0xfbef5 [ 35.752260] ? math_pow+0x48/0xa0 [amdgpu] [ 35.752400] ? srso_alias_return_thunk+0x5/0xfbef5 [ 35.752
thunk+0x5/0xfbef5 [ 35.752260] ? math_pow+0x48/0xa0 [amdgpu] [ 35.752400] ? srso_alias_return_thunk+0x5/0xfbef5 [ 35.752403] ? math_pow+0x11/0xa0 [amdgpu] [ 35.752524] ? srso_alias_return_thunk+0x5/0xfbef5 [ 35.752526] ? core_dcn4_mode_programming+0xe4d/0x20d0 [amdgpu] [ 35.752663] ? srso_alias_return_thunk+0x5/0xfbef5 [ 35.752669] dml21_validate+0x3d4/0x980 [amdgpu] (cherry picked from commit f8ad62c0a93e5dd94243e10f1b742232e4d6411e) References: - https://git.kernel.org/stable/c/6f47d7408133631a1b178f8a04e79aee189ef046 - https://git.kernel.org/stable/c/c53f23f7075c9f63f14d7ec8f2cc3e33e118d986 - https://git.kernel.org/stable/c/2ddac70fed50485aa4ae49cdb7478ce41d8d4715
CVE ID: CVE-2025-38092 State: PUBLISHED Published: 2025-07-02T14:43:30.776Z Last Updated: 2025-09-03T13:06:51.760Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: use list_first_entry_or_null for opinfo_get_list() The list_first_entry() macro never returns NULL. If the list is empty then it returns an invalid pointer. Use list_first_entry_or_null() to check if the list is empty. References: - https://git.kernel.org/stable/c/c78abb646ff823e7d22faad4cc0703d4484da9e8 - https://git.kernel.org/stable/c/334da674b25fdb7a1a4d4b89dcd7795144fc7e11 - https://git.kernel.org/stable/c/cb7e06e9736d73007dc8dab7b353733bb37df86b - https://
74b25fdb7a1a4d4b89dcd7795144fc7e11 - https://git.kernel.org/stable/c/cb7e06e9736d73007dc8dab7b353733bb37df86b - https://git.kernel.org/stable/c/10379171f346e6f61d30d9949500a8de4336444a
CVE ID: CVE-2025-38093 State: PUBLISHED Published: 2025-07-02T14:43:31.415Z Last Updated: 2025-07-28T04:12:07.474Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: x1e80100: Add GPU cooling Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. With certain high GPU loads it is possible to reach the critical hardware shutdown temperature of 120°C, endangering the hardware and making it impossible to run certain applications. Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms. References: - https://git
ar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms. References: - https://git.kernel.org/stable/c/cd9d354bdd28b20a8f3170dab3bc0f096e66d6b4 - https://git.kernel.org/stable/c/ae664ca09072857349857530dce12e09c048b12d - https://git.kernel.org/stable/c/d145a6a3e252f093dc243d2944fecb2387a3d690 - https://git.kernel.org/stable/c/5ba21fa11f473c9827f378ace8c9f983de9e0287
CVE ID: CVE-2025-38094 State: PUBLISHED Published: 2025-07-03T07:44:17.442Z Last Updated: 2025-11-03T19:58:26.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore. Additional Analyst Notes: - C
instead of jiffies so that the timeout really works and we do not have a deadlock anymore. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d - https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2 - https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7 - https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4 - https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48 - https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37 - https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f
CVE ID: CVE-2025-38095 State: PUBLISHED Published: 2025-07-03T07:44:18.214Z Last Updated: 2025-11-03T19:58:27.686Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/90eb79c4ed98a4e24a62ccf61c199ab0f680fa8f - https://git.kernel.org/stable/c/d0b7f11dd68b593bd970e5735be00e8d89bace30 - htt
0eb79c4ed98a4e24a62ccf61c199ab0f680fa8f - https://git.kernel.org/stable/c/d0b7f11dd68b593bd970e5735be00e8d89bace30 - https://git.kernel.org/stable/c/3becc659f9cb76b481ad1fb71f54d5c8d6332d3f - https://git.kernel.org/stable/c/c9d2b9a80d06a58f37e0dc8c827075639b443927 - https://git.kernel.org/stable/c/fe1bebd0edb22e3536cbc920ec713331d1367ad4 - https://git.kernel.org/stable/c/08680c4dadc6e736c75bc2409d833f03f9003c51 - https://git.kernel.org/stable/c/72c7d62583ebce7baeb61acce6057c361f73be4a
CVE ID: CVE-2025-38096 State: PUBLISHED Published: 2025-07-03T08:13:57.007Z Last Updated: 2025-07-03T08:13:57.007Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: don't warn when if there is a FW error iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently. References: - https://git.kernel.org/stable/c/0446d34a853d9576e2a7628c803d2abd2f8cf3a8 - https://git.kernel.org/stable/c/d07a08f42dc7230c902e1af2a899a72b0a03aa69 - https://git.kernel.org/stable/c/c7f50d0433a016d43681592
t.kernel.org/stable/c/d07a08f42dc7230c902e1af2a899a72b0a03aa69 - https://git.kernel.org/stable/c/c7f50d0433a016d43681592836a3d484817bfb34
CVE ID: CVE-2025-38097 State: PUBLISHED Published: 2025-07-03T08:13:57.694Z Last Updated: 2025-11-03T17:34:02.117Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly del
h or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e4cde54b46a87231c77256a633be1bef62687d69 - https://g
VE Program Container: References: - https://git.kernel.org/stable/c/e4cde54b46a87231c77256a633be1bef62687d69 - https://git.kernel.org/stable/c/b58a295d10065960bcb9d60cb8ca6ead9837cd27 - https://git.kernel.org/stable/c/9cbca30102028f9ad3d2098f935c4368f581fd07 - https://git.kernel.org/stable/c/74fd327767fb784c5875cf7c4ba1217f26020943 - https://git.kernel.org/stable/c/028363685bd0b7a19b4a820f82dd905b1dc83999
CVE ID: CVE-2025-38098 State: PUBLISHED Published: 2025-07-03T08:13:58.603Z Last Updated: 2025-09-03T13:06:53.318Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will "work" it's wrong and might lead to unknown bad things. Just... don't. References: - https://git.kernel.org/stable/c/b14e726d57f61085485f107a6203c50a09695abd - https://git.kernel.org/stable/c/18ca68f7c657721583a75cab01f0d0d2ec63a6c9 - https://git.kernel.org/stable/c/cbf48
95abd - https://git.kernel.org/stable/c/18ca68f7c657721583a75cab01f0d0d2ec63a6c9 - https://git.kernel.org/stable/c/cbf4890c6f28fb1ad733e14613fbd33c2004bced
CVE ID: CVE-2025-38099 State: PUBLISHED Published: 2025-07-03T08:13:59.288Z Last Updated: 2025-07-03T08:13:59.288Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken A SCO connection without the proper voice_setting can cause the controller to lock up. References: - https://git.kernel.org/stable/c/f48ee562c095e552a30b8d9cc0566a267b410f8a - https://git.kernel.org/stable/c/ec1f015ec0c6fd250a6564e8452f7bb3160b9cb1 - https://git.kernel.org/stable/c/14d17c78a4b1660c443bae9d38c814edea506f62
CVE ID: CVE-2025-38100 State: PUBLISHED Published: 2025-07-03T08:35:09.487Z Last Updated: 2025-11-03T17:34:04.011Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with