CyberSecBulletin
CVE-2026-46110NVD status: Undergoing Analysis

Linux: NULL Pointer Dereference

Published Updated By the CyberSecBulletin desk

CVE-2026-46110 is a high-severity NULL pointer dereference vulnerability in Linux, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions fdeb95b1fc7de25c9362990efb9996a8d761055c, e1c50b273298c7cd9b08b113e7a7598b531a02f5, 5c910f7708e3c507b037ca91ca5b09f8cfe71e65 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.51% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to fdeb95b1fc7de25c9362990efb9996a8d761055c or e1c50b273298c7cd9b08b113e7a7598b531a02f5 or 5c910f7708e3c507b037ca91ca5b09f8cfe71e65 or 4af2e62cbcda575a174acd230c3f3a208135e16d, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.1.176 or 6.6 or 6.6.140 or 6.12.88, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux7414a28de1b3b028714859078c00a874f9feff52 up to, but not including, fdeb95b1fc7de25c9362990efb9996a8d761055c; 779334e59850f863bf34665e0ff0b6faf126873b up to, but not including, e1c50b273298c7cd9b08b113e7a7598b531a02f5; b6cb4541853c7ee512111b0e7ddf3cb66c99c137 up to, but not including, 5c910f7708e3c507b037ca91ca5b09f8cfe71e65; b6cb4541853c7ee512111b0e7ddf3cb66c99c137 up to, but not including, 4af2e62cbcda575a174acd230c3f3a208135e16d; b6cb4541853c7ee512111b0e7ddf3cb66c99c137 up to, but not including, 950cb436165aad0f8f2cd49da3cd07677465bcde; b6cb4541853c7ee512111b0e7ddf3cb66c99c137 up to, but not including, 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8; b435b4573240b5530830a1a60e005c6fcfd928a0; 6.1.64 up to, but not including, 6.1.176; and 3 more rangesfdeb95b1fc7de25c9362990efb9996a8d761055c, e1c50b273298c7cd9b08b113e7a7598b531a02f5, 5c910f7708e3c507b037ca91ca5b09f8cfe71e65, 4af2e62cbcda575a174acd230c3f3a208135e16d, 950cb436165aad0f8f2cd49da3cd07677465bcde, 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8
SiemensSIMATIC S7-1500 TM MFP - GNU/Linux subsystemall versionsNot stated
LinuxLinux Kernel6.1.64 up to, but not including, 6.1.176; 6.5.13 up to, but not including, 6.6; 6.6.3 up to, but not including, 6.6.140; 6.7.1 up to, but not including, 6.12.88; 6.13 up to, but not including, 6.18.30; 6.19 up to, but not including, 7.0.7; 6.7; 7.16.1.176, 6.6, 6.6.140, 6.12.88, 6.18.30, 7.0.7

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
NoneNo data is disclosed.
Integrity
NoneNothing can be modified.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: NULL Pointer Dereference

The product dereferences a pointer that it expects to be valid but is NULL.

How developers prevent this class of flaw

  • For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished.
  • Select a programming language that is not susceptible to these issues.
  • Check the results of all functions that return a value and verify that the value is non-null before acting upon it.

More NULL Pointer Dereference vulnerabilities (CWE-476)

Timeline

  1. CVE record published.
  2. Record last changed materially (score, affected products, status or references).

References

Recent NULL Pointer Dereference vulnerabilities

Spotted an error? Tell us.