Bug 2516758 (CVE-2026-74364)

Summary:	CVE-2026-74364 kernel: bpf: Reject exclusive maps as inner maps in map-in-map
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. Exclusive maps, which are designed to be used by a single program, can be incorrectly inserted as inner maps within a map-in-map structure. This bypasses the intended security checks, allowing an unrelated program to modify the contents of an exclusive map. This vulnerability could enable a malicious actor to rewrite the contents of a frozen map, thereby undermining critical security guarantees.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 06:32:01 UTC

In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject exclusive maps as inner maps in map-in-map

An exclusive map (created with excl_prog_hash) is bound to a single
program by hash: check_map_prog_compatibility() refuses to load any
program whose digest does not match map->excl_prog_sha. That check
only runs for maps a program references directly, i.e. its used_maps.
A map reached at runtime through a map-of-maps is never in used_maps,
and bpf_map_meta_equal() does not consider excl_prog_sha, so an
exclusive map can be inserted into a non-exclusive outer map and
then looked up and mutated by an unrelated program, bypassing the
exclusivity guarantee.

For the signed loader this defeats the metadata map exclusivity check
added in the signed loader: the cached map->sha[] is validated against
the signed hash while another program on a hostile host rewrites the
frozen map's contents through the outer map.

Comment 1 gkamathe 2026-08-19 07:37:38 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081502-CVE-2026-74364-1e36@gregkh/T