Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-40114 State: PUBLISHED Published: 2025-04-18T07:01:40.964Z Last Updated: 2025-10-01T14:47:33.777Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: light: Add check for array bounds in veml6075_read_int_time_ms The array contains only 5 elements, but the index calculated by veml6075_read_int_time_index can range from 0 to 7, which could lead to out-of-bounds access. The check prevents this issue. Coverity Issue CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN) overrun-local: Overrunning array veml6075_it_ms of 5 4-byte elements at element index 7 (byte offset 31) using index int_index (which evaluates to 7
rray veml6075_it_ms of 5 4-byte elements at element index 7 (byte offset 31) using index int_index (which evaluates to 7) This is hardening against potentially broken hardware. Good to have but not necessary to backport. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7a40b52d4442178bee0cf1c36bc450ab951cef0f - https://git.kernel.org/stable/c/18a08b5632809faa671279b3cd27d5f96cc5a3f0 - https://git.kernel.org/stable/c/9c40a68b7f97fa487e6c7e67fcf4f846a1f96692 - https://git.kernel.org/stable/c/ee735aa33db16c1fb5ebccbaf84ad38f5583f3cc
CVE ID: CVE-2025-40115 State: PUBLISHED Published: 2025-11-12T10:23:17.283Z Last Updated: 2025-11-12T10:23:17.283Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() During mpt3sas_transport_port_remove(), messages were logged with dev_printk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device. Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protec
ia the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db
4 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:00000000
f4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] <TASK> [83428.295850] _dev_printk+0x5c/0x80 [83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas] [83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas] [83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.29591
4] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas] [83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas] [83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas] [83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pci_device_remove+0x3b/0xb0 [83428.295962] device_release_driver_internal+0x193/0x200 [83428.295968] driver_detach+0x44/0x90 [83428.295971] bus_remove_driver+0x69/0xf0 [83428.295975] pci_unregister_driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x1
driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310 [83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296000] ? __x64_sys_getdents64+0x9a/0x110 [83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296009] ? syscall_trace_enter+0xf6/0x1b0 [83428.296014] do_syscall_64+0x7b/0x2c0 [83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e References: - https://git.kernel.org/stable/c/b3a6d153861d0f29b80882470d14aafb8d687dc2 - https://git.kernel.org/stable/c/4e1442bae50ed633c2fe8058f47cd79b4ad88b9b - https://git.kernel.org/stable/c/a89253eb4e648deace48a4e
t.kernel.org/stable/c/4e1442bae50ed633c2fe8058f47cd79b4ad88b9b - https://git.kernel.org/stable/c/a89253eb4e648deace48a4e38996afd182eb95e3 - https://git.kernel.org/stable/c/fa153fb40c61f8ca01237427c97a0b93ba32c403 - https://git.kernel.org/stable/c/6459dba4f35017448535a799cf699d5205eb5489 - https://git.kernel.org/stable/c/1fd39e14d47d9b4965dd5c9cff16e64ba3e71a62 - https://git.kernel.org/stable/c/970ceb1bdc3d6c2af9245d6eca38606e74fcb6b8 - https://git.kernel.org/stable/c/1703fe4f8ae50d1fb6449854e1fcaed1053e3a14
CVE ID: CVE-2025-40116 State: PUBLISHED Published: 2025-11-12T10:23:17.569Z Last Updated: 2025-11-12T10:23:17.569Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup The kthread_run() function returns error pointers so the max3421_hcd->spi_thread pointer can be either error pointers or NULL. Check for both before dereferencing it. References: - https://git.kernel.org/stable/c/89838fe5c6c010ff8d3924f22afd9c18c5c95310 - https://git.kernel.org/stable/c/3facf69a735e730ae36387f18780fe420708aa91 - https://git.kernel.org/stable/c/e0e0ce06f3571be9b26790e4df56ba37b1de854
ble/c/3facf69a735e730ae36387f18780fe420708aa91 - https://git.kernel.org/stable/c/e0e0ce06f3571be9b26790e4df56ba37b1de8543 - https://git.kernel.org/stable/c/3723c3dda1cc82c9bbca08fcbd46705a361bfd56 - https://git.kernel.org/stable/c/b0439e3762ac9ea580f714e1504a1827d1ad32f5 - https://git.kernel.org/stable/c/e68ea6de1d0551f90d7a2c75f82cb3ebe5e397dc - https://git.kernel.org/stable/c/b682ce44bf20ada752a2f6ce70d5a575c56f6a35 - https://git.kernel.org/stable/c/186e8f2bdba551f3ae23396caccd452d985c23e3
CVE ID: CVE-2025-40117 State: PUBLISHED Published: 2025-11-12T10:23:17.851Z Last Updated: 2025-11-12T10:23:17.851Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl() Commit eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case") added NO_BAR (-1) to the pci_barno enum which, in practical terms, changes the enum from an unsigned int to a signed int. If the user passes a negative number in pci_endpoint_test_ioctl() then it results in an array underflow in pci_endpoint_test_bar(). References: - https://git.kernel.org/stable/c/6df3687922570f753574c40b35e
an array underflow in pci_endpoint_test_bar(). References: - https://git.kernel.org/stable/c/6df3687922570f753574c40b35e83b26b32292d0 - https://git.kernel.org/stable/c/1ad82f9db13d85667366044acdfb02009d576c5a
CVE ID: CVE-2025-40118 State: PUBLISHED Published: 2025-11-12T10:23:18.179Z Last Updated: 2025-11-12T10:23:18.179Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]' on rmmod when using an expander. For a direct attached device, attached_phy contains the local phy id. For a device behind an expander, attached_phy contains the remote phy id, not the
tached_phy contains the local phy id. For a device behind an expander, attached_phy contains the remote phy id, not the local phy id. I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a device behind an expander, attached_phy can be much larger than pm8001_ha->chip->n_phy (depending on the amount of phys of the expander). E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the ports has an expander connected. The expander has 31 phys with phy ids 0-30. The pm8001_ha->phy array only contains the phys of the HBA. It does not contain the phys of the expander. Thus, it is wrong to use attached_phy to index the pm8001_ha->phy array for a device behind an expander.
the expander. Thus, it is wrong to use attached_phy to index the pm8001_ha->phy array for a device behind an expander. Thus, we can only clear phy_attached for devices that are directly attached. References: - https://git.kernel.org/stable/c/d94be0a6ae9ade706d4270e740bdb4f79953a7fc - https://git.kernel.org/stable/c/45acbf154befedd9bc135f5e031fe7855d1e6493 - https://git.kernel.org/stable/c/eef5ef400893f8e3dbb09342583be0cdc716d566 - https://git.kernel.org/stable/c/9c671d4dbfbfb0d73cfdfb706afb36d9ad60a582 - https://git.kernel.org/stable/c/e62251954a128a2d0fcbc19e5fa39e08935bb628 - https://git.kernel.org/stable/c/9326a1541e1b7ed3efdbab72061b82cf01c6477a - https://git.kernel.org/stable/c/83ced3c
628 - https://git.kernel.org/stable/c/9326a1541e1b7ed3efdbab72061b82cf01c6477a - https://git.kernel.org/stable/c/83ced3c206c292458e47c7fac54223abc7141585 - https://git.kernel.org/stable/c/251be2f6037fb7ab399f68cd7428ff274133d693
CVE ID: CVE-2025-40119 State: PUBLISHED Published: 2025-11-12T10:23:18.449Z Last Updated: 2025-11-12T10:23:18.449Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential null deref in ext4_mb_init() In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy() lacks null pointer checking, this leads to a null pointer dereference. ================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer d
================================================= EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40 Call Trace: <TASK> xa_destroy+0x61/0x130 ext4_mb_init+0x483/0x540 __ext4_fill_super+0x116d/0x17b0 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 do_new_mount+0x197/0x300 __x64_sys_mount+0x116/0x150 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore, add n
y_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy() to prevent this issue. The same fix is also applied to ext4_mb_largest_free_orders_destroy(). References: - https://git.kernel.org/stable/c/00110f3cfc9b34b2dfee2a6c9e55a0ae6df125ae - https://git.kernel.org/stable/c/3c3fac6bc0a9c00dbe65d8dc0d3a282afe4d3188
CVE ID: CVE-2025-40120 State: PUBLISHED Published: 2025-11-12T10:23:18.726Z Last Updated: 2025-11-12T10:23:18.726Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Prevent USB runtime PM (autosuspend) for AX88772* in bind. usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real
453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues. To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this a
count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides. Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before. References: - https://git.kernel.org/stable/c/71a0ba7fdaf8d035426912a4ed7bf1738a81010c - https://git.kernel.org/stable/c/3e96cd27ff1a004d84908c1b6cc68ac60913874e - https://git.kernel.org/stable/c/724a9db84188f80ef60b1f21cc7b4e9c84e0cb64 - https://git.kernel.org/stable/c/1534517300e12f2930b6ff477b8820ff658afd11 - https://git.kernel.org/stable/c/9d8bcaf6fae1bd82bc27ec09a2694497e6f6c4b4 - https://git.kernel.org/sta
7b8820ff658afd11 - https://git.kernel.org/stable/c/9d8bcaf6fae1bd82bc27ec09a2694497e6f6c4b4 - https://git.kernel.org/stable/c/3d3c4cd5c62f24bb3cb4511b7a95df707635e00a
CVE ID: CVE-2025-40121 State: PUBLISHED Published: 2025-11-12T10:23:19.000Z Last Updated: 2025-11-12T10:23:19.000Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping When an invalid value is passed via quirk option, currently bytcr_rt5640 driver just ignores and leaves as is, which may lead to unepxected results like OOB access. This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed. References: - https://git.kernel.org/stable/c/bff827b0d507e52b23efab9f67c232a4f037ab2c - https://git.kernel.org/stable/c/64a3
ences: - https://git.kernel.org/stable/c/bff827b0d507e52b23efab9f67c232a4f037ab2c - https://git.kernel.org/stable/c/64a36a7032082b4c330ce081acb6efb99246020e - https://git.kernel.org/stable/c/95e29db33b5f73218ae08ebb48c61c9a8d28e2ff - https://git.kernel.org/stable/c/2204e582b4eea872e1e7a5c90edcb84b928c68b0 - https://git.kernel.org/stable/c/f197894de2f4ef46c7d53827d9df294b75c35e13 - https://git.kernel.org/stable/c/fdf99978a6480e14405212472b6c747e0fa43bed - https://git.kernel.org/stable/c/c60f269c123210a6846d6d1367de0eaa402c10b0 - https://git.kernel.org/stable/c/4336efb59ef364e691ef829a73d9dbd4d5ed7c7b
CVE ID: CVE-2025-40122 State: PUBLISHED Published: 2025-11-12T10:23:19.271Z Last Updated: 2025-11-12T10:23:19.271Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix IA32_PMC_x_CFG_B MSRs access error When running perf_fuzzer on PTL, sometimes the below "unchecked MSR access error" is seen when accessing IA32_PMC_x_CFG_B MSRs. [ 55.611268] unchecked MSR access error: WRMSR to 0x1986 (tried to write 0x0000000200000001) at rIP: 0xffffffffac564b28 (native_write_msr+0x8/0x30) [ 55.611280] Call Trace: [ 55.611282] <TASK> [ 55.611284] ? intel_pmu_config_acr+0x87/0x160 [ 55.611289] intel_pmu_enable_acr+0x6d/0x80 [ 55.6
e: [ 55.611282] <TASK> [ 55.611284] ? intel_pmu_config_acr+0x87/0x160 [ 55.611289] intel_pmu_enable_acr+0x6d/0x80 [ 55.611291] intel_pmu_enable_event+0xce/0x460 [ 55.611293] x86_pmu_start+0x78/0xb0 [ 55.611297] x86_pmu_enable+0x218/0x3a0 [ 55.611300] ? x86_pmu_enable+0x121/0x3a0 [ 55.611302] perf_pmu_enable+0x40/0x50 [ 55.611307] ctx_resched+0x19d/0x220 [ 55.611309] __perf_install_in_context+0x284/0x2f0 [ 55.611311] ? __pfx_remote_function+0x10/0x10 [ 55.611314] remote_function+0x52/0x70 [ 55.611317] ? __pfx_remote_function+0x10/0x10 [ 55.611319] generic_exec_single+0x84/0x150 [ 55.611323] smp_call_function_single+0xc5/0x1a0 [ 55.611326] ? __pfx_remote_function+0x10/0x10 [ 55.611329] perf_in
150 [ 55.611323] smp_call_function_single+0xc5/0x1a0 [ 55.611326] ? __pfx_remote_function+0x10/0x10 [ 55.611329] perf_install_in_context+0xd1/0x1e0 [ 55.611331] ? __pfx___perf_install_in_context+0x10/0x10 [ 55.611333] __do_sys_perf_event_open+0xa76/0x1040 [ 55.611336] __x64_sys_perf_event_open+0x26/0x30 [ 55.611337] x64_sys_call+0x1d8e/0x20c0 [ 55.611339] do_syscall_64+0x4f/0x120 [ 55.611343] entry_SYSCALL_64_after_hwframe+0x76/0x7e On PTL, GP counter 0 and 1 doesn't support auto counter reload feature, thus it would trigger a #GP when trying to write 1 on bit 0 of CFG_B MSR which requires to enable auto counter reload on GP counter 0. The root cause of causing this issue is the check for au
R which requires to enable auto counter reload on GP counter 0. The root cause of causing this issue is the check for auto counter reload (ACR) counter mask from user space is incorrect in intel_pmu_acr_late_setup() helper. It leads to an invalid ACR counter mask from user space could be set into hw.config1 and then written into CFG_B MSRs and trigger the MSR access warning. e.g., User may create a perf event with ACR counter mask (config2=0xcb), and there is only 1 event created, so "cpuc->n_events" is 1. The correct check condition should be "i + idx >= cpuc->n_events" instead of "i + idx > cpuc->n_events" (it looks a typo). Otherwise, the counter mask would traverse twice and an invalid "
stead of "i + idx > cpuc->n_events" (it looks a typo). Otherwise, the counter mask would traverse twice and an invalid "cpuc->assign[1]" bit (bit 0) is set into hw.config1 and cause MSR accessing error. Besides, also check if the ACR counter mask corresponding events are ACR events. If not, filter out these counter mask. If a event is not a ACR event, it could be scheduled to an HW counter which doesn't support ACR. It's invalid to add their counter index in ACR counter mask. Furthermore, remove the WARN_ON_ONCE() since it's easily triggered as user could set any invalid ACR counter mask and the warning message could mislead users. References: - https://git.kernel.org/stable/c/c6cca4213b618c
R counter mask and the warning message could mislead users. References: - https://git.kernel.org/stable/c/c6cca4213b618c92e4972919ee568f0fb87313b1 - https://git.kernel.org/stable/c/43796f30507802d93ead2dc44fc9637f34671a89
CVE ID: CVE-2025-40123 State: PUBLISHED Published: 2025-11-12T10:23:19.589Z Last Updated: 2025-11-12T10:23:19.589Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() an
ct. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as soc
though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we
ust not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. References: - https://git.kernel.org/stable/c/a99de19128aec0913f3d529f529fbbff5edfaff8 - https://git.kernel.org/stable/c/08cb3dc9d2b44f153d0bcf2cb966e4a94b5d0f32 - https://git.kernel.org/stable/c/f856c598080ba7ce1252867b8ecd6ad5bdaf9a6a - https://git.kernel.org/stable/c/c1ad19b5d8e23123503dcaf2d4342e1b90b923ad -
/c/f856c598080ba7ce1252867b8ecd6ad5bdaf9a6a - https://git.kernel.org/stable/c/c1ad19b5d8e23123503dcaf2d4342e1b90b923ad - https://git.kernel.org/stable/c/4540aed51b12bc13364149bf95f6ecef013197c0
CVE ID: CVE-2025-40124 State: PUBLISHED Published: 2025-11-12T10:23:19.861Z Last Updated: 2025-11-12T10:23:19.861Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Anthony Yznaga tracked down that a BUG_ON in ext4 code with large folios enabled resulted from copy_from_user() returning impossibly large values greater than the size to be copied. This lead to __copy_from_iter() returning impossible values instead of the actual number of bytes it was able to copy. The BUG_ON has been reported in https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a
of bytes it was able to copy. The BUG_ON has been reported in https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. The exception handlers expect that %o2 has already been masked during the bulk copy loop, but the masking was performed after that loop. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. References: - https://gi