netdev - Re: [PATCH net] sunrpc: fix UDP memory accounting

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

Date:   Wed, 31 Aug 2016 07:59:44 -0400
From:   "Benjamin Coddington" <bcodding@...hat.com>
To:     "Paolo Abeni" <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org,
        "Trond Myklebust" <trond.myklebust@...marydata.com>,
        "Anna Schumaker" <anna.schumaker@...app.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        "Jeff Layton" <jlayton@...chiereds.net>,
        "David S. Miller" <davem@...emloft.net>, linux-nfs@...r.kernel.org,
        "Jan Stancek" <jstancek@...hat.com>
Subject: Re: [PATCH net] sunrpc: fix UDP memory accounting

On 31 Aug 2016, at 7:45, Paolo Abeni wrote:

> On Tue, 2016-08-30 at 12:28 -0400, Benjamin Coddington wrote:
>> On 25 Aug 2016, at 12:42, Paolo Abeni wrote:
>>
>>> The commit f9b2ee714c5c ("SUNRPC: Move UDP receive data path
>>> into a workqueue context"), as a side effect, moved the
>>> skb_free_datagram() call outside the scope of the related socket
>>> lock, but UDP sockets require such lock to be held for proper
>>> memory accounting.
>>> Fix it by replacing skb_free_datagram() with
>>> skb_free_datagram_locked().
>>>
>>> Fixes: f9b2ee714c5c ("SUNRPC: Move UDP receive data path into a
>>> workqueue context")
>>> Reported-and-tested-by: Jan Stancek <jstancek@...hat.com>
>>> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
>>
>> Thanks for finding this. A similar fix in 2009 for svcsock.c was done by
>> Eric Dumazet:
>> 9d410c796067 ("net: fix sk_forward_alloc corruption")
>>
>> skb_free_datagram_locked() is used for all xprt types in svcsock.c,
>> should we use
>> it for the xs_local_transport as well in xprtsock.c?
>
> AFAICS a similar fix is _not_ needed for xs_local_transport(), since it
> uses AF_LOCAL sockets and such family does not support protocol's memory
> accounting.

This fixes the WARNING reported by Jan Stancek here:
http://marc.info/?l=linux-nfs&m=146616830928019&w=2

Reviewed-by: Benjamin Coddington <bcodding@...hat.com>

Ben