src/lib, branch releng/13.0

pam_exec: fix segfault when authtok is null

2022-07-25T21:08:46Z

According to pam_exec(8), the `expose_authtok` option should be ignored when the service function is `pam_sm_setcred`. Currently `pam_exec` only prevent prompt for anth token when `expose_authtok` is set on `pam_sm_setcred`. This subsequently led to segfault when there isn't an existing auth token available. Bug reported on this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263893 After reading https://reviews.freebsd.org/rS349556 I am not sure if the default behaviour supposed to be simply not prompt for authentication token, or is it to ignore the option entirely as stated in the man page. This patch is therefore only adding an additional NULL check on the item `pam_get_item` provide, and exit with `PAM_SYSTEM_ERR` when such item is NULL. Approved by: so Security: FreeBSD-EN-22:19.pam_exec MFC after: 1 week Reviewed by: des, khng Differential Revision: https://reviews.freebsd.org/D35169 (cherry picked from commit b75e0eed345d2ab047a6b1b00a9a7c3bf92e992c) (cherry picked from commit ea80848e1c0639e2ac8d3f974ddb9c6233491eb3)

Fix libfetch out of bounds read.

2021-08-24T18:00:47Z

Approved by: so Security: SA-21:15.libfetch Security: CVE-2021-36159

libcasper: fix descriptors numbers

2021-06-29T17:09:02Z

Casper services expect that the first 3 descriptors (stdin/stdout/stderr) will point to /dev/null. Which Casper will ensure later. The Casper services are forked from the original process. If the initial process closes one of those descriptors, Casper may reuse one of them for it on purpose. If this is the case, then renumarate the descriptors used by Casper to higher numbers. This is done already after the fork, so it doesn't break the parent process. Approved by: so Security: EN-21:19.libcasper PR: 255339 Reported by: Borja Marcos Tested by: jkim@ (cherry picked from commit aa310ebfba3d49a0b6b03a103b969731a8136a73) (cherry picked from commit 934e10b4a388b13c2bcd8fbac8cd8cc4a641b1b0)

Add C++ headers

2021-06-29T17:08:58Z

I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Approved by: so Security: EN-21:18.libc++ Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days (cherry picked from commit 95aa617e4bf09fcc813b1bab3d0dbf4b606807b1) (cherry picked from commit 70e13c4cffd5ff7a70296bc5c4c3b7525c278b1d)

libradius: Fix attribute length validation in rad_get_attr(3)

2021-06-01T20:26:32Z

The length of the attribute header needs to be excluded when comparing the attribute length against the length of the packet. Otherwise, validation may incorrectly fail when fetching the final attribute in a message. Approved by: so Security: FreeBSD-EN-21:17.libradius Fixes: 8d5c78130 ("libradius: Fix input validation bugs") Reported by: Peter Eriksson Tested by: Peter Eriksson Sponsored by: The FreeBSD Foundation (cherry picked from commit 6bb5699d2b59491097bc21ffa3c097cdd4853f89) (cherry picked from commit f9972532343bb1eb101bf7afef2966972eea3b5e)

libradius: Fix input validation bugs

2021-05-26T20:36:29Z

Approved by: so Security: FreeBSD-SA-21:12.libradius Security: CVE-2021-29629 Sponsored by: The FreeBSD Foundation (cherry picked from commit 8d5c7813061dfa0b187500dfe3aeea7a28181c13) (cherry picked from commit bec0d2c9c8413707b0fff8e65fb96aa53f149be3)

13.0: set static __FreeBSD_version

2021-04-09T00:12:37Z

Approved by: re (implicit) Sponsored by: Rubicon Communications, LLC ("Netgate")

AArch64: Don't set flush-subnormals-to-zero flag on startup

2021-03-24T00:07:34Z

This flag has been set on startup since 65618fdda0f272a823e6701966421bdca0efa301. However, This causes some of the math-related tests to fail as they report zero instead of a tiny number. This fixes at least /usr/tests/lib/msun/ldexp_test and possibly others. Additionally, setting this flag prevents printf() from printing subnormal numbers in decimal form. See also https://www.openwall.com/lists/musl/2021/02/26/1 PR: 253847 Reviewed By: mmel Approved by: re (gjb) Differential Revision: https://reviews.freebsd.org/D28938 (cherry picked from commit 0e4ff0acbe80c547988bede738af2e227c7eb47c) (cherry picked from commit d37fb0e37814db8f76462b3b9f1fb0e6dfca6324)

[PowerPC] [PowerPCSPE] Fix multiple issues in fpsetmask().

2021-03-23T21:59:28Z

Building R on powerpc64 exposed a problem in fpsetmask() whereby we were not properly clamping the provided mask to the valid range. This same issue affects powerpc and powerpcspe. Properly limit the range of bits that can be set via fpsetmask(). While here, use the correct fp_except_t type instead of fp_rnd_t. Reported by: pkubaj, jhibbits (in IRC) Sponsored by: Tag1 Consulting, Inc. Approved by: re (gjb) (Post-RC3 outstanding request approved for RC4) (cherry picked from commit 384ee7cc6e9e4ddc91a6e9e623fcbbe5826bce38) (cherry picked from commit 8b96d6ac04e7e761ec6b9eff47c801a2b89fbd6d)

[PowerPC64] Fix multiple issues in fpsetmask().

2021-03-23T21:50:14Z

Building R exposed a problem in fpsetmask() whereby we were not properly clamping the provided mask to the valid range. R initilizes the mask by calling fpsetmask(~0) on FreeBSD. Since we recently enabled precise exceptions, this was causing an immediate SIGFPE because we were attempting to set invalid bits in the fpscr. Properly limit the range of bits that can be set via fpsetmask(). While here, use the correct fp_except_t type instead of fp_rnd_t. Reported by: pkubaj (in IRC) Sponsored by: Tag1 Consulting, Inc. Approved by: re (gjb) (Post-RC3 outstanding request approved for RC4) (cherry picked from commit dd95b39235dd81c890aa3cce02a5bb7f91f23803) (cherry picked from commit a79735386c46298274d71577ab6b4dd00be261cc)