linux-kernel - Re: [PATCH v2 bpf-next] bpf: Fix latent unsoundness in and/or/xor value tracking

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: Wed, 10 Apr 2024 19:43:46 +0800
From: Shung-Hsi Yu <shung-hsi.yu@...e.com>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Harishankar Vishwanathan <harishankar.vishwanathan@...il.com>, 
	Edward Cree <ecree@....com>, ast@...nel.org, harishankar.vishwanathan@...gers.edu, 
	paul@...valent.com, Matan Shachnai <m.shachnai@...gers.edu>, 
	Srinivas Narayana <srinivas.narayana@...gers.edu>, Santosh Nagarakatte <santosh.nagarakatte@...gers.edu>, 
	Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 bpf-next] bpf: Fix latent unsoundness in and/or/xor
 value tracking

On Tue, Apr 09, 2024 at 06:17:05PM +0100, Edward Cree wrote:
> I don't feel too strongly about it, and if you or Shung-Hsi still
>  think, on reflection, that backporting is desirable, then go ahead
>  and keep the Fixes: tag.
> But maybe tweak the description so someone doesn't see "latent
>  unsoundness" and think they need to CVE and rush this patch out as
>  a security thing; it's more like hardening.  *shrug*

Unfortunately with Linux Kernel's current approach as a CVE Numbering
Authority I don't think this can be avoided. Patches with fixes tag will
almost certainly get a CVE number assigned (e.g. CVE-2024-26624[1][2]),
and we can only dispute[3] after such assignment happend for the CVE to
be rejected.

Shung-Hsi

1: https://lore.kernel.org/linux-cve-announce/2024030648-CVE-2024-26624-3032@gregkh/
2: https://lore.kernel.org/linux-cve-announce/2024032747-REJECTED-f2cf@gregkh/
3: https://docs.kernel.org/process/cve.html#disputes-of-assigned-cves