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>
shiftfs expects copy_to_user() to return a negative error code on
failure, when it actually returns the amount of uncopied data. Fix all
code using copy_to_user() to handle the return values correctly.
Signed-off-by: Seth Forshee <email address hidden>
CVE-2021-3492
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Marcelo Cerri <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
UBUNTU: SAUCE: shiftfs: free allocated memory in shiftfs_btrfs_ioctl_fd_replace() error paths
Many error paths in shiftfs_btrfs_ioctl_fd_replace() do not free memory
allocated near the top of the function. Fix up these error paths to free
the memory.
Additionally, the addresses for the allocated memory are assigned to
return parameters early in the function, before we know whether or not
the function as a whole will return success. Wait to assign these values
until we know the function was successful, and for good measure
initialize the return parameters to NULL at the start.
Signed-off-by: Seth Forshee <email address hidden>
CVE-2021-3492
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Marcelo Cerri <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
UBUNTU: SAUCE: bpf, x86: Validate computation of branch displacements for x86-32
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>
(cherry picked from commit 26f55a59dc65ff77cd1c4b37991e26497fc68049
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git)
CVE-2021-29154
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
