FKIE_CVE-2025-71095

Vulnerability from fkie_nvd - Published: 2026-01-13 16:16 - Updated: 2026-01-14 16:26
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix the crash issue for zero copy XDP_TX action There is a crash issue when running zero copy XDP_TX action, the crash log is shown below. [ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcache_clean_poc+0x20/0x38 (P) [ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0 [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400 [ 216.317701] __stmmac_xdp_run_prog+0x164/0x368 [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00 [ 216.326576] __napi_poll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt For XDP_TX action, the xdp_buff is converted to xdp_frame by xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame depends on the memory type of the xdp_buff. For page pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy XSK pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdp_buff memory type in stmmac_xdp_xmit_back() to fix this issue.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3f7823219407f2f18044c2b72366a48810c5c821
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/45ee0462b88396a0bd1df1991f801c89994ea72b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4d0ceb7677e1c4616afb96abb4518f70b65abb0d
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5e5988736a95b1de7f91b10ac2575454b70e4897
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a48e232210009be50591fdea8ba7c07b0f566a13
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix the crash issue for zero copy XDP_TX action\n\nThere is a crash issue when running zero copy XDP_TX action, the crash\nlog is shown below.\n\n[  216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000\n[  216.187524] Internal error: Oops: 0000000096000144 [#1]  SMP\n[  216.301694] Call trace:\n[  216.304130]  dcache_clean_poc+0x20/0x38 (P)\n[  216.308308]  __dma_sync_single_for_device+0x1bc/0x1e0\n[  216.313351]  stmmac_xdp_xmit_xdpf+0x354/0x400\n[  216.317701]  __stmmac_xdp_run_prog+0x164/0x368\n[  216.322139]  stmmac_napi_poll_rxtx+0xba8/0xf00\n[  216.326576]  __napi_poll+0x40/0x218\n[  216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt\n\nFor XDP_TX action, the xdp_buff is converted to xdp_frame by\nxdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame\ndepends on the memory type of the xdp_buff. For page pool based xdp_buff\nit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy\nXSK pool based xdp_buff it produces xdp_frame with memory type\nMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the\nmemory type and always uses the page pool type, this leads to invalid\nmappings and causes the crash. Therefore, check the xdp_buff memory type\nin stmmac_xdp_xmit_back() to fix this issue."
    }
  ],
  "id": "CVE-2025-71095",
  "lastModified": "2026-01-14T16:26:00.933",
  "metrics": {},
  "published": "2026-01-13T16:16:09.347",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3f7823219407f2f18044c2b72366a48810c5c821"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/45ee0462b88396a0bd1df1991f801c89994ea72b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4d0ceb7677e1c4616afb96abb4518f70b65abb0d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5e5988736a95b1de7f91b10ac2575454b70e4897"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a48e232210009be50591fdea8ba7c07b0f566a13"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.