netdev - Re: [PATCH] esp: Skip TX bytes accounting when sending from a request socket

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190130113328.GJ3581@gauss3.secunet.de>
Date:   Wed, 30 Jan 2019 12:33:28 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Martin Willi <martin@...ongswan.org>
CC:     <netdev@...r.kernel.org>
Subject: Re: [PATCH] esp: Skip TX bytes accounting when sending from a
 request socket

On Mon, Jan 28, 2019 at 09:35:35AM +0100, Martin Willi wrote:
> On ESP output, sk_wmem_alloc is incremented for the added padding if a
> socket is associated to the skb. When replying with TCP SYNACKs over
> IPsec, the associated sk is a casted request socket, only. Increasing
> sk_wmem_alloc on a request socket results in a write at an arbitrary
> struct offset. In the best case, this produces the following WARNING:
> 
> WARNING: CPU: 1 PID: 0 at lib/refcount.c:102 esp_output_head+0x2e4/0x308 [esp4]
> refcount_t: addition on 0; use-after-free.
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc3 #2
> Hardware name: Marvell Armada 380/385 (Device Tree)
> [...]
> [<bf0ff354>] (esp_output_head [esp4]) from [<bf1006a4>] (esp_output+0xb8/0x180 [esp4])
> [<bf1006a4>] (esp_output [esp4]) from [<c05dee64>] (xfrm_output_resume+0x558/0x664)
> [<c05dee64>] (xfrm_output_resume) from [<c05d07b0>] (xfrm4_output+0x44/0xc4)
> [<c05d07b0>] (xfrm4_output) from [<c05956bc>] (tcp_v4_send_synack+0xa8/0xe8)
> [<c05956bc>] (tcp_v4_send_synack) from [<c0586ad8>] (tcp_conn_request+0x7f4/0x948)
> [<c0586ad8>] (tcp_conn_request) from [<c058c404>] (tcp_rcv_state_process+0x2a0/0xe64)
> [<c058c404>] (tcp_rcv_state_process) from [<c05958ac>] (tcp_v4_do_rcv+0xf0/0x1f4)
> [<c05958ac>] (tcp_v4_do_rcv) from [<c0598a4c>] (tcp_v4_rcv+0xdb8/0xe20)
> [<c0598a4c>] (tcp_v4_rcv) from [<c056eb74>] (ip_protocol_deliver_rcu+0x2c/0x2dc)
> [<c056eb74>] (ip_protocol_deliver_rcu) from [<c056ee6c>] (ip_local_deliver_finish+0x48/0x54)
> [<c056ee6c>] (ip_local_deliver_finish) from [<c056eecc>] (ip_local_deliver+0x54/0xec)
> [<c056eecc>] (ip_local_deliver) from [<c056efac>] (ip_rcv+0x48/0xb8)
> [<c056efac>] (ip_rcv) from [<c0519c2c>] (__netif_receive_skb_one_core+0x50/0x6c)
> [...]
> 
> The issue triggers only when not using TCP syncookies, as for syncookies
> no socket is associated.
> 
> Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
> Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
> Signed-off-by: Martin Willi <martin@...ongswan.org>

Applied, thanks Martin!