CVE-2023-53107: veth: Fix use after free in XDP_REDIRECT
In the Linux kernel, the following vulnerability has been resolved:
veth: Fix use after free in XDPREDIRECT
Commit 718a18a0c8a6 ("veth: Rework vethxdprcvskb in order to accept non-linear skb") introduced a bug where it tried to use pskbexpandhead() if the headroom was less than XDPPACKETHEADROOM. This however uses kmalloc to expand the head, which will later allow consumeskb() to free the skb while is it still in use by AFXDP.
Previously if the headroom was less than XDPPACKETHEADROOM we continued on to allocate a new skb from pages so this restores that behavior.
BUG: KASAN: use-after-free in xskrcv+0x18d/0x2c0 Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640
CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G O 6.1.4-cloudflare-kasan-2023.1.2 #1 Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S3B10.03 06/21/2018 Call Trace: <TASK> dumpstacklvl+0x34/0x48 printreport+0x170/0x473 ? xskrcv+0x18d/0x2c0 kasanreport+0xad/0x130 ? xskrcv+0x18d/0x2c0 kasancheckrange+0x149/0x1a0 memcpy+0x20/0x60 xskrcv+0x18d/0x2c0 xskmapredirect+0x1f3/0x490 ? vethxdprcvskb+0x89c/0x1ba0 [veth] xdpdoredirect+0x5ca/0xd60 vethxdprcvskb+0x935/0x1ba0 [veth] ? netifreceiveskblistcore+0x671/0x920 ? vethxdp+0x670/0x670 [veth] vethxdprcv+0x304/0xa20 [veth] ? doxdpgeneric+0x150/0x150 ? vethxdprcvone+0xde0/0xde0 [veth] ? rawspinlockbh+0xe0/0xe0 ? newidlebalance+0x887/0xe30 ? perfeventtaskschedin+0xdb/0x800 vethpoll+0x139/0x571 [veth] ? vethxdprcv+0xa20/0xa20 [veth] ? rawspinunlock+0x39/0x70 ? finishtaskswitch.isra.0+0x17e/0x7d0 ? switchto+0x5cf/0x1070 ? schedule+0x95b/0x2640 ? ioscheduletimeout+0x160/0x160 napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 ? napipoll+0x440/0x440 ? kthreadparkme+0xc6/0x1f0 ? napipoll+0x440/0x440 kthread+0x2a2/0x340 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK>
Freed by task 148640: kasansavestack+0x23/0x50 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 kasanslabfree+0x169/0x1d0 slabfreefreelisthook+0xd2/0x190 kmemcachefree+0x1a1/0x2f0 skbreleasedata+0x449/0x600 consumeskb+0x9f/0x1c0 vethxdprcvskb+0x89c/0x1ba0 [veth] vethxdprcv+0x304/0xa20 [veth] vethpoll+0x139/0x571 [veth] napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 kthread+0x2a2/0x340 retfromfork+0x22/0x30
The buggy address belongs to the object at ffff888976250000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 340 bytes inside of 2048-byte region [ffff888976250000, ffff888976250800)
The buggy address belongs to the physical page: page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250 head:00000000ae18262a order:3 compoundmapcount:0 compoundpincount:0 flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff) raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00 raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb <span class="quote">> ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb</span> ^ ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Other sources
In the Linux kernel, the following vulnerability has been resolved:
veth: Fix use after free in XDPREDIRECT
Commit 718a18a0c8a6 ("veth: Rework vethxdprcvskb in order to accept non-linear skb") introduced a bug where it tried to use pskbexpandhead() if the headroom was less than XDPPACKETHEADROOM. This however uses kmalloc to expand the head, which will later allow consumeskb() to free the skb while is it still in use by AFXDP.
Previously if the headroom was less than XDPPACKETHEADROOM we continued on to allocate a new skb from pages so this restores that behavior.
BUG: KASAN: use-after-free in xskrcv+0x18d/0x2c0 Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640
CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G O 6.1.4-cloudflare-kasan-2023.1.2 #1 Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S3B10.03 06/21/2018 Call Trace: <TASK> dumpstacklvl+0x34/0x48 printreport+0x170/0x473 ? xskrcv+0x18d/0x2c0 kasanreport+0xad/0x130 ? xskrcv+0x18d/0x2c0 kasancheckrange+0x149/0x1a0 memcpy+0x20/0x60 xskrcv+0x18d/0x2c0 xskmapredirect+0x1f3/0x490 ? vethxdprcvskb+0x89c/0x1ba0 [veth] xdpdoredirect+0x5ca/0xd60 vethxdprcvskb+0x935/0x1ba0 [veth] ? netifreceiveskblistcore+0x671/0x920 ? vethxdp+0x670/0x670 [veth] vethxdprcv+0x304/0xa20 [veth] ? doxdpgeneric+0x150/0x150 ? vethxdprcvone+0xde0/0xde0 [veth] ? rawspinlockbh+0xe0/0xe0 ? newidlebalance+0x887/0xe30 ? perfeventtaskschedin+0xdb/0x800 vethpoll+0x139/0x571 [veth] ? vethxdprcv+0xa20/0xa20 [veth] ? rawspinunlock+0x39/0x70 ? finishtaskswitch.isra.0+0x17e/0x7d0 ? switchto+0x5cf/0x1070 ? schedule+0x95b/0x2640 ? ioscheduletimeout+0x160/0x160 napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 ? napipoll+0x440/0x440 ? kthreadparkme+0xc6/0x1f0 ? napipoll+0x440/0x440 kthread+0x2a2/0x340 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK>
Freed by task 148640: kasansavestack+0x23/0x50 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 kasanslabfree+0x169/0x1d0 slabfreefreelisthook+0xd2/0x190 kmemcachefree+0x1a1/0x2f0 skbreleasedata+0x449/0x600 consumeskb+0x9f/0x1c0 vethxdprcvskb+0x89c/0x1ba0 [veth] vethxdprcv+0x304/0xa20 [veth] vethpoll+0x139/0x571 [veth] napipoll+0xa1/0x440 napithreadedpoll+0x3d1/0x460 kthread+0x2a2/0x340 retfromfork+0x22/0x30
The buggy address belongs to the object at ffff888976250000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 340 bytes inside of 2048-byte region [ffff888976250000, ffff888976250800)
The buggy address belongs to the physical page: page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250 head:00000000ae18262a order:3 compoundmapcount:0 compoundpincount:0 flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff) raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00 raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (veth: Fix use after free in XDP_REDIRECT)to a version that resolves this vulnerability.Patch 718a18a0c8a6
Event History
Frequently Asked Questions
What is the severity of CVE-2023-53107?
CVE-2023-53107 has a high severity rating due to its potential for exploitation leading to denial of service.
How do I fix CVE-2023-53107?
To fix CVE-2023-53107, update your Linux kernel to the latest version provided by your distribution.
What is the impact of CVE-2023-53107?
The impact of CVE-2023-53107 includes possible denial of service due to a use-after-free vulnerability in the veth network driver.
Which versions of the Linux kernel are affected by CVE-2023-53107?
CVE-2023-53107 affects multiple versions of the Linux kernel that include commit 718a18a0c8a6.
How can I determine if my system is vulnerable to CVE-2023-53107?
You can determine if your system is vulnerable to CVE-2023-53107 by checking the kernel version against the vulnerability's known affected versions.