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:	Thu, 20 Nov 2014 20:17:54 -0800
From:	"Nicholas A. Bellinger" <>
To:	Al Viro <>
Cc:	David Miller <>,,,,, Christoph Hellwig <>
Subject: Re: [RFC] situation with csum_and_copy_... API

Hi Al & Co,

On Thu, 2014-11-20 at 21:47 +0000, Al Viro wrote:
> On Wed, Nov 19, 2014 at 04:53:40PM -0500, David Miller wrote:
> > Pulled, thanks Al.
> Umm...  Not in net-next.git#master...  Anyway, the next portion is in
> vfs.git#iov_iter-net right now; I'll post it on netdev once I get some
> sleep.

Thanks for your detailed analysis + work on this.

> It's getting close to really interesting parts.  Right now the main obstacle
> is in iscsit_do_rx_data/iscsit_do_tx_data; what happens there is reuse of
> iovec if kernel_sendmsg() gives a short write - it tries to send again, with
> the same iovec and decremented length.  Ditto on RX side (with kernel_recvmsg(),
> obviously).
> As far as I can see, these retries on the send side are simply broken -
> normally we are talking to TCP sockets there and tcp_sendmsg() does *not*
> modify iovec in normal case.  IOW, if you get 8K sent out of 80K, the next
> time it'll try to send 72K - already sent piece + 64K following it, etc.

AFAIK, short writes have not been actively getting triggered.

This is likely due to iscsit_do_tx_data() being used for sending 48 byte
PDU header, and small payloads in ISCSI_OP_LOGIN_RSP, ISCSI_OP_TEXT_RSP,
and ISCSI_OP_NOOP_IN control PDUs. 

All bulk data READ payloads are sent via iscsit_fe_sendpage_sg() and
only use iscsit_do_tx_data() for leading PDU header.

On the receive side, kernel_recvmsg() is called with MSG_WAITALL that
has been masking this bug..

> Could target-devel folks tell how realistic those resends are, in the
> first place?  Both with TX and RX sides...  Is there any sane limit on
> iovec size there, etc.

Of the three control type PDU using this codepath, the transfer lengths
are currently limited to <= 32K + header across 2 kvecs.  The simplest
fix would probably be to fail the connection when send/recv returns a
value other than requested transfer length for these special cases.

For correctly handling short writes with your new work, what's the
preferred way to do this..?


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists