linux-kernel - RE: [PATCH] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

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]

Message-ID:
 <SJ0PR11MB5072F196CE31B9371118153CE5A3A@SJ0PR11MB5072.namprd11.prod.outlook.com>
Date: Tue, 9 Dec 2025 23:55:11 +0000
From: "Liu, Yongxin" <Yongxin.Liu@...driver.com>
To: Ingo Molnar <mingo@...nel.org>
CC: "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com"
	<mingo@...hat.com>,
        "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>,
        "vigbalas@....com" <vigbalas@....com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] x86/elf: Fix core dump truncation on CPUs with no
 extended xfeatures

> -----Original Message-----
> From: Ingo Molnar <mingo@...nel.org>
> Sent: Tuesday, December 9, 2025 17:05
> To: Liu, Yongxin <Yongxin.Liu@...driver.com>
> Cc: x86@...nel.org; linux-kernel@...r.kernel.org; bp@...en8.de;
> tglx@...utronix.de; mingo@...hat.com; dave.hansen@...ux.intel.com;
> vigbalas@....com; stable@...r.kernel.org
> Subject: Re: [PATCH] x86/elf: Fix core dump truncation on CPUs with no
> extended xfeatures
> 
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
> 
> * yongxin.liu@...driver.com <yongxin.liu@...driver.com> wrote:
> 
> > From: Yongxin Liu <yongxin.liu@...driver.com>
> >
> > Zero can be a valid value of num_records. For example, on Intel Atom
> > x6425RE, only x87 and SSE are supported (features 0, 1), and
> > fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop
> > only iterates feature 2, which is not enabled, so num_records = 0.
> > This is valid and should not cause core dump failure.
> >
> > The size check already validates consistency: if num_records = 0, then
> > en.n_descsz = 0, so the check passes.
> >
> > Cc: stable@...r.kernel.org
> > Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86
> > core files")
> > Signed-off-by: Yongxin Liu <yongxin.liu@...driver.com>
> > ---
> >  arch/x86/kernel/fpu/xstate.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/fpu/xstate.c
> > b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..b1dd30eb21a8 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -1984,8 +1984,6 @@ int elf_coredump_extra_notes_write(struct
> coredump_params *cprm)
> >               return 1;
> >
> >       num_records = dump_xsave_layout_desc(cprm);
> > -     if (!num_records)
> > -             return 1;
> 
> The problem with your patch is that '0' is also used for other errors,
> it's the all-around error flag for core dump helper functions such as
> dump_emit():
> 
>                 if (!dump_emit(cprm, &xc, sizeof(xc)))
>                         return 0;
> 
> So please change dump_xsave_layout_desc() to use negatives as genuine
> errors and otherwise returns num_records, and change
> elf_coredump_extra_notes_write() to only abort on genuine errors.

Thank you for the review. I'll send a v2 patch addressing your feedback.

Thanks,
Yongxin

> 
> Thanks,
> 
>         Ingo