CVE-2025-68301: net: atlantic: fix fragment overflow handling in RX path
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix fragment overflow handling in RX path
The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.
The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKBFRAGS fragments, the fragment index exceeds the array bounds.
Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.
This crash occurred in production with an Aquantia AQC113 10G NIC.
Stack trace from production environment: RIP: 0010:skbaddrxfragnetmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: <IRQ> aqringrxclean+0x175/0xe60 [atlantic] ? aqringrxclean+0x14d/0xe60 [atlantic] ? aqringtxclean+0xdf/0x190 [atlantic] ? kmemcachefree+0x348/0x450 ? aqvecpoll+0x81/0x1d0 [atlantic] ? napipoll+0x28/0x1c0 ? netrxaction+0x337/0x420
Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.
Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix fragment overflow handling in RX path
The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.
The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKBFRAGS fragments, the fragment index exceeds the array bounds.
Fix by assuming there will be an extra frag if buff-len AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.
This crash occurred in production with an Aquantia AQC113 10G NIC.
Stack trace from production environment: RIP: 0010:skbaddrxfragnetmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 48 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: IRQ aqringrxclean+0x175/0xe60 [atlantic] ? aqringrxclean+0x14d/0xe60 [atlantic] ? aqringtxclean+0xdf/0x190 [atlantic] ? kmemcachefree+0x348/0x450 ? aqvecpoll+0x81/0x1d0 [atlantic] ? napipoll+0x28/0x1c0 ? netrxaction+0x337/0x420
Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.
Changes in v3: - Fix by assuming there will be an extra frag if buff-len AQCFGRXHDRSIZE, then all fragments are accounted for.
— IBM
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the RX clean/poll path for the atlantic driver, add/adjust the logic so the code prevents fragment overflow earlier—before calling skb_add_rx_frag()—when handling large multi-descriptor packets. Ensure the total number of fragments is checked against MAX_SKB_FRAGS (17) so the fragment index cannot exceed array bounds.
Linux kernel (atlantic network driver) skb_add_rx_frag_netmem fragment overflow handling (RX path) = Add an early check to prevent out-of-bounds fragment index when total fragments exceed MAX_SKB_FRAGS (17) - Configuration
Update the atlantic RX path to handle the case where there may be an extra fragment by assuming an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE (as described in the provided text). Reuse the existing check logic for fragment accounting in skb_add_rx_frag_netmem().
Linux kernel (atlantic network driver) Fragment sizing assumption for RX header buffering = Assume an extra frag when buff->len > AQ_CFG_RX_HDR_SIZE (and equivalent buffer-length checks)
Event History
Frequently Asked Questions
What is the severity of CVE-2025-68301?
CVE-2025-68301 has been classified as a potentially high-severity vulnerability due to its impact on memory management in the Linux kernel.
How do I fix CVE-2025-68301?
To fix CVE-2025-68301, update your Linux kernel to the latest version where the vulnerability has been patched.
What systems are affected by CVE-2025-68301?
CVE-2025-68301 affects systems using the Atlantic driver in the Linux kernel that handle large multi-descriptor packets.
What type of vulnerability is CVE-2025-68301?
CVE-2025-68301 is a memory management vulnerability that can result in out-of-bounds memory access.
Is CVE-2025-68301 actively being exploited?
As of the latest updates, there is no reported active exploitation of CVE-2025-68301, but it is crucial to apply patches to mitigate risks.