netdev - Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list

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: <54F6D6EB.5020104@citrix.com>
Date:	Wed, 4 Mar 2015 09:56:59 +0000
From:	David Vrabel <david.vrabel@...rix.com>
To:	Ian Campbell <ian.campbell@...rix.com>,
	David Vrabel <david.vrabel@...rix.com>
CC:	<netdev@...r.kernel.org>, Wei Liu <wei.liu2@...rix.com>,
	<xen-devel@...ts.xenproject.org>
Subject: Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling
 a from-guest skb with a frag list

On 04/03/15 09:48, Ian Campbell wrote:
> On Tue, 2015-03-03 at 16:26 +0000, David Vrabel wrote:
>> Every time a VIF is destroyed up-to 256 pages may be leaked if packets
>> with more than MAX_SKB_FRAGS frags where transmitted from the guest.
>> Even worse, if another user of ballooned pages allocated one of these
>> ballooned pages it would not handle the the unexpectedly non-zero page
>> count (e.g., gntdev would deadlock when unmapping a grant because the
>> page count would never reach 1).
>>
>> When handling a from-guest skb with a frag list, unref the frags
>> before releasing them so they are freed correctly when the VIF is
>> destroyed.
> 
> Am I right that the majority of the first 2 hunks (and various bits of
> the 3rd) are just switching the outer loop to nr_frags instead of i, to
> free up i for use in the new code below? And also to switch j to the now
> available i in the inner loop.

Yes.  If you prefer I can split this into one patch that adds the
skb_frag_unref() calls and one that reorders/refactors.

>> Also swap over to the new (local) frags /after/ calling the skb
>> destructor.  This isn't strictly necessary but it's less confusing.
> 
> My only concern would be that this now means there is a period where the
> frags list is invalid. However I think the calling context is such that
> nobody else can have a reference to an skb which has the same shinfo as
> the one in our hand. Is that right?

That is correct.  This skb is allocated by netback and has not yet been
passed up to the network stack.

David

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