CVE-2023-53107

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: Fix use after free in XDP_REDIRECT<br /> <br /> Commit 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order<br /> to accept non-linear skb") introduced a bug where it tried to<br /> use pskb_expand_head() if the headroom was less than<br /> XDP_PACKET_HEADROOM. This however uses kmalloc to expand the head,<br /> which will later allow consume_skb() to free the skb while is it still<br /> in use by AF_XDP.<br /> <br /> Previously if the headroom was less than XDP_PACKET_HEADROOM we<br /> continued on to allocate a new skb from pages so this restores that<br /> behavior.<br /> <br /> BUG: KASAN: use-after-free in __xsk_rcv+0x18d/0x2c0<br /> Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640<br /> <br /> CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G O 6.1.4-cloudflare-kasan-2023.1.2 #1<br /> Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S_3B10.03 06/21/2018<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x48<br /> print_report+0x170/0x473<br /> ? __xsk_rcv+0x18d/0x2c0<br /> kasan_report+0xad/0x130<br /> ? __xsk_rcv+0x18d/0x2c0<br /> kasan_check_range+0x149/0x1a0<br /> memcpy+0x20/0x60<br /> __xsk_rcv+0x18d/0x2c0<br /> __xsk_map_redirect+0x1f3/0x490<br /> ? veth_xdp_rcv_skb+0x89c/0x1ba0 [veth]<br /> xdp_do_redirect+0x5ca/0xd60<br /> veth_xdp_rcv_skb+0x935/0x1ba0 [veth]<br /> ? __netif_receive_skb_list_core+0x671/0x920<br /> ? veth_xdp+0x670/0x670 [veth]<br /> veth_xdp_rcv+0x304/0xa20 [veth]<br /> ? do_xdp_generic+0x150/0x150<br /> ? veth_xdp_rcv_one+0xde0/0xde0 [veth]<br /> ? _raw_spin_lock_bh+0xe0/0xe0<br /> ? newidle_balance+0x887/0xe30<br /> ? __perf_event_task_sched_in+0xdb/0x800<br /> veth_poll+0x139/0x571 [veth]<br /> ? veth_xdp_rcv+0xa20/0xa20 [veth]<br /> ? _raw_spin_unlock+0x39/0x70<br /> ? finish_task_switch.isra.0+0x17e/0x7d0<br /> ? __switch_to+0x5cf/0x1070<br /> ? __schedule+0x95b/0x2640<br /> ? io_schedule_timeout+0x160/0x160<br /> __napi_poll+0xa1/0x440<br /> napi_threaded_poll+0x3d1/0x460<br /> ? __napi_poll+0x440/0x440<br /> ? __kthread_parkme+0xc6/0x1f0<br /> ? __napi_poll+0x440/0x440<br /> kthread+0x2a2/0x340<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Freed by task 148640:<br /> kasan_save_stack+0x23/0x50<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x169/0x1d0<br /> slab_free_freelist_hook+0xd2/0x190<br /> __kmem_cache_free+0x1a1/0x2f0<br /> skb_release_data+0x449/0x600<br /> consume_skb+0x9f/0x1c0<br /> veth_xdp_rcv_skb+0x89c/0x1ba0 [veth]<br /> veth_xdp_rcv+0x304/0xa20 [veth]<br /> veth_poll+0x139/0x571 [veth]<br /> __napi_poll+0xa1/0x440<br /> napi_threaded_poll+0x3d1/0x460<br /> kthread+0x2a2/0x340<br /> ret_from_fork+0x22/0x30<br /> <br /> The buggy address belongs to the object at ffff888976250000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 340 bytes inside of<br /> 2048-byte region [ffff888976250000, ffff888976250800)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250<br /> head:00000000ae18262a order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff)<br /> raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00<br /> raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt; ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb