netdev - Re: [net PATCH] skb: Do mix page pool and page referenced frags in GRO

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:   Thu, 26 Jan 2023 22:35:27 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     nbd@....name, davem@...emloft.net, edumazet@...gle.com,
        hawk@...nel.org, ilias.apalodimas@...aro.org, kuba@...nel.org,
        linux-kernel@...r.kernel.org, linyunsheng@...wei.com,
        lorenzo@...nel.org, netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [net PATCH] skb: Do mix page pool and page referenced frags in GRO

Alexander Duyck <alexander.duyck@...il.com> writes:

> On Thu, Jan 26, 2023 at 11:14 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>
>> Alexander Duyck <alexander.duyck@...il.com> writes:
>>
>> > From: Alexander Duyck <alexanderduyck@...com>
>> >
>> > GSO should not merge page pool recycled frames with standard reference
>> > counted frames. Traditionally this didn't occur, at least not often.
>> > However as we start looking at adding support for wireless adapters there
>> > becomes the potential to mix the two due to A-MSDU repartitioning frames in
>> > the receive path. There are possibly other places where this may have
>> > occurred however I suspect they must be few and far between as we have not
>> > seen this issue until now.
>> >
>> > Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool")
>> > Reported-by: Felix Fietkau <nbd@....name>
>> > Signed-off-by: Alexander Duyck <alexanderduyck@...com>
>>
>> I know I'm pattern matching a bit crudely here, but we recently had
>> another report where doing a get_page() on skb->head didn't seem to be
>> enough; any chance they might be related?
>>
>> See: https://lore.kernel.org/r/Y9BfknDG0LXmruDu@JNXK7M3
>
> Looking at it I wouldn't think so. Doing get_page() on these frames is
> fine. In the case you reference it looks like get_page() is being
> called on a slab allocated skb head. So somehow a slab allocated head
> is leaking through.

Alright, thanks for taking a look! :)

-Toke