CVE-2023-54012
Last modified
CVE-2023-54012 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. In 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.. EPSS estimates a 0.20% chance of exploitation in the next 30 days.
Description
In 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.
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= fd867d51f889aec11cca235ebb008578780d052d, < 9ea0c5f90a27b5b884d880e146e0f65f3052e401; >= fd867d51f889aec11cca235ebb008578780d052d, < 4bb955c4d2830a58c08e2a48ab75d75368e3ff36; >= fd867d51f889aec11cca235ebb008578780d052d, < cf3b5cd7127cc10c5b12400c545f263f0e5e715c; >= fd867d51f889aec11cca235ebb008578780d052d, < ed66e6327a69fec95034cda2ac5b6a57b8b3b622; >= fd867d51f889aec11cca235ebb008578780d052d, < 6bf00bb3dc7e5b9fb05488e11616e65d64e975fa; >= fd867d51f889aec11cca235ebb008578780d052d, < ae9b15fbe63447bc1d3bba3769f409d17ca6fdf6 |
| Linux | Linux | 4.4 |
References
Timeline
- Published
- Last Modified
- Status
- Deferred
Frequently Asked Questions
What is CVE-2023-54012?
How severe is CVE-2023-54012?
How do I fix CVE-2023-54012?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2023
- CVE-2023-54007In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54008In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54009In the Linux kernel, the following vulnerability has been re…
- CVE-2023-5401Server receiving a malformed message based on a using the sp…8.1
- CVE-2023-54010In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54011In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54013In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54014In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54015In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54016In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54017In the Linux kernel, the following vulnerability has been re…
- CVE-2023-54018In the Linux kernel, the following vulnerability has been re…
Are you affected by CVE-2023-54012?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
