netdev - Re: BUG: Bad page state in process systemd-udevd (was: [PATCH v9 bpf-next 1/9] x86/Kconfig: select HAVE_ARCH_HUGE_VMALLOC with HAVE_ARCH_HUGE

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: <24f39339c3371cd63fa959f33c1bab33c19ac51f.camel@intel.com>
Date:   Mon, 28 Mar 2022 19:21:56 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "pmenzel@...gen.mpg.de" <pmenzel@...gen.mpg.de>,
        "songliubraving@...com" <songliubraving@...com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "Kernel-team@...com" <Kernel-team@...com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "song@...nel.org" <song@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "iii@...ux.ibm.com" <iii@...ux.ibm.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>
Subject: Re: BUG: Bad page state in process systemd-udevd (was: [PATCH v9
 bpf-next 1/9] x86/Kconfig: select HAVE_ARCH_HUGE_VMALLOC with
 HAVE_ARCH_HUGE_VMAP)

On Mon, 2022-03-28 at 06:37 +0000, Song Liu wrote:
> + Rick, who highlighted some potential issues with this. (also
> attached
> the stack trace).

Yea, this looks like something else. Just a wild guess, but could some
vmalloc() caller be mucking with the struct page of the backing
allocation in way that trips up compound pages?