On Fri, 8 Jan 2021 11:18:39 +0100 Daniel Borkmann wrote: > On 1/8/21 3:28 AM, Dongseok Yi wrote: > > skbs in fraglist could be shared by a BPF filter loaded at TC. If TC > > writes, it will call skb_ensure_writable -> pskb_expand_head to create > > a private linear section for the head_skb. And then call > > skb_clone_fraglist -> skb_get on each skb in the fraglist. > > > > skb_segment_list overwrites part of the skb linear section of each > > fragment itself. Even after skb_clone, the frag_skbs share their > > linear section with their clone in PF_PACKET. > > > > Both sk_receive_queue of PF_PACKET and PF_INET (or PF_INET6) can have > > a link for the same frag_skbs chain. If a new skb (not frags) is > > queued to one of the sk_receive_queue, multiple ptypes can see and > > release this. It causes use-after-free. > > > > [ 4443.426215] ------------[ cut here ]------------ > > [ 4443.426222] refcount_t: underflow; use-after-free. > > [ 4443.426291] WARNING: CPU: 7 PID: 28161 at lib/refcount.c:190 > > refcount_dec_and_test_checked+0xa4/0xc8 > > [ 4443.426726] pstate: 60400005 (nZCv daif +PAN -UAO) > > [ 4443.426732] pc : refcount_dec_and_test_checked+0xa4/0xc8 > > [ 4443.426737] lr : refcount_dec_and_test_checked+0xa0/0xc8 > > [ 4443.426808] Call trace: > > [ 4443.426813] refcount_dec_and_test_checked+0xa4/0xc8 > > [ 4443.426823] skb_release_data+0x144/0x264 > > [ 4443.426828] kfree_skb+0x58/0xc4 > > [ 4443.426832] skb_queue_purge+0x64/0x9c > > [ 4443.426844] packet_set_ring+0x5f0/0x820 > > [ 4443.426849] packet_setsockopt+0x5a4/0xcd0 > > [ 4443.426853] __sys_setsockopt+0x188/0x278 > > [ 4443.426858] __arm64_sys_setsockopt+0x28/0x38 > > [ 4443.426869] el0_svc_common+0xf0/0x1d0 > > [ 4443.426873] el0_svc_handler+0x74/0x98 > > [ 4443.426880] el0_svc+0x8/0xc > > > > Fixes: 3a1296a38d0c (net: Support GRO/GSO fraglist chaining.) > > Signed-off-by: Dongseok Yi <dseok...@samsung.com> > > Acked-by: Willem de Bruijn <will...@google.com> > > Acked-by: Daniel Borkmann <dan...@iogearbox.net>
Applied, thanks!
