FKIE_CVE-2023-53426

Vulnerability from fkie_nvd - Published: 2025-09-18 16:15 - Updated: 2025-09-19 16:00
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix xsk_diag use-after-free error during socket cleanup Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND. The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic's netlink operation.
Impacted products
Vendor Product Version

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix xsk_diag use-after-free error during socket cleanup\n\nFix a use-after-free error that is possible if the xsk_diag interface\nis used after the socket has been unbound from the device. This can\nhappen either due to the socket being closed or the device\ndisappearing. In the early days of AF_XDP, the way we tested that a\nsocket was not bound to a device was to simply check if the netdevice\npointer in the xsk socket structure was NULL. Later, a better system\nwas introduced by having an explicit state variable in the xsk socket\nstruct. For example, the state of a socket that is on the way to being\nclosed and has been unbound from the device is XSK_UNBOUND.\n\nThe commit in the Fixes tag below deleted the old way of signalling\nthat a socket is unbound, setting dev to NULL. This in the belief that\nall code using the old way had been exterminated. That was\nunfortunately not true as the xsk diagnostics code was still using the\nold way and thus does not work as intended when a socket is going\ndown. Fix this by introducing a test against the state variable. If\nthe socket is in the state XSK_UNBOUND, simply abort the diagnostic\u0027s\nnetlink operation."
    }
  ],
  "id": "CVE-2023-53426",
  "lastModified": "2025-09-19T16:00:27.847",
  "metrics": {},
  "published": "2025-09-18T16:15:46.490",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3e019d8a05a38abb5c85d4f1e85fda964610aa14"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/595931912357fa3507e522a7f8a0a76e423c23e4"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5979985f2d6b565b6cf0f79a62670a2855c0e96c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6436973164ea5506a495f39e56be5aea375e7832"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…