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  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:   Wed, 6 Jan 2021 21:11:27 -0500
From:   Willem de Bruijn <>
To:     Jakub Kicinski <>
Cc:     Linus Torvalds <>,
        Steven Rostedt <>,
        David Miller <>,
        Jonathan Lemon <>,
        Thomas Gleixner <>,
        LKML <>,
        "the arch/x86 maintainers" <>,
        Christoph Hellwig <>,
        Matthew Wilcox <>,
        Daniel Vetter <>,
        Andrew Morton <>,
        Linux-MM <>,
        Peter Zijlstra <>,
        Ingo Molnar <>,
        Juri Lelli <>,
        Vincent Guittot <>,
        Dietmar Eggemann <>,
        Ben Segall <>, Mel Gorman <>,
        Daniel Bristot de Oliveira <>,
        Netdev <>
Subject: Re: [BUG] from x86: Support kmap_local() forced debugging

On Wed, Jan 6, 2021 at 8:49 PM Jakub Kicinski <> wrote:
> On Wed, 6 Jan 2021 17:03:48 -0800 Linus Torvalds wrote:
> > I wonder whether there is other code that "knows" about kmap() only
> > affecting PageHighmem() pages thing that is no longer true.
> >
> > Looking at some other code, skb_gro_reset_offset() looks suspiciously
> > like it also thinks highmem pages are special.
> >
> > Adding the networking people involved in this area to the cc too.
> Thanks for the detailed analysis! skb_gro_reset_offset() checks if
> kernel can read data in the fragments directly as an optimization,
> in case the entire header is in a fragment.
> IIUC DEBUG_KMAP_LOCAL_FORCE_MAP only affects the mappings from
> explicit kmap calls, which GRO won't make - it will fall back to
> pulling the header out of the fragment and end up in skb_copy_bits(),
> i.e. the loop you fixed. So GRO should be good. I think..

Agreed. That code in skb_gro_reset_offset skips the GRO frag0
optimization in various cases, including if the first fragment is in
high mem.

That specific check goes back to the introduction of the frag0
optimization in commit 86911732d399 ("gro: Avoid copying headers of
unmerged packets"), at the time in helper skb_gro_header().

Very glad to hear that the fix addresses the crash in
skb_frag_foreach_page. Thanks!

Powered by blists - more mailing lists