linux-kernel - Re: 2.6.25-rc8: FTP transfer errors

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:	Wed, 09 Apr 2008 13:16:13 -0400
From:	Mark Lord <lkml@....ca>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Network <linux-net@...r.kernel.org>
Subject: Re: 2.6.25-rc8: FTP transfer errors

Jeff Garzik wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> Today I've been using 2.6.25-rc8 with an old embedded build system here
>>> for my empegs.  One shell script calls out to /usr/bin/ftp to transfer
>>> an image to a remote system, and then read it back again and compare.
>>>
>>> The compare is failing, most (but not all) of the time,
>>> but only on 2.6.25-rc8, not on 2.6.24.  Verified by switching
>>> back and forth between kernel versions for a short spell.
>>>
>>> The ftp client is netkit-ftp 0.17-16 on Kubuntu feisty.
>>>
>>> Switching to ncftpput/ncftpget avoids it on 2.6.25,
>>> but I wonder where the problem is.
>> ..
>>
>> Now verified that the data loss occurs in the outbound direction.
>> The readback data is the same, regardless of which client s/w is used.
>>
>> So something in 2.6.25 is incompatible with the ftp client binary, or 
>> libs, that are installed here.  Or some other problem.
> 
> Or maybe it uses sendfile, and that is broken?
..

No, it uses read()/write() calls (from the strace).
Here's the most recent update:

> Recap, with more info:
> 
> The host system is running 2.6.25-rc8-git.  It uses netkit-ftp to
> send a file to the remote system.  Using strace shows that the
> entire file was read, and passed to write() for the outbound socket.
> 
> The remote system is running linux-2.2.xx, and is reporting -EPIPE
> from net/socket.c::sock_recvmsg() before all of the data has been received,
> and thus ends up with a short file, missing data at the end.
> 
> This exact sequence, with the exact same software,
> works fine when the host system is NOT running 2.6.25-*,
> (eg. 2.6.11 through 2.6.24 are fine).
> 
> Something may be broken here.
..

The failing FTP client software issues a close() on the socket after
the final data write().  This close seems to be propagated to the other
end before the data is fully received.

I suppose a wireshark capture is next, once I dig out my ancient hub
so we can sniff it from an independent box.

-ml 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/