Opened 2 years ago

Closed 2 years ago

#4979 closed enhancement (fixed)

linux-5.16.2

Reported by: Bruce Dubbs Owned by: lfs-book
Priority: high Milestone: 11.1
Component: Book Version: git
Severity: normal Keywords:
Cc:

Description

New point version.

Change History (8)

comment:1 by Bruce Dubbs, 2 years ago

Summary: linux-5.15.13linux-5.16 (Wait for 5.16.1)

Now version 5.16.

comment:2 by Bruce Dubbs, 2 years ago

Summary: linux-5.16 (Wait for 5.16.1)linux-5.16

comment:3 by Bruce Dubbs, 2 years ago

Summary: linux-5.16linux-5.16,1

That didn't take long. Now version 5.15.1.

comment:4 by Bruce Dubbs, 2 years ago

Summary: linux-5.16,1linux-5.16,2

Now version 5.16.2.

comment:5 by Bruce Dubbs, 2 years ago

Summary: linux-5.16,2linux-5.16.2

comment:6 by Douglas R. Reno, 2 years ago

It's been 6 days since there's been a kernel release so far, but the next one will likely have a fix for CVE-2022-0330, which is a security hole in the i915 GPU driver.


[This is a public disclosure of an issue reported 7 days ago to linux-distros at openwall. CVE-2022-0330 has been assigned to the issue since.]

Hi all,

A missing GPU TLB flush has been discovered in the i915 kernel driver which could be exploited by malicious userspace and can manifest in two flavours, depending on whether the GPU is running behind an active IOMMU (address translation) or not:

1. IOMMU with address translation - malicious userspace can trigger DMAR read/write faults getting logged to the kernel log.

2. Without an active IOMMU malicious userspace can gain access (from the code executing on the GPU) to random memory pages.

Second case is therefore the serious one.

It is currently not known whether specific memory could be targeted, but random memory corruption or data leaks are a known possibility.

Underlying reason for the access to memory not owned is a missing TLB flush upon releasing memory which used to back a GPU buffer object back to the system.

Flawed assumption was that flushing the TLB at the start of every userspace GPU execution is sufficient, given the programming model where userspace is expected to declare which graphics virtual memory address ranges it will be accessing at the start of every execution. However what was not considered is that userspace can legitimately (it is allowed in uapi) _not_ declare those accesses.

This allows userspace to continue GPU access to memory, while the kernel driver (i915) is unaware of it being in use, and therefore is allowed to release the backing store back to the system. Should the system then give out those pages back for a different use, the exploit situation can arise.

Return of the pages back to the system can either be specifically engineered by the malicious software, or can happen innocently via system memory pressure.

All Intel integrated and discrete GPUs starting from Gen8 (Broadwell) are affected.

Fix has already been developed and consists of explicitly flushing the TLBs before releasing memory back to the system for any GPU buffer objects which were in use from the GPU.

Note that this will have a varying performance impact depending on the specific GPU, GPU workload and overall system workload.

Fix for the issue has been provided to the Linus distributions and Linux kernel maintainers and is expected to be merged to top of the tree and stable and LTS releases shortly. Fix carries the title of "drm/i915: Flush TLBs before releasing backing store".

Kind regards,

Tvrtko

comment:7 by Douglas R. Reno, 2 years ago

Priority: normalhigh

On the other hand, it looks like CVE-2022-0185 (out-of-bounds write in the filesystem layer) has been fixed, and can allow for sandbox escape and other things.

commit 8b1530a3772ae5b49c6d8d171fd3146bb947430f
Author: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
Date:   Tue Jan 18 08:06:04 2022 +0100

    vfs: fs_context: fix up param length parsing in legacy_parse_param
    
    commit 722d94847de29310e8aa03fcbdb41fc92c521756 upstream.
    
    The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an
    unsigned type so a large value of "size" results in a high positive
    value instead of a negative value as expected.  Fix this by getting rid
    of the subtraction.
    
    Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
    Signed-off-by: William Liu <willsroot@protonmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

More details on that can be found here: https://sysdig.com/blog/cve-2022-0185-container-escape/

The original disclosure: https://www.openwall.com/lists/oss-security/2022/01/18/7

A long writeup on exploitation from yesterday: https://www.openwall.com/lists/oss-security/2022/01/25/14

comment:8 by Bruce Dubbs, 2 years ago

Resolution: fixed
Status: newclosed

Fixed at commit e1ebbef46a60aefd2cb48c6fc82ac3c1414a4054

Package updates.
    Update to vim-8.2.4236.
    Update to zstd-1.5.2.
    Update to util-linux-2.37.3 (security fix).
    Update to Python-3.10.2.
    Update to linux-5.16.2.
    Update to libcap-2.63.
    Update to iproute2-5.16.0.
    Update to iana-etc-20220120.
Note: See TracTickets for help on using tickets.