netdev - Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG

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]

Date:   Sat, 20 Mar 2021 16:57:42 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Stefan Metzmacher <metze@...ba.org>, io-uring@...r.kernel.org
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short
 send[msg]()/recv[msg]() with MSG_WAITALL

On 3/20/21 1:33 PM, Stefan Metzmacher wrote:
> Without that it's not safe to use them in a linked combination with
> others.
> 
> Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
> should be possible.
> 
> We already handle short reads and writes for the following opcodes:
> 
> - IORING_OP_READV
> - IORING_OP_READ_FIXED
> - IORING_OP_READ
> - IORING_OP_WRITEV
> - IORING_OP_WRITE_FIXED
> - IORING_OP_WRITE
> - IORING_OP_SPLICE
> - IORING_OP_TEE
> 
> Now we have it for these as well:
> 
> - IORING_OP_SENDMSG
> - IORING_OP_SEND
> - IORING_OP_RECVMSG
> - IORING_OP_RECV
> 
> For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC
> flags in order to call req_set_fail_links().
> 
> There might be applications arround depending on the behavior
> that even short send[msg]()/recv[msg]() retuns continue an
> IOSQE_IO_LINK chain.
> 
> It's very unlikely that such applications pass in MSG_WAITALL,
> which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'.
> 
> It's expected that the low level sock_sendmsg() call just ignores
> MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set
> SO_ZEROCOPY.
> 
> We also expect the caller to know about the implicit truncation to
> MAX_RW_COUNT, which we don't detect.

Thanks, I do think this is much better and I feel comfortable getting
htis applied for 5.12 (and stable).

-- 
Jens Axboe