linux

mirror of https://github.com/torvalds/linux.git synced 2024-12-27 21:33:00 +00:00

A mirror of the official Linux kernel repository just in case

Go to file

Daniel Borkmann 353050be4c bpf: Fix toctou on read-only map's constant scalar tracking Commit `a23740ec43` ("bpf: Track contents of read-only maps as scalars") is checking whether maps are read-only both from BPF program side and user space side, and then, given their content is constant, reading out their data via map->ops->map_direct_value_addr() which is then subsequently used as known scalar value for the register, that is, it is marked as __mark_reg_known() with the read value at verification time. Before `a23740ec43`, the register content was marked as an unknown scalar so the verifier could not make any assumptions about the map content. The current implementation however is prone to a TOCTOU race, meaning, the value read as known scalar for the register is not guaranteed to be exactly the same at a later point when the program is executed, and as such, the prior made assumptions of the verifier with regards to the program will be invalid which can cause issues such as OOB access, etc. While the BPF_F_RDONLY_PROG map flag is always fixed and required to be specified at map creation time, the map->frozen property is initially set to false for the map given the map value needs to be populated, e.g. for global data sections. Once complete, the loader "freezes" the map from user space such that no subsequent updates/deletes are possible anymore. For the rest of the lifetime of the map, this freeze one-time trigger cannot be undone anymore after a successful BPF_MAP_FREEZE cmd return. Meaning, any new BPF_* cmd calls which would update/delete map entries will be rejected with -EPERM since map_get_sys_perms() removes the FMODE_CAN_WRITE permission. This also means that pending update/delete map entries must still complete before this guarantee is given. This corner case is not an issue for loaders since they create and prepare such program private map in successive steps. However, a malicious user is able to trigger this TOCTOU race in two different ways: i) via userfaultfd, and ii) via batched updates. For i) userfaultfd is used to expand the competition interval, so that map_update_elem() can modify the contents of the map after map_freeze() and bpf_prog_load() were executed. This works, because userfaultfd halts the parallel thread which triggered a map_update_elem() at the time where we copy key/value from the user buffer and this already passed the FMODE_CAN_WRITE capability test given at that time the map was not "frozen". Then, the main thread performs the map_freeze() and bpf_prog_load(), and once that had completed successfully, the other thread is woken up to complete the pending map_update_elem() which then changes the map content. For ii) the idea of the batched update is similar, meaning, when there are a large number of updates to be processed, it can increase the competition interval between the two. It is therefore possible in practice to modify the contents of the map after executing map_freeze() and bpf_prog_load(). One way to fix both i) and ii) at the same time is to expand the use of the map's map->writecnt. The latter was introduced in `fc9702273e` ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY") and further refined in `1f6cb19be2` ("bpf: Prevent re-mmap()'ing BPF map as writable for initially r/o mapping") with the rationale to make a writable mmap()'ing of a map mutually exclusive with read-only freezing. The counter indicates writable mmap() mappings and then prevents/fails the freeze operation. Its semantics can be expanded beyond just mmap() by generally indicating ongoing write phases. This would essentially span any parallel regular and batched flavor of update/delete operation and then also have map_freeze() fail with -EBUSY. For the check_mem_access() in the verifier we expand upon the bpf_map_is_rdonly() check ensuring that all last pending writes have completed via bpf_map_write_active() test. Once the map->frozen is set and bpf_map_write_active() indicates a map->writecnt of 0 only then we are really guaranteed to use the map's data as known constants. For map->frozen being set and pending writes in process of still being completed we fall back to marking that register as unknown scalar so we don't end up making assumptions about it. With this, both TOCTOU reproducers from i) and ii) are fixed. Note that the map->writecnt has been converted into a atomic64 in the fix in order to avoid a double freeze_mutex mutex_{un,}lock() pair when updating map->writecnt in the various map update/delete BPF_* cmd flavors. Spanning the freeze_mutex over entire map update/delete operations in syscall side would not be possible due to then causing everything to be serialized. Similarly, something like synchronize_rcu() after setting map->frozen to wait for update/deletes to complete is not possible either since it would also have to span the user copy which can sleep. On the libbpf side, this won't break `d66562fba1` ("libbpf: Add BPF object skeleton support") as the anonymous mmap()-ed "map initialization image" is remapped as a BPF map-backed mmap()-ed memory where for .rodata it's non-writable. Fixes: `a23740ec43` ("bpf: Track contents of read-only maps as scalars") Reported-by: w1tcher.bupt@gmail.com Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org>		2021-11-15 20:47:07 -08:00
arch	Merge branch 'akpm' (patches from Andrew)	2021-11-11 14:31:47 -08:00
block	for-5.16/drivers-2021-11-09	2021-11-09 11:24:08 -08:00
certs	certs: Add support for using elliptic curve keys for signing modules	2021-08-23 19:55:42 +03:00
crypto	Kbuild updates for v5.16	2021-11-08 09:15:45 -08:00
Documentation	Merge branch 'akpm' (patches from Andrew)	2021-11-11 14:31:47 -08:00
drivers	pci-v5.16-fixes-1	2021-11-11 15:10:18 -08:00
fs	Networking fixes for 5.16-rc1, including fixes from bpf, can	2021-11-11 09:49:36 -08:00
include	bpf: Fix toctou on read-only map's constant scalar tracking	2021-11-15 20:47:07 -08:00
init	mm: allow only SLUB on PREEMPT_RT	2021-11-11 09:34:35 -08:00
ipc	ipc/ipc_sysctl.c: remove fallback for !CONFIG_PROC_SYSCTL	2021-11-09 10:02:53 -08:00
kernel	bpf: Fix toctou on read-only map's constant scalar tracking	2021-11-15 20:47:07 -08:00
lib	mm/migrate.c: remove MIGRATE_PFN_LOCKED	2021-11-11 09:34:35 -08:00
LICENSES	LICENSES/dual/CC-BY-4.0: Git rid of "smart quotes"	2021-07-15 06:31:24 -06:00
mm	Merge branch 'akpm' (patches from Andrew)	2021-11-11 14:31:47 -08:00
net	bpf: Forbid bpf_ktime_get_coarse_ns and bpf_timer_* in tracing progs	2021-11-15 20:35:58 -08:00
samples	samples/bpf: Fix build error due to -isystem removal	2021-11-15 20:37:20 -08:00
scripts	Merge branch 'akpm' (patches from Andrew)	2021-11-09 10:11:53 -08:00
security	+ Features	2021-11-11 14:47:32 -08:00
sound	TTY / Serial driver update for 5.16-rc1	2021-11-04 09:09:37 -07:00
tools	selftests/bpf: Add tests for restricted helpers	2021-11-15 20:37:11 -08:00
usr	initramfs: Check timestamp to prevent broken cpio archive	2021-10-24 13:48:40 +09:00
virt	kvm: irqfd: avoid update unmodified entries of the routing	2021-09-30 04:27:10 -04:00
.clang-format	clang-format: Update with the latest for_each macro list	2021-05-12 23:32:39 +02:00
.cocciconfig
.get_maintainer.ignore
.gitattributes	.gitattributes: use 'dts' diff driver for dts files	2019-12-04 19:44:11 -08:00
.gitignore	.gitignore: ignore only top-level modules.builtin	2021-05-02 00:43:35 +09:00
.mailmap	Merge branch 'akpm' (patches from Andrew)	2021-11-09 10:11:53 -08:00
COPYING	COPYING: state that all contributions really are covered by this file	2020-02-10 13:32:20 -08:00
CREDITS	MAINTAINERS: Move Daniel Drake to credits	2021-09-21 08:34:58 +03:00
Kbuild	kbuild: rename hostprogs-y/always to hostprogs/always-y	2020-02-04 01:53:07 +09:00
Kconfig	kbuild: ensure full rebuild when the compiler is updated	2020-05-12 13:28:33 +09:00
MAINTAINERS	Networking fixes for 5.16-rc1, including fixes from bpf, can	2021-11-11 09:49:36 -08:00
Makefile	Kbuild updates for v5.16	2021-11-08 09:15:45 -08:00
README

README

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.