| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <0975b0d16879764a2ab22bc8b3051b13cf55d262.camel@mediatek.com> Date: Tue, 26 Mar 2024 13:10:07 +0000 From: Lena Wang (王娜) <Lena.Wang@...iatek.com> To: "davem@...emloft.net" <davem@...emloft.net>, "kuba@...nel.org" <kuba@...nel.org>, Shiming Cheng (成诗明) <Shiming.Cheng@...iatek.com>, "pabeni@...hat.com" <pabeni@...hat.com>, "willemdebruijn.kernel@...il.com" <willemdebruijn.kernel@...il.com>, "edumazet@...gle.com" <edumazet@...gle.com> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH net] udp: fix segmentation crash for untrusted source packet On Sat, 2024-03-16 at 09:47 -0400, Willem de Bruijn wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Lena Wang (王娜) wrote: > > On Wed, 2024-03-13 at 16:41 +0100, Paolo Abeni wrote: > > > > > > External email : Please do not click links or open attachments > until > > > you have verified the sender or the content. > > > On Wed, 2024-03-13 at 21:34 +0800, Shiming Cheng wrote: > > > > Kernel exception is reported when making udp frag list > > > segmentation. > > > > Backtrace is as below: > > > > at out/android15-6.6/kernel-6.6/kernel- > > > 6.6/net/ipv4/udp_offload.c:229 > > > > at out/android15-6.6/kernel-6.6/kernel- > > > 6.6/net/ipv4/udp_offload.c:262 > > > > features=features@...ry=19, is_ipv6=false) > > > > at out/android15-6.6/kernel-6.6/kernel- > > > 6.6/net/ipv4/udp_offload.c:289 > > > > features=19) > > > > at out/android15-6.6/kernel-6.6/kernel- > > > 6.6/net/ipv4/udp_offload.c:399 > > > > features=19) > > > > at out/android15-6.6/kernel-6.6/kernel- > > > 6.6/net/ipv4/af_inet.c:1418 > > > > skb@...ry=0x0, features=19, features@...ry=0) > > > > at out/android15-6.6/kernel-6.6/kernel- > 6.6/net/core/gso.c:53 > > > > tx_path=<optimized out>) > > > > at out/android15-6.6/kernel-6.6/kernel- > 6.6/net/core/gso.c:124 > > > > > > A full backtrace would help better understanding the issue. > > > > Below is full backtrace: > > [ 1100.812205][ C3] CPU: 3 PID: 0 Comm: swapper/3 Tainted: > > G W OE 6.6.17-android15-0-g380371ea9bf1 #1 > > [ 1100.812211][ C3] Hardware name: MT6991(ENG) (DT) > > [ 1100.812215][ C3] Call trace: > > [ 1100.812218][ C3] dump_backtrace+0xec/0x138 > > [ 1100.812222][ C3] show_stack+0x18/0x24 > > [ 1100.812226][ C3] dump_stack_lvl+0x50/0x6c > > [ 1100.812232][ C3] dump_stack+0x18/0x24 > > [ 1100.812237][ C3] mrdump_common_die+0x24c/0x388 [mrdump] > > [ 1100.812259][ C3] ipanic_die+0x20/0x34 [mrdump] > > [ 1100.812269][ C3] notifier_call_chain+0x90/0x174 > > [ 1100.812275][ C3] notify_die+0x50/0x8c > > [ 1100.812279][ C3] die+0x94/0x308 > > [ 1100.812283][ C3] __do_kernel_fault+0x240/0x26c > > [ 1100.812288][ C3] do_page_fault+0xa0/0x48c > > [ 1100.812293][ C3] do_translation_fault+0x38/0x54 > > [ 1100.812297][ C3] do_mem_abort+0x58/0x104 > > [ 1100.812302][ C3] el1_abort+0x3c/0x5c > > [ 1100.812307][ C3] el1h_64_sync_handler+0x54/0x90 > > [ 1100.812313][ C3] el1h_64_sync+0x68/0x6c > > [ 1100.812317][ C3] __udp_gso_segment+0x298/0x4d4 > > [ 1100.812322][ C3] udp4_ufo_fragment+0x130/0x174 > > [ 1100.812326][ C3] inet_gso_segment+0x164/0x330 > > [ 1100.812330][ C3] skb_mac_gso_segment+0xc4/0x13c > > [ 1100.812335][ C3] __skb_gso_segment+0xc4/0x120 > > [ 1100.812339][ C3] udp_rcv_segment+0x50/0x134 > > [ 1100.812344][ C3] udp_queue_rcv_skb+0x74/0x114 > > [ 1100.812348][ C3] udp_unicast_rcv_skb+0x94/0xac > > [ 1100.812353][ C3] __udp4_lib_rcv+0x3e0/0x818 > > [ 1100.812358][ C3] udp_rcv+0x20/0x30 > > [ 1100.812362][ C3] ip_protocol_deliver_rcu+0x194/0x368 > > [ 1100.812368][ C3] ip_local_deliver+0xe4/0x184 > > [ 1100.812373][ C3] ip_rcv+0x90/0x118 > > [ 1100.812378][ C3] __netif_receive_skb+0x74/0x124 > > [ 1100.812383][ C3] process_backlog+0xd8/0x18c > > [ 1100.812388][ C3] __napi_poll+0x5c/0x1fc > > [ 1100.812392][ C3] net_rx_action+0x150/0x334 > > [ 1100.812397][ C3] __do_softirq+0x120/0x3f4 > > [ 1100.812401][ C3] ____do_softirq+0x10/0x20 > > [ 1100.812405][ C3] call_on_irq_stack+0x3c/0x74 > > [ 1100.812410][ C3] do_softirq_own_stack+0x1c/0x2c > > [ 1100.812414][ C3] __irq_exit_rcu+0x5c/0xd4 > > [ 1100.812418][ C3] irq_exit_rcu+0x10/0x1c > > [ 1100.812422][ C3] el1_interrupt+0x38/0x58 > > [ 1100.812428][ C3] el1h_64_irq_handler+0x18/0x24 > > [ 1100.812434][ C3] el1h_64_irq+0x68/0x6c > > [ 1100.812437][ C3] arch_local_irq_enable+0x4/0x8 > > [ 1100.812443][ C3] cpuidle_enter+0x38/0x54 > > [ 1100.812449][ C3] do_idle+0x198/0x294 > > [ 1100.812454][ C3] cpu_startup_entry+0x34/0x3c > > [ 1100.812459][ C3] secondary_start_kernel+0x138/0x158 > > [ 1100.812465][ C3] __secondary_switched+0xc0/0xc4 > > > > > > This packet's frag list is null while gso_type is not 0. Then > it is > > > treated > > > > as a GRO-ed packet and sent to segment frag list. Function call > > > path is > > > > udp_rcv_segment => config features value > > > > __udpv4_gso_segment => skb_gso_ok returns false. Here it > > > should be > > > > true. > > > > > > Why? If I read correctly the above, this is GSO packet landing in > an > > > UDP socket with no UDP_GRO sockopt. The packet is expected to be > > > segmented again. > > > > > Yes, it is GSO packet, however the fragment list of this GSO packet > > becomes NULL. As the occurrence rate is very low, we really don’t > know > > why and when it becomes to be NULL. It happens both in cellular and > > wlan network and seems an unknown kernel issue. > > > > To avoid crash the packet should skip to be segmented when fraglist > is > > null. > > > > > >Failed reason is features doesn't > > > match > > > > gso_type. > > > > __udp_gso_segment_list > > > > skb_segment_list => packet is linear with skb->next > = > > > NULL > > > > __udpv4_gso_segment_list_csum => use skb->next > directly > > > and > > > > crash happens > > > > > > > > In rx-gro-list GRO-ed packet is set gso type as > > > > NETIF_F_GSO_UDP_L4 | NETIF_F_GSO_FRAGLIST in napi_gro_complete. > In > > > gso > > > > flow the features should also set them to match with gso_type. > Or > > > else it > > > > will always return false in skb_gso_ok. Then it can't discover > the > > > > untrusted source packet and result crash in following function. > > > > > > What is the 'untrusted source' here? I read the above as the > packet > > > aggregation happened in the GRO engine??? > > > > > > Could you please give a complete description of the relevant > > > scenario? > > > > > > > According to the backtrace info, we infer it is a rx-frag_list GRO > > It would be helpful to see an skb_dump. But if this happens rarely in > production, understood if that is not feasible. > > The packet arrives on process_backlog, so still not sure how it is > produced. > Yes, it rarely happens. It is very hard to debug it and not sure its produced path. > > packet. Before sending into the UDP socket with no UDP_GRO sockopt, > it > > seems enter "skb_condense" to trim it and loose his frag list. > However > > it still keeps gso_type and gso_size. Then it continues to do > > skb_segment_list. > > > > First crash happens in skb_segment_list. > > This patch resolves the crash and lets the packet becomes a skb > without > > skb->next: > > https://lore.kernel.org/all/Y9gt5EUizK1UImEP@debian/ > > Then crash moves to __udp_gso_sement_list -> > skb_segment_list(finish) > > -> __udpv4_gso_segment_list_csum, it uses skb->next without check > then > > crash. > > > > > > What we want to do is to drop this abnormal packet. > > I think we want to deliver this packet if possible. > > Thanks for the added context. So this is assumed to be a GSO skb with > SKB_GSO_FRAGLIST that somewhere lots its fraglist? That is the bug > if true. > > You are suggesting that this happens in the skb_condense in > __udp_enqueue_schedule_skb? > We try to add a skb_condense directly before skb_segment_list then get a similar KE backtrace and skb dump value same with this issue skb dump. However we don't know which condition trigger the flow runinto skb_condense. > If generated by GRO then on a device that has NETIF_F_GRO_FRAGLIST > set. > So one workaround (not fix) is to disable that. > As we met other issue previously with GRO in skb_segment(disalbe NETIF_F_GRO_FRAGLIST flow), it is still not safe to disable GRO fraglist. We hope current patch could be applied to drop the invalid packet. > > So we set features > > NETIF_F_GSO_UDP_L4 |NETIF_F_GSO_FRAGLIST to match fixes: > f2696099c6c6 > > condation then drop it.
Powered by blists - more mailing lists