netdev - Re: [PATCH v1 net] kcm: Serialise kcm_sendmsg() for the same 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL+tcoCc7Nm7KgaJxYr4arRxnB+62WrTSoSD79i5X-mkHBiO6g@mail.gmail.com>
Date: Fri, 16 Aug 2024 10:56:19 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Tom Herbert <tom@...bertland.com>, 
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org, 
	syzbot+b72d86aa5df17ce74c60@...kaller.appspotmail.com
Subject: Re: [PATCH v1 net] kcm: Serialise kcm_sendmsg() for the same socket.

Hello Kuniyuki,

On Fri, Aug 16, 2024 at 6:05 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> syzkaller reported UAF in kcm_release(). [0]
>
> The scenario is
>
>   1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
>
>   2. Thread A resumes building skb from kcm->seq_skb but is blocked
>      by sk_stream_wait_memory()
>
>   3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb
>      and puts the skb to the write queue
>
>   4. Thread A faces an error and finally frees skb that is already in the
>      write queue
>
>   5. kcm_release() does double-free the skb in the write queue
>
> When a thread is building a MSG_MORE skb, another thread must not touch it.

Thanks for the analysis.

Since the empty skb (without payload) could cause such race and
double-free issue, I wonder if we can clear the empty skb before
waiting for memory, like what already implemented in
tcp_recvmsg_locked():

commit 72bf4f1767f0386970dc04726dc5bc2e3991dc19
Author: Eric Dumazet <edumazet@...gle.com>
Date:   Thu Oct 19 11:24:57 2023 +0000

    net: do not leave an empty skb in write queue

    Under memory stress conditions, tcp_sendmsg_locked()
    might call sk_stream_wait_memory(), thus releasing the socket lock.

    If a fresh skb has been allocated prior to this,
    we should not leave it in the write queue otherwise
    tcp_write_xmit() could panic.

I'm not pretty sure if I understand correctly.

Thanks,
Jason