linux-kernel - Re: CVE-2025-38495: HID: core: ensure the allocated report buffer can contain the reserved report ID

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: <2025093000-shrank-vending-2bd1@gregkh>
Date: Tue, 30 Sep 2025 12:49:44 +0200
From: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To: Siddh Raman Pant <siddh.raman.pant@...cle.com>
Cc: "cve@...nel.org" <cve@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: CVE-2025-38495: HID: core: ensure the allocated report buffer
 can contain the reserved report ID

On Tue, Sep 30, 2025 at 10:42:31AM +0000, Siddh Raman Pant wrote:
> On Mon, 28 Jul 2025 13:22:37 +0200, Greg Kroah-Hartman wrote:
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > HID: core: ensure the allocated report buffer can contain the reserved report ID
> > 
> > When the report ID is not used, the low level transport drivers expect
> > the first byte to be 0. However, currently the allocated buffer not
> > account for that extra byte, meaning that instead of having 8 guaranteed
> > bytes for implement to be working, we only have 7.
> > 
> > The Linux kernel CVE team has assigned CVE-2025-38495 to this issue.
> 
> This commit prepares for the next commit in the patch series. See
> https://lore.kernel.org/all/20250710-report-size-null-v2-0-ccf922b7c4e5@kernel.org/
> 
> The patch series has 3 commits, with the main fix being the middle
> commit "HID: core: ensure __hid_request reserves the report ID as the
> first byte".
> 
> Unfortunately, the 1st and 3rd commit has CVE numbers assigned to them
> but not the actual fix.
> 
> Please assign CVE number to the middle commit.

What git id is that?

And this commit on its own fixes a problem, so it should be a separate
CVE, right?

> Segue: Can we not have same CVE number for a patch series fixing a
> vuln?

We can, but generally it's just one-fix-per-cve.

thanks,

greg k-h