Since I had a question on this in another forum, I figure I'll copy it to the
public list as well. The credit line below was specifically requested by the
reporter. It wasn't a typo or a lack of proof-reading on our part.
Best,
Gordon
Hat: security-officer
> On May 26, 2021, at 5:54 PM, FreeBSD Security Advisories
> wrote:
>
> Signed PGP part
> =
> FreeBSD-SA-21:11.smap Security Advisory
> The FreeBSD Project
>
> Topic: SMAP bypass
>
> Category: core
> Module: amd64
> Announced: 2021-05-26
> Credits:I lost my dog if you see him please contact me at @m00nbsd.
> Affects:FreeBSD 12.2 and later.
> Corrected: 2021-05-26 19:18:54 UTC (stable/13, 13.0-STABLE)
> 2021-05-26 19:31:50 UTC (releng/13.0, 13.0-RELEASE-p1)
> 2021-05-26 19:30:31 UTC (stable/12, 12.2-STABLE)
> 2021-05-26 20:40:20 UTC (releng/12.2, 12.2-RELEASE-p7)
> CVE Name: CVE-2021-29628
>
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit https://security.FreeBSD.org/>.
>
> I. Background
>
> Supervisor Mode Access Prevention (SMAP) is a security feature
> implemented by contemporary Intel and AMD CPUs. When enabled, it
> ensures that accesses to user memory by the kernel trigger a page fault
> and a subsequent kernel panic. This helps mitigate the security
> implications of kernel bugs that permit an attacker to read from or
> write to user memory from the kernel.
>
> The kernel may legitimately need to copy data between userspace and the
> kernel. To enable this, SMAP is temporarily disabled in the subroutines
> which handle this copying, so only small, specially designated portions
> of the kernel should be executed with SMAP disabled.
>
> II. Problem Description
>
> The FreeBSD kernel enables SMAP during boot when the CPU reports that
> the SMAP capability is present. Subroutines such as copyin() and
> copyout() are responsible for disabling SMAP around the sections of code
> that perform user memory accesses.
>
> Such subroutines must handle page faults triggered when user memory is
> not mapped. The kernel's page fault handler checks the validity of the
> fault, and if it is indeed valid it will map a page and resume copying.
> If the fault is invalid, the fault handler returns control to a
> trampoline which aborts the operation and causes an error to be
> returned. In this second scenario, a bug in the implementation of SMAP
> support meant that SMAP would remain disabled until the thread returns
> to user mode.
>
> III. Impact
>
> This bug may be used to bypass the protections provided by SMAP for the
> duration of a system call. It could thus be combined with other kernel
> bugs to craft an exploit.
>
> IV. Workaround
>
> No workaround is available. On hardware that does not implement SMAP,
> the bug is inconsequential as the mitigation does not exist in the first
> place.
>
> V. Solution
>
> Upgrade your vulnerable system to a supported FreeBSD stable or
> release / security branch (releng) dated after the correction date
> and reboot.
>
> Perform one of the following:
>
> 1) To update your vulnerable system via a binary patch:
>
> Systems running a RELEASE version of FreeBSD on the amd64, i386, or
> (on FreeBSD 13 and later) arm64 platforms can be updated via the
> freebsd-update(8) utility:
>
> # freebsd-update fetch
> # freebsd-update install
> # shutdown -r +10min "Rebooting for a security update"
>
> 2) To update your vulnerable system via a source code patch:
>
> The following patches have been verified to apply to the applicable
> FreeBSD release branches.
>
> a) Download the relevant patch from the location below, and verify the
> detached PGP signature using your PGP utility.
>
> # fetch https://security.FreeBSD.org/patches/SA-21:11/smap.patch
> # fetch https://security.FreeBSD.org/patches/SA-21:11/smap.patch.asc
> # gpg --verify smap.patch.asc
>
> b) Apply the patch. Execute the following commands as root:
>
> # cd /usr/src
> # patch < /path/to/patch
>
> c) Recompile your kernel as described in
> https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
> system.
>
> VI. Correction details
>
> This issue is corrected by the corresponding Git commit hash or Subversion
> revision number in the following stable and release branches:
>
> Branch/path Hash Revision
> -
> stable/13/ 876ffe28796cstable/13-n245764
> releng/13.0/f32130a1955e releng/13.0-n244739
> stable/12/
