linux-kernel - Re: [PATCH net] kcm: Fix splice support

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: <20250804165155.44a32242@kernel.org>
Date: Mon, 4 Aug 2025 16:51:55 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Michal Luczaj <mhal@...x.co>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
 <horms@...nel.org>, Cong Wang <cong.wang@...edance.com>, Tom Herbert
 <tom@...bertland.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] kcm: Fix splice support

On Sun, 3 Aug 2025 12:00:38 +0200 Michal Luczaj wrote:
> On 7/31/25 03:02, Jakub Kicinski wrote:
> > On Fri, 25 Jul 2025 12:33:04 +0200 Michal Luczaj wrote:  
> >> Flags passed in for splice() syscall should not end up in
> >> skb_recv_datagram(). As SPLICE_F_NONBLOCK == MSG_PEEK, kernel gets
> >> confused: skb isn't unlinked from a receive queue, while strp_msg::offset
> >> and strp_msg::full_len are updated.
> >>
> >> Unbreak the logic a bit more by mapping both O_NONBLOCK and
> >> SPLICE_F_NONBLOCK to MSG_DONTWAIT. This way we align with man splice(2) in
> >> regard to errno EAGAIN:
> >>
> >>    SPLICE_F_NONBLOCK was specified in flags or one of the file descriptors
> >>    had been marked as nonblocking (O_NONBLOCK), and the operation would
> >>    block.  
> > 
> > Coincidentally looks like we're not honoring
> > 
> > 	sock->file->f_flags & O_NONBLOCK 
> > 
> > in TLS..  
> 
> I'm a bit confused.
> 
> Comparing AF_UNIX and pure (non-TLS) TCP, I see two non-blocking-splice
> interpretations. Unix socket doesn't block on `f_flags & O_NONBLOCK ||
> flags & SPLICE_F_NONBLOCK` (which this patch follows), while TCP, after
> commit 42324c627043 ("net: splice() from tcp to pipe should take into
> account O_NONBLOCK"), honours O_NONBLOCK and ignores SPLICE_F_NONBLOCK.
> 
> Should KCM (and TLS) follow TCP behaviour instead?

I didn't look closely, but FWIW - yes, in principle KCM and TLS should
copy TCP.