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 > <security-advisor...@freebsd.org> 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 <URL: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 > <URL: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/ 876ffe28796c stable/13-n245764 > releng/13.0/ f32130a1955e releng/13.0-n244739 > stable/12/ r369857 > releng/12.2/ r369863 > ------------------------------------------------------------------------- > > For FreeBSD 13 and later: > > Run the following command to see which files were modified by a > particular commit: > > # git show --stat <commit hash> > > Or visit the following URL, replacing NNNNNN with the hash: > > <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> > > To determine the commit count in a working tree (for comparison against > nNNNNNN in the table above), run: > > # git rev-list --count --first-parent HEAD > > For FreeBSD 12 and earlier: > > Run the following command to see which files were modified by a particular > revision, replacing NNNNNN with the revision number: > > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base > > Or visit the following URL, replacing NNNNNN with the revision number: > > <URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN> > > VII. References > > <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29628> > > The latest revision of this advisory is available at > <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-21:11.smap.asc> > >
signature.asc
Description: Message signed with OpenPGP