The NUMA balancing logic uses an arch-specific PROT_NONE page table flag
defined by pte_protnone() or pmd_protnone() to mark PTEs or huge page
PMDs respectively as requiring balancing upon a subsequent page fault.
User-defined PROT_NONE memory regions which also have this flag set will
not normally invoke the NUMA balancing code as do_page_fault() will send
a segfault to the process before handle_mm_fault() is even called.
However if access_remote_vm() is invoked to access a PROT_NONE region of
memory, handle_mm_fault() is called via faultin_page() and
__get_user_pages() without any access checks being performed, meaning
the NUMA balancing logic is incorrectly invoked on a non-NUMA memory
region.
A simple means of triggering this problem is to access PROT_NONE mmap'd
memory using /proc/self/mem which reliably results in the NUMA handling
functions being invoked when CONFIG_NUMA_BALANCING is set.
This issue was reported in bugzilla (issue 99101) which includes some
simple repro code.
There are BUG_ON() checks in do_numa_page() and do_huge_pmd_numa_page()
added at commit c0e7cad to avoid accidentally provoking strange
behaviour by attempting to apply NUMA balancing to pages that are in
fact PROT_NONE. The BUG_ON()'s are consistently triggered by the repro.
This patch moves the PROT_NONE check into mm/memory.c rather than
invoking BUG_ON() as faulting in these pages via faultin_page() is a
valid reason for reaching the NUMA check with the PROT_NONE page table
flag set and is therefore not always a bug.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99101
Reported-by: Trevor Saunders <email address hidden>
Signed-off-by: Lorenzo Stoakes <email address hidden>
Acked-by: Rik van Riel <email address hidden>
Cc: Andrew Morton <email address hidden>
Cc: Mel Gorman <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(backported from commit 38e088546522e1e86d2b8f401a1354ad3a9b3303)
Tested-by: Marcelo Henrique Cerri <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
Acked-by: Guilherme G. Piccoli <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
The backport of commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call
into vfs_setxattr()") did not consider that vfs_setxattr had other exit
paths that would require a converted value to be freed.
If xattr_permission returns a failure, it would cause a memory leak. In the
case of security.capability attribute, which is the only that can allocate
a new value, xattr_permission will return a failure in case of
HAS_UNMAPPED_ID(inode), which would already be caught by cap_convert_nscap,
at !capable_wrt_inode_uidgid(inode, CAP_SETFCAP).
However, if the file IS_IMMUTABLE or IS_APPEND, the failure will be
returned and the leak will happen.
Though setting a file as immutable or append is restricted to
CAP_FILE_IMMUTABLE, the leak was still shown to happen when trying to
setcap on an immutable file after doing a mount unshare.
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Krzysztof Kozlowski <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
UBUNTU: SAUCE: bpf, x86: Validate computation of branch displacements for x86-64
The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.
But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.
And so the optimizer can expand blocks of machine code in some cases.
This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.
To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.
Signed-off-by: Piotr Krysiuk <email address hidden>
Reviewed-by: Daniel Borkmann <email address hidden>
Signed-off-by: Daniel Borkmann <email address hidden>
(backported from commit e4d4d456436bfb2fe412ee2cd489f7658449b098)
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git)
[cascardo: conflict on message, kept new one, so users can find more
references about it]
CVE-2021-29154
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Guilherme G. Piccoli <email address hidden>
Acked-by: Colin King <email address hidden>
