GHSA-VCMQ-H7G2-2M6J

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-19 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

bonding: refuse to enslave CAN devices

syzbot reported a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The crash occurs because a virtual CAN device (vxcan) is being enslaved to a bonding master.

During the enslavement process, the bonding driver mutates and modifies the network device states to fit an Ethernet-like aggregation model. However, CAN devices operate on a completely different Layer 2 architecture, relying on the CAN mid-layer private data structure (can_ml_priv) instead of standard Ethernet structures. Since bonding does not initialize or maintain these CAN structures, subsequent operations on the half-enslaved interface (such as closing associated sockets via isotp_release) lead to a null-pointer dereference when accessing the CAN receiver lists.

Bonding CAN interfaces is architecturally invalid as CAN lacks MAC addresses, ARP capabilities, and standard Ethernet link-layer mechanisms. While generic loopback devices are blocked globally in net/core/dev.c, virtual CAN devices bypass this check because they do not carry the IFF_LOOPBACK flag, despite acting as local software-loopbacks.

Fix this by explicitly blocking network devices of type ARPHRD_CAN from being enslaved at the very beginning of bond_enslave(). This prevents illegal state mutations, eliminates the resulting KASAN crashes, and avoids potential memory leaks from incomplete socket cleanups.

As the CAN support has been added a long time after bonding the Fixes-tag points to the introduction of ARPHRD_CAN that would have needed a specific handling in bonding_main.c.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-63990"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:18Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: refuse to enslave CAN devices\n\nsyzbot reported a kernel paging request crash in\ncan_rx_unregister() inside net/can/af_can.c. The crash occurs\nbecause a virtual CAN device (vxcan) is being enslaved to a\nbonding master.\n\nDuring the enslavement process, the bonding driver mutates\nand modifies the network device states to fit an Ethernet-like\naggregation model. However, CAN devices operate on a completely\ndifferent Layer 2 architecture, relying on the CAN mid-layer\nprivate data structure (can_ml_priv) instead of standard\nEthernet structures. Since bonding does not initialize or\nmaintain these CAN structures, subsequent operations on the\nhalf-enslaved interface (such as closing associated sockets\nvia isotp_release) lead to a null-pointer dereference when\naccessing the CAN receiver lists.\n\nBonding CAN interfaces is architecturally invalid as CAN lacks\nMAC addresses, ARP capabilities, and standard Ethernet\nlink-layer mechanisms. While generic loopback devices are\nblocked globally in net/core/dev.c, virtual CAN devices\nbypass this check because they do not carry the IFF_LOOPBACK\nflag, despite acting as local software-loopbacks.\n\nFix this by explicitly blocking network devices of type\nARPHRD_CAN from being enslaved at the very beginning of\nbond_enslave(). This prevents illegal state mutations,\neliminates the resulting KASAN crashes, and avoids potential\nmemory leaks from incomplete socket cleanups.\n\nAs the CAN support has been added a long time after bonding\nthe Fixes-tag points to the introduction of ARPHRD_CAN that\nwould have needed a specific handling in bonding_main.c.",
  "id": "GHSA-vcmq-h7g2-2m6j",
  "modified": "2026-07-19T18:31:48Z",
  "published": "2026-07-19T18:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63990"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/02f1c87ded33b43d48b4a1d665da15f2157b30d8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/41e8478c4cd896d3abbe33d41afc90c84ac66602"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/563090e5d450c665f70d955a39f9587afc7842eb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/69b78b5f3033272e53a2dc2dad675962654a5b38"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ba68464e4787b6a7ec938826e16124df20fd23d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ea8a648d9120f7652bcde1ce2c4ad66871af707"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f4d78a81f57df82e9d82a2c07471fed1a1235893"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.