linux-kernel - Regression: 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]

Message-ID: <47FCCD7F.8010309@rtr.ca>
Date:	Wed, 09 Apr 2008 10:06:55 -0400
From:	Mark Lord <lkml@....ca>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Network <linux-net@...r.kernel.org>
Subject: Regression: 2.6.25-rc8: FTP transfer errors

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.
..

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.
--
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/