Logo
-

Byte Open Security

(ByteOS Network)

Log In

Sign Up

ByteOS

Security
Vulnerability Details
Registries
Custom Views
Weaknesses
Attack Patterns
Filters & Tools
Vulnerability Details :

CVE-2026-43465

Summary
Assigner-Linux
Assigner Org ID-416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At-08 May, 2026 | 14:22
Updated At-11 May, 2026 | 22:25
Rejected At-
Credits

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. The issue was discovered by the drivers/net/xdp.py selftest, more specifically the test_xdp_native_tx_mb: - The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error. Resulting splat during the test: WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: <TASK> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70 The problem applies for XDP_PASS as well which is handled in a different code path in the driver. This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags.

Vendors
-
Not available
Products
-
Metrics (CVSS)
VersionBase scoreBase severityVector
Weaknesses
Attack Patterns
Solution/Workaround
References
HyperlinkResource Type
EPSS History
Score
Latest Score
-
N/A
No data available for selected date range
Percentile
Latest Percentile
-
N/A
No data available for selected date range
Stakeholder-Specific Vulnerability Categorization (SSVC)
â–¼Common Vulnerabilities and Exposures (CVE)
cve.org
Assigner:Linux
Assigner Org ID:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:08 May, 2026 | 14:22
Updated At:11 May, 2026 | 22:25
Rejected At:
â–¼CVE Numbering Authority (CNA)
net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. The issue was discovered by the drivers/net/xdp.py selftest, more specifically the test_xdp_native_tx_mb: - The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error. Resulting splat during the test: WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: <TASK> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70 The problem applies for XDP_PASS as well which is handled in a different code path in the driver. This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags.

Affected Products
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
Default Status
unaffected
Versions
Affected
  • From 87bcef158ac1faca1bd7e0104588e8e2956d10be before 7d7342a18fadcdb70a63b3c930dc63528ce51832 (git)
  • From 87bcef158ac1faca1bd7e0104588e8e2956d10be before 043bd62f748bc9fd98154037aa598cffbd3c667c (git)
  • From 87bcef158ac1faca1bd7e0104588e8e2956d10be before db25c42c2e1f9c0d136420fff5e5700f7e771a6f (git)
  • 8b051d7f530e8a5237da242fbeafef02fec6b813 (git)
  • cb9edd583e23979ee546981be963ad5f217e8b18 (git)
  • f2557d7fa38e9475b38588f5c124476091480f53 (git)
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
Default Status
affected
Versions
Affected
  • 6.18
Unaffected
  • From 0 before 6.18 (semver)
  • From 6.18.19 through 6.18.* (semver)
  • From 6.19.9 through 6.19.* (semver)
  • From 7.0 through * (original_commit_for_fix)
Metrics
VersionBase scoreBase severityVector
3.19.8CRITICAL
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Version: 3.1
Base score: 9.8
Base severity: CRITICAL
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions

Configurations

Workarounds

Exploits

Credits

Timeline
EventDate
Replaced By

Rejected Reason

References
HyperlinkResource
https://git.kernel.org/stable/c/7d7342a18fadcdb70a63b3c930dc63528ce51832
N/A
https://git.kernel.org/stable/c/043bd62f748bc9fd98154037aa598cffbd3c667c
N/A
https://git.kernel.org/stable/c/db25c42c2e1f9c0d136420fff5e5700f7e771a6f
N/A
Hyperlink: https://git.kernel.org/stable/c/7d7342a18fadcdb70a63b3c930dc63528ce51832
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/043bd62f748bc9fd98154037aa598cffbd3c667c
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/db25c42c2e1f9c0d136420fff5e5700f7e771a6f
Resource: N/A
Information is not available yet
â–¼National Vulnerability Database (NVD)
nvd.nist.gov
Source:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:08 May, 2026 | 15:16
Updated At:12 May, 2026 | 14:10

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. The issue was discovered by the drivers/net/xdp.py selftest, more specifically the test_xdp_native_tx_mb: - The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error. Resulting splat during the test: WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: <TASK> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70 The problem applies for XDP_PASS as well which is handled in a different code path in the driver. This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags.

CISA Catalog
Date AddedDue DateVulnerability NameRequired Action
N/A
Date Added: N/A
Due Date: N/A
Vulnerability Name: N/A
Required Action: N/A
Metrics
TypeVersionBase scoreBase severityVector
Secondary3.19.8CRITICAL
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Type: Secondary
Version: 3.1
Base score: 9.8
Base severity: CRITICAL
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CPE Matches

Evaluator Description

Evaluator Impact

Evaluator Solution

Vendor Statements

References
HyperlinkSourceResource
https://git.kernel.org/stable/c/043bd62f748bc9fd98154037aa598cffbd3c667c416baaa9-dc9f-4396-8d5f-8c081fb06d67
N/A
https://git.kernel.org/stable/c/7d7342a18fadcdb70a63b3c930dc63528ce51832416baaa9-dc9f-4396-8d5f-8c081fb06d67
N/A
https://git.kernel.org/stable/c/db25c42c2e1f9c0d136420fff5e5700f7e771a6f416baaa9-dc9f-4396-8d5f-8c081fb06d67
N/A
Hyperlink: https://git.kernel.org/stable/c/043bd62f748bc9fd98154037aa598cffbd3c667c
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/7d7342a18fadcdb70a63b3c930dc63528ce51832
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/db25c42c2e1f9c0d136420fff5e5700f7e771a6f
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource: N/A

