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>] [day] [month] [year] [list]
Message-ID: <2024102124-CVE-2024-49861-5288@gregkh>
Date: Mon, 21 Oct 2024 14:27:27 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-49861: bpf: Fix helper writes to read-only maps

Description
===========

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

bpf: Fix helper writes to read-only maps

Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.

In check_func_arg() when the argument is as mentioned, the meta->raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.

The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.

However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *<ptr> = val.
The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).

MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *<ptr> = val.

The Linux kernel CVE team has assigned CVE-2024-49861 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.2 with commit 57c3bb725a3d and fixed in 6.6.54 with commit a2c8dc7e2180
	Issue introduced in 5.2 with commit 57c3bb725a3d and fixed in 6.10.13 with commit 2ed98ee02d1e
	Issue introduced in 5.2 with commit 57c3bb725a3d and fixed in 6.11.2 with commit 1e75d2513315
	Issue introduced in 5.2 with commit 57c3bb725a3d and fixed in 6.12-rc1 with commit 32556ce93bc4

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-49861
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	include/linux/bpf.h
	kernel/bpf/helpers.c
	kernel/bpf/syscall.c
	kernel/bpf/verifier.c
	kernel/trace/bpf_trace.c
	net/core/filter.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0
	https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c
	https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5
	https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