{
  "public_date" : "2026-05-28T00:00:00Z",
  "bugzilla" : {
    "description" : "kernel: net: stmmac: Prevent NULL deref when RX memory exhausted",
    "id" : "2482596",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2482596"
  },
  "cwe" : "CWE-476",
  "details" : [ "In the Linux kernel, the following vulnerability has been resolved:\nnet: stmmac: Prevent NULL deref when RX memory exhausted\nThe CPU receives frames from the MAC through conventional DMA: the CPU\nallocates buffers for the MAC, then the MAC fills them and returns\nownership to the CPU. For each hardware RX queue, the CPU and MAC\ncoordinate through a shared ring array of DMA descriptors: one\ndescriptor per DMA buffer. Each descriptor includes the buffer's\nphysical address and a status flag (\"OWN\") indicating which side owns\nthe buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set\nthe flag and the MAC is only allowed to clear it, and both must move\nthrough the ring in sequence: thus the ring is used for both\n\"submissions\" and \"completions.\"\nIn the stmmac driver, stmmac_rx() bookmarks its position in the ring\nwith the `cur_rx` index. The main receive loop in that function checks\nfor rx_descs[cur_rx].own=0, gives the corresponding buffer to the\nnetwork stack (NULLing the pointer), and increments `cur_rx` modulo the\nring size. After the loop exits, stmmac_rx_refill(), which bookmarks its\nposition with `dirty_rx`, allocates fresh buffers and rearms the\ndescriptors (setting OWN=1). If it fails any allocation, it simply stops\nearly (leaving OWN=0) and will retry where it left off when next called.\nThis means descriptors have a three-stage lifecycle (terms my own):\n- `empty` (OWN=1, buffer valid)\n- `full` (OWN=0, buffer valid and populated)\n- `dirty` (OWN=0, buffer NULL)\nBut because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In\nthe past (see 'Fixes:'), there was a bug where the loop could cycle\n`cur_rx` all the way back to the first descriptor it dirtied, resulting\nin a NULL dereference when mistaken for `full`. The aforementioned\ncommit resolved that *specific* failure by capping the loop's iteration\nlimit at `dma_rx_size - 1`, but this is only a partial fix: if the\nprevious stmmac_rx_refill() didn't complete, then there are leftover\n`dirty` descriptors that the loop might encounter without needing to\ncycle fully around. The current code therefore panics (see 'Closes:')\nwhen stmmac_rx_refill() is memory-starved long enough for `cur_rx` to\ncatch up to `dirty_rx`.\nFix this by explicitly checking, before advancing `cur_rx`, if the next\nentry is dirty; exit the loop if so. This prevents processing of the\nfinal, used descriptor until stmmac_rx_refill() succeeds, but\nfully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix\nintended: so remove the clamp as well. Since stmmac_rx_zc() is a\ncopy-paste-and-tweak of stmmac_rx() and the code structure is identical,\nany fix to stmmac_rx() will also need a corresponding fix for\nstmmac_rx_zc(). Therefore, apply the same check there.\nIn stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the\nMAC sets OWN=0 on the final descriptor, it will be unable to send any\nfurther DMA-complete IRQs until it's given more `empty` descriptors.\nCurrently, the driver simply *hopes* that the next stmmac_rx_refill()\nsucceeds, risking an indefinite stall of the receive process if not. But\nthis is not a regression, so it can be addressed in a future change.", "A flaw was found in the Linux kernel's `stmmac` driver. When the system experiences receive (RX) memory exhaustion, the `stmmac_rx()` function can misinterpret already-processed data descriptors as valid, leading to a NULL pointer dereference. This vulnerability can cause the system to panic, resulting in a Denial of Service (DoS)." ],
  "package_state" : [ {
    "product_name" : "Red Hat Enterprise Linux 10",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:10"
  }, {
    "product_name" : "Red Hat Enterprise Linux 6",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:6"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2026-46110\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-46110\nhttps://lore.kernel.org/linux-cve-announce/2026052812-CVE-2026-46110-9346@gregkh/T" ],
  "name" : "CVE-2026-46110",
  "csaw" : false
}