Change History

0
Information is not available yet

Similar CVEs

59Records found

CVE-2024-42256
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.09% / 25.97%
||
7 Day CHG~0.00%
Published-08 Aug, 2024 | 08:49
Updated-11 May, 2026 | 20:28
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
cifs: Fix server re-repick on subrequest retry

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix server re-repick on subrequest retry When a subrequest is marked for needing retry, netfs will call cifs_prepare_write() which will make cifs repick the server for the op before renegotiating credits; it then calls cifs_issue_write() which invokes smb2_async_writev() - which re-repicks the server. If a different server is then selected, this causes the increment of server->in_flight to happen against one record and the decrement to happen against another, leading to misaccounting. Fix this by just removing the repick code in smb2_async_writev(). As this is only called from netfslib-driven code, cifs_prepare_write() should always have been called first, and so server should never be NULL and the preparatory step is repeated in the event that we do a retry. The problem manifests as a warning looking something like: WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Which may be triggered by a number of different xfstests running against an Azure server in multichannel mode. generic/249 seems the most repeatable, but generic/215, generic/249 and generic/308 may also show it.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2024-38612
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.18% / 39.42%
||
7 Day CHG+0.02%
Published-19 Jun, 2024 | 13:56
Updated-12 May, 2026 | 12:16
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ipv6: sr: fix invalid unregister error path

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path.

Action-Not Available
Vendor-Siemens AGLinux Kernel Organization, Inc
Product-linux_kernelLinuxSIPLUS S7-1500 CPU 1518-4 PN/DP MFPRUGGEDCOM RST2428PSIMATIC S7-1500 CPU 1518F-4 PN/DP MFPSIMATIC S7-1500 CPU 1518-4 PN/DP MFPSCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 familySCALANCE XCM-/XRM-/XCH-/XRH-300 familyacrnSIMATIC S7-1500 TM MFP - GNU/Linux subsystemlinux_kernel
CWE ID-CWE-416
Use After Free
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2024-38541
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.11% / 29.11%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 13:35
Updated-11 May, 2026 | 20:18
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
of: module: add buffer overflow check in of_modalias()

In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinuxlinux_kernel
CWE ID-CWE-120
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CVE-2024-39462
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.11% / 28.28%
||
7 Day CHG~0.00%
Published-25 Jun, 2024 | 14:25
Updated-11 May, 2026 | 20:21
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
clk: bcm: dvp: Assign ->num before accessing ->hws

In the Linux kernel, the following vulnerability has been resolved: clk: bcm: dvp: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in clk_dvp_probe() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinuxlinux_kernel
CWE ID-CWE-400
Uncontrolled Resource Consumption
CVE-2024-38623
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.25% / 48.12%
||
7 Day CHG~0.00%
Published-21 Jun, 2024 | 10:18
Updated-11 May, 2026 | 20:20
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
fs/ntfs3: Use variable length array instead of fixed size

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use variable length array instead of fixed size Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinuxlinux_kernel
CWE ID-CWE-129
Improper Validation of Array Index
CVE-2024-36031
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.04% / 11.23%
||
7 Day CHG~0.00%
Published-30 May, 2024 | 15:23
Updated-11 May, 2026 | 20:15
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
keys: Fix overwrite of key expiration on instantiation

In the Linux kernel, the following vulnerability has been resolved: keys: Fix overwrite of key expiration on instantiation The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinuxlinux_kernel
CWE ID-CWE-324
Use of a Key Past its Expiration Date
CVE-2025-39946
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.03% / 9.91%
||
7 Day CHG~0.00%
Published-04 Oct, 2025 | 07:31
Updated-11 May, 2026 | 21:39
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
tls: make sure to abort the stream if headers are bogus

In the Linux kernel, the following vulnerability has been resolved: tls: make sure to abort the stream if headers are bogus Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space. Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send. Make sure that tls_rx_msg_size() aborts strp, if we reach an invalid record there's really no way to recover.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2022-48716
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.11% / 28.16%
||
7 Day CHG~0.00%
Published-20 Jun, 2024 | 11:13
Updated-11 May, 2026 | 18:45
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ASoC: codecs: wcd938x: fix incorrect used of portid

In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd938x: fix incorrect used of portid Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chan_info array. So fix this. Without this, its possible that we could corrupt struct wcd938x_sdw_priv by accessing port_map array out of range with channel id instead of port id.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinuxlinux_kernel
CWE ID-CWE-400
Uncontrolled Resource Consumption
CVE-2026-43341
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-9.8||CRITICAL
EPSS-0.07% / 21.78%
||
7 Day CHG+0.05%
Published-08 May, 2026 | 13:37
Updated-15 May, 2026 | 19:45
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/ipv6: ioam6: prevent schema length wraparound in trace fill

In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
  • Previous
  • 1
  • 2
  • Next
Details not found