netdev - vmsplice() appears to be returning to caller while buffers are still in use

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>] [day] [month] [year] [list]

Date:	Tue, 31 Jan 2012 09:50:06 -0800
From:	David VomLehn <dvomlehn@...co.com>
To:	netdev@...r.kernel.org
Subject: vmsplice() appears to be returning to caller while buffers are still
 in use

(Apologies to anyone who has already seen this--didn't realize the mailing
list changed from linux-net to netdev)
Entered in kernel bug tracker as bug #42699.

This problem appears to occur both with sending packets over a network and with
the loopback device, though the specifics vary slightly. The simplest case is a
loopback. When task A sends a big buffer to task B, an sk_buff will be set up
with the mapped buffer as sk_bufs data. The problem is that vmsplice appears to
return to task A at that point, even though task B may not have read any or all
of the data. When task A writes to the buffer, it overwrites the data being
sent to task B, even though task B has not read the data. Thus, task B gets
corrupted data.

The scenario with TCP appears similar, but can be worse because of the
requirement to keep the buffer around for quite a while in order to
retransmitted if necessary.

So long as task A is writing data into the buffer area intended for task B,
this is only a data corruption issue. This may not be the case, however. Should
task A write data intended for some other use into the memory that had been
used for the buffer, that data can leak to task B.

One possible fix would be to add the ability to support sk_buff- or
page-specific notifiers to handle buffer freeing, rather like Ian Campbell's
recent proposal (http://lwn.net/Articles/474791/)

The Bugzilla report has code attached for the loopback case.
-- 
David VL
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html