GHSA-2VMP-Q8V6-7QC9
Vulnerability from github – Published: 2025-12-24 12:30 – Updated: 2025-12-24 12:30In the Linux kernel, the following vulnerability has been resolved:
net: fix stack overflow when LRO is disabled for virtual interfaces
When the virtual interface's feature is updated, it synchronizes the updated feature for its own lower interface. This propagation logic should be worked as the iteration, not recursively. But it works recursively due to the netdev notification unexpectedly. This problem occurs when it disables LRO only for the team and bonding interface type.
team0
|
+------+------+-----+-----+ | | | | | team1 team2 team3 ... team200
If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE event to its own lower interfaces(team1 ~ team200). It is worked by netdev_sync_lower_features(). So, the NETDEV_FEAT_CHANGE notification logic of each lower interface work iteratively. But generated NETDEV_FEAT_CHANGE event is also sent to the upper interface too. upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own lower interfaces again. lower and upper interfaces receive this event and generate this event again and again. So, the stack overflow occurs.
But it is not the infinite loop issue. Because the netdev_sync_lower_features() updates features before generating the NETDEV_FEAT_CHANGE event. Already synchronized lower interfaces skip notification logic. So, it is just the problem that iteration logic is changed to the recursive unexpectedly due to the notification mechanism.
Reproducer:
ip link add team0 type team ethtool -K team0 lro on for i in {1..200} do ip link add team$i master team0 type team ethtool -K team$i lro on done
ethtool -K team0 lro off
In order to fix it, the notifier_ctx member of bonding/team is introduced.
{
"affected": [],
"aliases": [
"CVE-2023-54012"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-24T11:15:54Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix stack overflow when LRO is disabled for virtual interfaces\n\nWhen the virtual interface\u0027s feature is updated, it synchronizes the\nupdated feature for its own lower interface.\nThis propagation logic should be worked as the iteration, not recursively.\nBut it works recursively due to the netdev notification unexpectedly.\nThis problem occurs when it disables LRO only for the team and bonding\ninterface type.\n\n team0\n |\n +------+------+-----+-----+\n | | | | |\nteam1 team2 team3 ... team200\n\nIf team0\u0027s LRO feature is updated, it generates the NETDEV_FEAT_CHANGE\nevent to its own lower interfaces(team1 ~ team200).\nIt is worked by netdev_sync_lower_features().\nSo, the NETDEV_FEAT_CHANGE notification logic of each lower interface\nwork iteratively.\nBut generated NETDEV_FEAT_CHANGE event is also sent to the upper\ninterface too.\nupper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own\nlower interfaces again.\nlower and upper interfaces receive this event and generate this\nevent again and again.\nSo, the stack overflow occurs.\n\nBut it is not the infinite loop issue.\nBecause the netdev_sync_lower_features() updates features before\ngenerating the NETDEV_FEAT_CHANGE event.\nAlready synchronized lower interfaces skip notification logic.\nSo, it is just the problem that iteration logic is changed to the\nrecursive unexpectedly due to the notification mechanism.\n\nReproducer:\n\nip link add team0 type team\nethtool -K team0 lro on\nfor i in {1..200}\ndo\n ip link add team$i master team0 type team\n ethtool -K team$i lro on\ndone\n\nethtool -K team0 lro off\n\nIn order to fix it, the notifier_ctx member of bonding/team is introduced.",
"id": "GHSA-2vmp-q8v6-7qc9",
"modified": "2025-12-24T12:30:27Z",
"published": "2025-12-24T12:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bb955c4d2830a58c08e2a48ab75d75368e3ff36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bf00bb3dc7e5b9fb05488e11616e65d64e975fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ea0c5f90a27b5b884d880e146e0f65f3052e401"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae9b15fbe63447bc1d3bba3769f409d17ca6fdf6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf3b5cd7127cc10c5b12400c545f263f0e5e715c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed66e6327a69fec95034cda2ac5b6a57b8b3b622"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.