From errata-notices at freebsd.org Tue Aug 6 18:31:29 2019
From: errata-notices at freebsd.org (FreeBSD Errata Notices)
Date: Tue, 6 Aug 2019 18:31:28 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:14.epoch
Message-ID: <20190806183128.F0EB0EDFB@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:14.epoch Errata Notice
The FreeBSD Project
Topic: Incorrect locking in epoch(9)
Category: core
Module: kernel
Announced: 2019-08-06
Credits: Mark Johnston
Affects: FreeBSD 12.0
Corrected: 2019-07-27 16:11:04 UTC (stable/12, 12.0-STABLE)
2019-08-06 17:07:43 UTC (releng/12.0, 12.0-RELEASE-p9)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
Some parts of the kernel use a new synchronization primitive, epoch(9),
which can be used to implement safe memory reclamation. In this usage,
threads can use the epoch(9) KPI to ensure that no other threads hold
a reference to a given object in memory.
II. Problem Description
In the case where epoch(9) must wait for a thread that is blocked on
a lock, it will use the turnstile(9) KPI to propagate the current
thread's priority to the lock holder. However, in the case where the
lock has no designated owner - for example, it is a reader-writer lock
owned by one or more readers - a bug in the interaction with the
turnstile meant that pair of spin locks were left locked when they
should have been unlocked.
III. Impact
In rare cases and under heavy load, the kernel may panic or lock up.
IV. Workaround
No workaround is available.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date, and reboot.
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Rebooting for errata update"
2) To update your 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/EN-19:14/epoch.patch
# fetch https://security.FreeBSD.org/patches/EN-19:14/epoch.patch.asc
# gpg --verify epoch.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r350373
releng/12.0/ r350641
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1JtztfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJgXA//Wbh6Nv6OL+Aer7oZ8uiZEhDTj+a+IMG617uCyeD+x4/8Hj73J7Pg6vaT
CGqGAslxy8GMmvrO8Jmn0RFDyfJb+mW1M9FqQS4u9DNm1r7nNuOBWj9UcAC9TQOY
rIEoqe/wD6a+EKQ01tgsWm2TYA2hX/WwtKJiYuPJOyuTzm9d3PhQ2SPmU0NaqyfU
+0YT3QHRYUEYHU/tZwAV3axcihYP7NfrgEWmE3LY7fBX1ShxFOYZVlexY4604wyc
SLxCMVnfqFiB8vH5X8R4J9OlsK00j1W2B+PJodocDzNjvHgnRb3RSHeo+EC+3y7k
/P3qRCxtgPzb/VHCCRry0LAmeijxQDWVf4vydjaMVDQEv/zQ+Y5ujAucRAtvtjRm
gYLRTOHnXVTpZk/c8h2Gch9g3sB9aqrsMYtPUqSfRRUFDYJjN3NVmVLo4ciAhjwY
EvGr7HloO3O4n+zYWOagvSvu05TjOA1SGGURAkslthjTXRpmiqDSS6yawW23v7Jw
gC7pvVUnmGSGzlwGPojE6LBSX3CWlgwJV/6g2s0wizPGv3K/IQMMQn7NaaLl09xw
X6TND7mVGqk2w3do1k9ZSkvqI+jr4MkJbGh5Vl8q1J/oW9KPTVO3+mQEi91SvgU+
YEyzryregBP69ta7gqT0Pgb2+LR9733qPLSh3Hgn/4zRI/seSkU=
=pBEN
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 6 18:32:12 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 6 Aug 2019 18:32:11 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:19.mldv2
Message-ID: <20190806183211.E4B82EE12@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:19.mldv2 Security Advisory
The FreeBSD Project
Topic: ICMPv6 / MLDv2 out-of-bounds memory access
Category: core
Module: net
Announced: 2019-08-06
Credits: CJD of Apple
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-06 17:13:41 UTC (stable/12, 12.0-STABLE)
2019-08-06 17:11:17 UTC (releng/12.0, 12.0-RELEASE-p9)
2019-08-06 17:15:46 UTC (stable/11, 11.3-STABLE)
2019-08-06 17:11:17 UTC (releng/11.3, 11.3-RELEASE-p2)
2019-08-06 17:11:17 UTC (releng/11.2, 11.2-RELEASE-p13)
CVE Name: CVE-2019-5608
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
MLDv2 is the Multicast Listener Discovery protocol, version 2. It is used
by IPv6 routers to discover multicast listeners.
II. Problem Description
The ICMPv6 input path incorrectly handles cases where an MLDv2 listener
query packet is internally fragmented across multiple mbufs.
III. Impact
A remote attacker may be able to cause an out-of-bounds read or write that
may cause the kernel to attempt to access an unmapped page and subsequently
panic.
IV. Workaround
No workaround is available. Systems not using IPv6 are not affected.
V. Solution
Perform one of the following:
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Reboot for 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.
[FreeBSD 11.2, FreeBSD 11.3]
# fetch https://security.FreeBSD.org/patches/SA-19:19/mldv2.11.patch
# fetch https://security.FreeBSD.org/patches/SA-19:19/mldv2.11.patch.asc
# gpg --verify mldv2.11.patch.asc
[FreeBSD 12.0]
# fetch https://security.FreeBSD.org/patches/SA-19:19/mldv2.12.patch
# fetch https://security.FreeBSD.org/patches/SA-19:19/mldv2.12.patch.asc
# gpg --verify mldv2.12.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r350648
releng/12.0/ r350644
stable/11/ r350650
releng/11.3/ r350644
releng/11.2/ r350644
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1Jt1RfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cLzTA/+OyyukXWH7rfwMhOlpD60UH4hxN3purvdNeBe4ZxlYvtf8gSUzS1VbK5r
NR9D2HiYRlmaePOil5myan6cVkrKoANoWTrQsCcsFLe6KKbiKlQDx/btbENmCMsR
VoS0ZPx3l9iGuVUwDk6k1JXwKCcO3U3dCDYEI941hEKxYadR+twUP3JOceg8Zn0h
oODXW7LcPXWQKAyFc0Kun1VrjrUGdRGfqk30joR20GP2IjgQceFHKUbiOyBbbIjW
+UVvp2wPBxXvcXNPTpcIpTW5UGJBHCT2OsDulh7hqpiWf78VE8BoksKAvDjtI4i0
15fmwn7tmQ3aGWK3WoaKWUOXZUlKrxRQDzGyAZ3LzOqPWhv12tJjNJhjnRmCVLfo
+F4I/MHzPgjitZhv8gfn+MRiPG4E1ueAYnPQWiR3qRCLQGhemVdKZIAVnYg6NGpQ
Jgsr1QS8/3GHZ8yrMXUOSNOSuiMmRHbI9915vVzu+hWkfnrCcSr3uVkJeQvx4CZJ
gdTL083Knnkdo4IPOdHWnQjGfrv2rGRyvCJ88m/DIC6hw4weR1LyFWMEHeJCEcJl
5LHiVWmOUJE4ltJXrRoXwxuh9Dia0Mq6KfNA0343JFpQF9rdt3JQ/54FPGtK6NUO
LyX5a42RIKRxWNTN+ADrSk8czbHFIg8MfTwpjiRGx2rYtxjp1qU=
=WaXC
-----END PGP SIGNATURE-----
From errata-notices at freebsd.org Tue Aug 6 18:31:35 2019
From: errata-notices at freebsd.org (FreeBSD Errata Notices)
Date: Tue, 6 Aug 2019 18:31:35 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:15.libunwind
Message-ID: <20190806183135.772D8EDFE@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:15.libunwind Errata Notice
The FreeBSD Project
Topic: Incorrect exception handling
Category: contrib
Module: libunwind
Announced: 2019-08-06
Affects: FreeBSD 11.2, FreeBSD 12.0
Corrected: 2019-08-06 17:08:30 UTC (releng/12.0, 12.0-RELEASE-p9)
2019-08-06 17:08:30 UTC (releng/11.2, 11.2-RELEASE-p13)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
The libunwind library, which originates from the LLVM project, is responsible
for handling the unwinding of stack frames, when programs throw C or C++
style exceptions. It uses exception handling information embedded in the
executable file to determine the layout of the stack, at the time the
exception is being processed.
II. Problem Description
In some cases, the exception handling information embedded in executables is
not correctly interpreted by libunwind. This causes it to emit a runtime
error, and abort the affected program.
III. Impact
Affected programs will show an message on the standard error stream, when
they attempt to throw an exception:
libunwind: getEncodedP \
/usr/src/contrib/llvm/projects/libunwind/src/AddressSpace.hpp:280 - \
unknown pointer encoding
After this message, the program will be aborted using the abort(3) function,
which usually results in a core dump.
IV. Workaround
No workaround is available.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date, and reboot.
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
2) To update your 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/EN-19:15/libunwind.patch
# fetch https://security.FreeBSD.org/patches/EN-19:15/libunwind.patch.asc
# gpg --verify libunwind.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in , and
reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
releng/12.0/ r350642
releng/11.2/ r350642
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1Jt0pfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJOkQ/+N8Esx4GPWNOzNOGJAnBgtujVeCDjbubny9ktMElEw6mZJKWqcgFmG1bm
hdz5iAz6xn/W6Y5fUR07aM6KFLTN7Is0LqaC+4mWFgbmPu9t0DVgjjsSHAJk6+fu
NpkSMDYq0tUqhNUFlP36EoTHUuM7KlD3/a1dlGZwSOmT3tQitosD8MYNm8bXdsiG
Fx8xXJz8l7qtSw5a1HI2yrRmR7hZHEblGVDP1BjU+QVh7O+0oTeSWHjtriCeYXOl
KUNypPNU5HTySLI0XE+wXJ8S3SblmCOJSdEy/EDZYd8KxG2ib+abn6KdewQl0dIL
0evKaSeIfrVyHfbQporrUotpuTgHrxdD63vowtyH4fL/JzNmw38ZBRzu/4Lib4eF
uaMr7IXyUvifJRBNHCSV5waEQXdcaZ4/YiNg93kiBCC1FhqKEEel0TLARTqtCEVu
ByQVjjZ5v45OAq74uFSYfnSReLt96VnQFD8J5JIKlYaR145tSUKzgetUy+iekjq2
7sRr0kh7lGFFNoOhbFDBURr3HrFgfpWgRA12/AuAVelXPTG4ik8tU6X/vNlvysK6
TJel41R8++MPUQuaQPU9KfUiAycvV4P9/hHEodnjhNY7NaWkXaP+fJpxCtctcFGd
eIcI3nIoJX+6W2KjZkJcrbuZsqkVSsz0MXgfLNuoNZruzdppLAY=
=Sq9+
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 6 18:32:04 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 6 Aug 2019 18:32:03 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:18.bzip2
Message-ID: <20190806183203.E7B77EE07@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:18.bzip2 Security Advisory
The FreeBSD Project
Topic: Multiple vulnerabilities in bzip2
Category: contrib
Module: bzip2
Announced: 2019-08-06
Affects: All supported versions of FreeBSD.
Corrected: 2019-07-04 07:29:18 UTC (stable/12, 12.0-STABLE)
2019-08-06 17:09:47 UTC (releng/12.0, 12.0-RELEASE-p9)
2019-07-04 07:32:25 UTC (stable/11, 11.3-STABLE)
2019-08-06 17:09:47 UTC (releng/11.3, 11.3-RELEASE-p2)
2019-08-06 17:09:47 UTC (releng/11.2, 11.2-RELEASE-p13)
CVE Name: CVE-2016-3189, CVE-2019-12900
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
The bzip2(1)/bunzip2(1) utilities and the libbz2 library compress and
decompress files using an algorithm based on the Burrows-Wheeler transform.
They are generally slower than Lempel-Ziv compressors such as gzip, but
usually provide a greater compression ratio.
The bzip2recover utility extracts blocks from a damaged bzip2(1) file,
permitting partial recovery of the contents of the file.
II. Problem Description
The decompressor used in bzip2 contains a bug which can lead to an
out-of-bounds write when processing a specially crafted bzip2(1) file.
bzip2recover contains a heap use-after-free bug which can be triggered
when processing a specially crafted bzip2(1) file.
III. Impact
An attacker who can cause maliciously crafted input to be processed
may trigger either of these bugs. The bzip2recover bug may cause a
crash, permitting a denial-of-service. The bzip2 decompressor bug
could potentially be exploited to execute arbitrary code.
Note that some utilities, including the tar(1) archiver and the bspatch(1)
binary patching utility (used in portsnap(8) and freebsd-update(8))
decompress bzip2(1)-compressed data internally; system administrators should
assume that their systems will at some point decompress bzip2(1)-compressed
data even if they never explicitly invoke the bunzip2(1) utility.
IV. Workaround
No workaround is available.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and restart daemons if necessary.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
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-19:18/bzip2.patch
# fetch https://security.FreeBSD.org/patches/SA-19:18/bzip2.patch.asc
# gpg --verify bzip2.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Restart all daemons that use the library, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r349717
releng/12.0/ r350643
stable/11/ r349718
releng/11.3/ r350643
releng/11.2/ r350643
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1Jt09fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJWEQ//dBiFwPCKcUaeSBuM9opVUxWzFYrpWdYwwagQXzNqO3Z77Vi2hHQnfpkD
bM8WgWwChOJmlTja7sjnF+QjoV9/elzYhFrD6q0W1nLZ2XHcXyHrbFLMJ+CrvCWR
AuVCEkmT2fchE/5c71l/v8I452EpGZG7P0fwG1bpf84p1PFLl3esfeo8+CzN1x2h
YLnvfp69/tC18LR0/yozRUuFSqoYBhbnJsclB1JkrGx0fPOcE9y3sudVhBIDbH7h
nYSTJl/KkTHf6tbJVXWUVr5gJzCgGvvhUer49RCdJMAwj6hKYT49vWnOFl1T8DAL
+co0ZzTiKoCdrrrguijh4QTEUe4UAGS3PPAwhUiOu+y8Bry06/U565uO9y9iILef
M5oYTbM7h/TErPxSE421fWeexeK0seCHqmj/rO1Yf7RkRvLg/QaJk5YWM0KoP3NH
QQRdX8qNiy4liEqGvJwfUdNcVXA3d7BKifl6MKH+5/2i5B23wHItIeuIGYo5LgdI
mnH59L5wylhWGa0Dc+N9fP0jFvBfk7/4a0joXYIQ7/KDQg0X+WdiGZ/mzZ4GEisX
hwI2laAh/oyksInrMcLCbvgWql+lrUvK3ltHo17U+wrMeb+8btDLR5T/9XlLPWGp
s101XS6ewcwpZ8g5uBtlFBLmp8BGkALTAJtwwqJ2eoLfLYCXq3I=
=3O6m
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 6 18:32:19 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 6 Aug 2019 18:32:18 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:20.bsnmp
Message-ID: <20190806183218.F15A6EE1F@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:20.bsnmp Security Advisory
The FreeBSD Project
Topic: Insufficient message length validation in bsnmp library
Category: contrib
Module: bsnmp
Announced: 2019-08-06
Credits: Guido Vranken
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-06 16:11:16 UTC (stable/12, 12.0-STABLE)
2019-08-06 17:12:17 UTC (releng/12.0, 12.0-RELEASE-p9)
2019-08-06 16:12:43 UTC (stable/11, 11.3-STABLE)
2019-08-06 17:12:17 UTC (releng/11.3, 11.3-RELEASE-p2)
2019-08-06 17:12:17 UTC (releng/11.2, 11.2-RELEASE-p13)
CVE Name: CVE-2019-5610
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
The bsnmp software library is used for the Internet SNMP (Simple Network
Management Protocol). As part of this it includes functions to handle ASN.1
(Abstract Syntax Notation One).
II. Problem Description
A function extracting the length from type-length-value encoding is not
properly validating the submitted length.
III. Impact
A remote user could cause, for example, an out-of-bounds read, decoding of
unrelated data, or trigger a crash of the software such as bsnmpd resulting
in a denial of service.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
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-19:20/bsnmp.patch
# fetch https://security.FreeBSD.org/patches/SA-19:20/bsnmp.patch.asc
# gpg --verify bsnmp.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Restart all daemons that use the library, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r350637
releng/12.0/ r350646
stable/11/ r350638
releng/11.3/ r350646
releng/11.2/ r350646
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1Jt1lfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cKtBBAAltxFzxuMqWCgJoL9SemLRQxGGk0hRFdN5b78mgVdk2lfDgVz8U7mVM6v
XbcCa4lIy7wMYpUdEySAZLR2ENt0xdpx7oQ6lAg5fnnvrUvom4wU9ruxEs5txFVL
K6RaJnQJyOkI2c/LYvI/ZYmuc29/Nt3p/DvVe7wq86taoqUufN11MXkrRHgn68N3
7vewixzWpqH5L/aY2qP1d+Xe3QmHX0IcFqeo4U3/3G4wUGRCfHtaENY4w5eUbCa2
1Qk0oS9iUdX1IJjM5l1ccoFqsjbcO6vNS337qeYNKhLspXMQPwoS0K0HfB6LKt1D
dCBFoXu/qUFjf3qqbpcqGEFrFPZjlNmC4R0Ngx1rfZ1t1dXbj83NOOE1okd3Gb/V
TPDU/jzwt+/6DE6ryNQpeanPdim83w/j+qeA0UaTyxlbj+oSz1gU9Ckaauf+9peI
GT8TPnrgmFlYg2tkYl4tbq5LtRstPGZYguqEt5SHCxBOg3dxByMPzikSFUL9oNxS
9GX7JZT36J20f62hG8Watp2y3W0QsMjJpxF9OojRU6B15Z4Q2aCht4F6DnvEkVfN
1GvS5NAHPHU09TniSgYK3ThkoYrLYykhsXPmJmETV7DU1Qhny1p8H0NwIwB20DEm
AOAcYzLhiXHGpniE5y+MT9Pvt3BDBt36k6WgZ4eZ4RWuzGOumiU=
=rH6X
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 6 18:32:25 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 6 Aug 2019 18:32:25 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:21.bhyve
Message-ID: <20190806183225.6B608EE2F@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:21.bhyve Security Advisory
The FreeBSD Project
Topic: Insufficient validation of guest-supplied data (e1000 device)
Category: core
Module: bhyve
Announced: 2019-08-06
Credits: Reno Robert
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-05 22:04:16 UTC (stable/12, 12.0-STABLE)
2019-08-06 17:13:17 UTC (releng/12.0, 12.0-RELEASE-p9)
2019-08-05 22:04:16 UTC (stable/11, 11.3-STABLE)
2019-08-06 17:13:17 UTC (releng/11.3, 11.3-RELEASE-p2)
2019-08-06 17:13:17 UTC (releng/11.2, 11.2-RELEASE-p13)
CVE Name: CVE-2019-5609
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
bhyve(8) is a hypervisor that supports running a variety of guest operating
systems in virtual machines. bhyve(8) includes an emulated Intel 82545
network interface adapter ("e1000").
II. Problem Description
The e1000 network adapters permit a variety of modifications to an Ethernet
packet when it is being transmitted. These include the insertion of IP and
TCP checksums, insertion of an Ethernet VLAN header, and TCP segmentation
offload ("TSO"). The e1000 device model uses an on-stack buffer to generate
the modified packet header when simulating these modifications on transmitted
packets.
When TCP segmentation offload is requested for a transmitted packet, the
e1000 device model used a guest-provided value to determine the size of the
on-stack buffer without validation. The subsequent header generation could
overflow an incorrectly sized buffer or indirect a pointer composed of stack
garbage.
III. Impact
A misbehaving bhyve guest could overwrite memory in the bhyve process on the
host.
IV. Workaround
Only the e1000 device model is affected; the virtio-net device is not
affected by this issue. If supported by the guest operating system
presenting only the virtio-net device to the guest is a suitable workaround.
No workaround is available if the e1000 device model is required.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and restart any affected virtual machines.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
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-19:21/bhyve.patch
# fetch https://security.FreeBSD.org/patches/SA-19:21/bhyve.patch.asc
# gpg --verify bhyve.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Restart the applicable virtual machines, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r350619
releng/12.0/ r350647
stable/11/ r350619
releng/11.3/ r350647
releng/11.2/ r350647
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1Jt1xfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cL0qA//ZdapXUMl6KuuvtZIveMZgNdMVLYaqB1K8yHXO5udd58fTsH6+Khei0LT
gYGxDEJkHinM1EWy688xE+PSzb9twmEmawW4N4WMhWB9oMoTuLQ5E4Zm9my1TdDh
ducK6Q4GqOojIXJ0LtHDqs9qveAfkgB6L6jmLt/1jpZelLupte3S+bPmI4yta7ge
7k54V9GcN05i7wX2TaZA7H3ROQziW537ZeoRB8BQwt7bekFw2uBfO9s0CWcJZPnG
+0D6QEsRqbtYMJr5RkUCc1y4qaqnWBBn/Zyyr0P+bXZklU/IW2GJTDWNObXN7DPE
NOhuVY7PQHN6jv3u+nKa1AY7mjI3zBo009iAfPQFCb9Kn08tJ2A9WrExEMwZdcbI
nXVqCRdp7xCSPO73vjNv4btzvAU7iwbaBkpGFs721cH72ImvmXi7TwepPEAul0do
VwKYMxhStZtoDQhEea1eq41KNvqxmA/mkbEjpKcTZCUJq7xVyV4uaVme3Uq45uaa
mKMWx+Gg09A2Y5NfSCiz9AGuMkIGn05hKIOK39yAG159uTks60Ybsw/bOnE9WnMJ
5igcI+U6utIMi2M6nH4rn/wKBYM9cHWmQLfo6kECUi2CCTmR5VL8BTJ/8vHCqXi1
vCcAPacKYAROsvGQyynSVLiXJAXOrc8/VyoXRHC5cAapVeParcw=
=0XzG
-----END PGP SIGNATURE-----
From errata-notices at freebsd.org Tue Aug 20 20:12:32 2019
From: errata-notices at freebsd.org (FreeBSD Errata Notices)
Date: Tue, 20 Aug 2019 20:12:31 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:16.bhyve
Message-ID: <20190820201231.C07F21F73D@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:16.bhyve Errata Notice
The FreeBSD Project
Topic: Bhyve instruction emulation improvements (opcode 03H and F7H)
Category: core
Module: bhyve
Announced: 2019-08-20
Credits: John Baldwin, Jason Tubnor
Affects: All supported versions of FreeBSD.
Corrected: 2019-07-07 17:30:23 UTC (stable/12, 12.0-STABLE)
2019-08-20 17:45:44 UTC (releng/12.0, 12.0-RELEASE-p10)
2019-07-07 17:31:13 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:45:44 UTC (releng/11.3, 11.3-RELEASE-p3)
Note: This errata notice does not update FreeBSD 11.2. FreeBSD 11.2
users affected by this update should upgrade to FreeBSD 11.3.
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
bhyve(8) is a hypervisor that supports running a variety of guest operating
systems in virtual machines, using hardware virtualization in Intel and AMD
CPUs. Some instructions are not handled by hardware virtualization and must
be emulated by the hypervisor.
II. Problem Description
Some newer software uses instructions previously not handled by bhyve's
instruction emulation. This errata notice adds emulation for two instruction
opcodes, to enable flash variable storage in OVMF and to support guest
operating systems compiled with Clang 8.0.0 that use the TEST instruction
against local APIC registers (such as OpenBSD 6.6).
III. Impact
Guest firmware or operating systems using unsupported instructions caused
bhyve to exit with a "Failed to emulate instruction" error.
IV. Workaround
No workaround is available.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
2) To update your 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.
[FreeBSD 11.3, FreeBSD 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:16/bhyve.patch
# fetch https://security.FreeBSD.org/patches/EN-19:16/bhyve.patch.asc
# gpg --verify bhyve.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Start the applicable virtual machines.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r349808
releng/12.0/ r351256
stable/11/ r349809
releng/11.3/ r351256
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1cPfFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJzqA//XiWRn/psT+I8r7MSiS6K2bJASZlFGUDnVqLsFAnj2XoZlSp265dZw0R7
t++kBPu0Q9vm3FphkE/J3e4fR9PyCsa5QpEvTeXE9v1RixrkmmLT56ukR3BgivKa
rmCTjkwLikmRb8qrRMly9ERjwySKlUZmOMHX1xte33WTi2eVwZUfNg9xNq1c4YGi
QvIABOa1xTZHr0oyeZfmuEyhSDRD+jzb+mOboX9TFQSfAUwC16VDCAHu5SwXNeQS
l4/FxrYf0yupf2bqwWmfeRlAE25nHGErsaXiQwqdPZB3SUTECpDcl5BCwPwA+pr3
Jf7lxTPrp/NLi7sghgofOX5AwbiVacYxN45P4JNjBB5OpDut+e196VkzO1IAXVRb
spyc/zKE6BWYRT2KOeNlMzmQXmDIjZERuumV98DQQEAAw52p+RWdEU3IlfZ+plW7
bF8P/OmJ5DDcdW1XeONIzFaal4VFjauDsmPt5QTyb/SpX/20hvTT3/QCbDJJiRu3
5Lf7RPMK63r+uFwLz58XrGJwimYdKCn67nC+o1k/j9Izc63+At9h0tU2XR2u7V8c
iuQaGkeBT/OjtVg6/IjCs4SbT24wbmP1LecUtQyFzZkHdNkdw7+67Ty2Y3jGE3GG
sCpU88b0PIh2pJ+4oJ28WwH2M55VnxuId5N0uosrAGSo/C1kYWY=
=CkK1
-----END PGP SIGNATURE-----
From errata-notices at freebsd.org Tue Aug 20 20:12:37 2019
From: errata-notices at freebsd.org (FreeBSD Errata Notices)
Date: Tue, 20 Aug 2019 20:12:37 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:17.ipfw
Message-ID: <20190820201237.56D781F761@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:17.ipfw Errata Notice
The FreeBSD Project
Topic: ipfw(8) jail keyword broken prior to jail startup
Category: core
Module: ipfw
Announced: 2019-08-20
Affects: FreeBSD 11.3
Corrected: 2019-08-15 17:40:48 UTC (stable/12, 12.0-STABLE)
2019-08-15 17:40:48 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:46:40 UTC (releng/11.3, 11.3-RELEASE-p3)
Note that this issue was introduced after the FreeBSD 11.2 and 12.0 releases.
FreeBSD 11.3 is the only affected release.
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
The ipfw(8) utility configures rules for the ipfw(4) firewall. The jail
keyword applies the rule for packets pertaining to the given jail, named by
the argument.
II. Problem Description
The jail argument no longer allowed jids to be specified before a jail was
created. Attempts to use the jail keyword in this scenario would result in
"jail not found" errors, when previously these rules would apply to
any jail with the given jid that was subsequently started.
III. Impact
The ipfw(4) firewall will reject rules that attempt to use the jail
keyword prior to jail startup, and these rules will not be applied.
IV. Workaround
The system administrator can apply jail-based firewall rules after jail
creation.
Systems that do not use ipfw(4) are not affected.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
Perform one of the following:
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
2) To update your 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/EN-19:17/ipfw.patch
# fetch https://security.FreeBSD.org/patches/EN-19:17/ipfw.patch.asc
# gpg --verify ipfw.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Restart jails to apply firewall rules, if required.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r351094
stable/11/ r351094
releng/11.3/ r351258
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1cPf5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cIDTg//ca9BaMVV04yzSaIqgcuxCs5nM6eQMJehRKWP+Ibt6bUUnUYlS8V1HOBD
eUS0eW9GiO2QkrVmttxrC2IwJSutVzUXMP/zkLEyb91LJ13+YkuLKSaj14pucA+S
VNy1CH8Sry/PnA+bcFQxgpTAl8EGaTAzT0znRgdvooe26JbHw0y8941t88Mr3giN
vCPnfAdaT0MjKSdKgykA+xKKgY1+fwA1vUFOYybNzg+eN10gU2qRQfksFc4VpnNd
7J3j5I2n/1Y1KxsbEagGXK0JOztZa1PhqsAYuj4iAMhM8Nw+vdAtVX8DYyqHEe2m
hjJyGPu1Lrihrx2PUH5GVv0KXHbLVRnZ/N7Xs3hPsUZWBuSrcU2r3cdqe1nB055D
PQMr6m+Ydr0DXnySShd5Kow26IBDVJQ+YrGkK88CdMT2YGnarqcg/RaT/eIoJ654
lKvl5XeOL/P9apU567HzYoAUVlvxMAD2pEd2+NGr9gi3bXfAg2Usjeekwo7BRRMo
Ddmec7Ql/wBU0RED67l+TYIM2IDNj5ofua6WrSrs8QCIeNXnYi8kBLTBwKBiz5Fw
scisoACv92zexrIpac1RoAT/+OdWUgwtCx7axyLybbEsAC2FDfSDVqlJfq0m+DFY
/R3Bezk1Ek+U4KUpQr6I1DSBU+1Uo8DljfwkwH8DVn+aWy3194Q=
=8VPw
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 20 20:12:53 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 20 Aug 2019 20:12:53 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:22.mbuf
Message-ID: <20190820201253.1EF2E1F87A@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:22.mbuf Security Advisory
The FreeBSD Project
Topic: IPv6 remote Denial-of-Service
Category: kernel
Module: net
Announced: 2019-08-20
Credits: Clement Lecigne
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-10 00:01:25 UTC (stable/12, 12.0-STABLE)
2019-08-20 17:49:33 UTC (releng/12.0, 12.0-RELEASE-p10)
2019-08-10 00:02:45 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:49:33 UTC (releng/11.3, 11.3-RELEASE-p3)
2019-08-20 17:49:33 UTC (releng/11.2, 11.2-RELEASE-p14)
CVE Name: CVE-2019-5611
For general information regarding FreeBSD Security Advisories, including
descriptions of the fields above, security branches, and the following
sections, please visit .
I. Background
mbufs are a unit of memory management mostly used in the kernel for network
packets and socket buffers. m_pulldown(9) is a function to arrange the data
in a chain of mbufs.
II. Problem Description
Due do a missing check in the code of m_pulldown(9) data returned may not be
contiguous as requested by the caller.
III. Impact
Extra checks in the IPv6 code catch the error condition and trigger a kernel
panic leading to a remote DoS (denial-of-service) attack with certain
Ethernet interfaces. At this point it is unknown if any other than the IPv6
code paths can trigger a similar condition.
IV. Workaround
For the currently known attack vector systems with IPv6 not enabled are not
vulnerable.
On systems with IPv6 active, IPv6 fragmentation may be disabled, or
a firewall can be used to filter out packets with certain or excessive
amounts of extension headers in a first fragment. These rules may be
dependent on the operational needs of each site.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Rebooting for 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-19:22/mbuf.patch
# fetch https://security.FreeBSD.org/patches/SA-19:22/mbuf.patch.asc
# gpg --verify mbuf.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r350828
releng/12.0/ r351259
stable/11/ r350829
releng/11.3/ r351259
releng/11.2/ r351259
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1cPgFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cK+4w/7BCGyLpeSCIaHMpKdZvSqKc6RptLyxPq1q6XO/5fUxQiBXuwxfZIUO45o
VyQCsuVf0QDeT/HaMJAdTr450RlSs1ozyzEmd2iLfwqmpc8JRemihrzHkNMfny1U
Y4ffN6zyrOLyFeyQcdbgHUKHwuAvGZFhR/PtPJfWDmULi0vW5PHBGjxOQmxKbbUr
6zcR+gKrm5E3vLW4vD2gvsB1RGyOzUBOaEeQU36LE1/W6hhgwtXAkZacEP+W4BiB
jPbG7u23C3a2KcRImCWM2vJ5dZFoa0Mz5+vHzaSMwPT49KRRRRkcd7+azqUfbGg0
k9Py6KuwGhclNmehpUth0NlvR89JV58Fbkh7TaCWHV51hAWoH/1EQdJNY9yb0eAZ
AgsvAiotWU1VNDcF2xWaf5m3VE87jl0/Bz9BgpVFI0kHuof4OwiG9PkdFI1q0Yl2
TdkksZj1iRETN8/Qt5HGzY1pGQFRc7b+nE9GIfIUcEH1B7d7Gb58DVElZ95Og+EF
bGwR6/e7r39mBsqs0qloYgk/2c6B4vuFyt8b9Yhuw4ns0SpO4cP9XYXawUff7+p3
oLo7dqPKn8fMRLhT0/QZfPRyluUshVvJW1Yg9HWdYMYm7wFAilemnMWMxJKIUOmt
pkQx3e6Tvk3VNkls4yv7GbApO5iMNXaBvC2JYMP0GUiQ1FOkB9M=
=ip7/
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 20 20:12:57 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 20 Aug 2019 20:12:57 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:23.midi
Message-ID: <20190820201257.767EF1F8B5@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:23.midi Security Advisory
The FreeBSD Project
Topic: kernel memory disclosure from /dev/midistat
Category: core
Module: sound
Announced: 2019-08-20
Credits: Peter Holm, Mark Johnston
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-20 17:53:16 UTC (stable/12, 12.0-STABLE)
2019-08-20 17:50:33 UTC (releng/12.0, 12.0-RELEASE-p10)
2019-08-20 17:54:18 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:50:33 UTC (releng/11.3, 11.3-RELEASE-p3)
2019-08-20 17:50:33 UTC (releng/11.2, 11.2-RELEASE-p14)
CVE Name: CVE-2019-5612
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
/dev/midistat is a device file which can be read to obtain a
human-readable list of the available MIDI-capable devices in the system.
II. Problem Description
The kernel driver for /dev/midistat implements a handler for read(2).
This handler is not thread-safe, and a multi-threaded program can
exploit races in the handler to cause it to copy out kernel memory
outside the boundaries of midistat's data buffer.
III. Impact
The races allow a program to read kernel memory within a 4GB window
centered at midistat's data buffer. The buffer is allocated each
time the device is opened, so an attacker is not limited to a static
4GB region of memory.
On 32-bit platforms, an attempt to trigger the race may cause a page
fault in kernel mode, leading to a panic.
IV. Workaround
No workaround is available. Custom kernels without "device sound"
are not vulnerable.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Rebooting for 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-19:23/midi.patch
# fetch https://security.FreeBSD.org/patches/SA-19:23/midi.patch.asc
# gpg --verify midi.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r351264
releng/12.0/ r351260
stable/11/ r351265
releng/11.3/ r351260
releng/11.2/ r351260
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1cPgVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cItmQ/9HL5BIP/QUvfcBbhZmZAXa7O7V9Em4auumaUWEPnUaAR0vNKZqMvFXNeN
v51/HOwCZte2fCgs8rxSH9ncQR+cUk/3nXO7PZ7pNPNfvuJoPlCV1rIuRrdwm14+
+pZIJpY65gmmXyh5Qa5cw41MEWuDcKluUg38zEROwBpX4h0J/ZuMSARn/s1jj/kJ
hy2yzgPTz8gAzkNd8OtQm1CHdFnKWabuAHBlltj9qIA3OvJL+TpIFmzU5jA7wO1n
w9GCcz73+IA1RZXu8vPsW9AEc/1LlUrNcyLmJ+bZjW9b7mY9dq+ackvULTzFV21u
5xW2FEX3EBr3kFSbWyIS9zuTX4InftoAr97CBxNMYa25/0En4Ri2rB3oH49BgqTb
sr6p5hO3ZB6gOfJIm3WeYIc9dXsqQcWC/Y8hp7zO/Ef29jBHaa76ZX3uGgKGgyoo
UcoEjIx4ZpiqQxUEigKdlpEQdUtCIOSZ1NjSYDRFuCURDI07o1Oi8/HSdb9tNRe4
IxfmT7G+oBGbhjZ/bziC/tZX/whXzBdo6eNIBC8XW8hrTDIXVCyqls3igiSqxoFA
WMpQN2gEZ6Yug0zpRCn4fj+dvBobpAle7F/gwZdFeWU/wtDiLQHnBOxPaobR56Qy
fIoVVGufmnjbSReSGh1WtFhDt+uJ8zal/EqGWi3IBIFpxjhAuP0=
=I8mB
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Tue Aug 20 20:13:02 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Tue, 20 Aug 2019 20:13:02 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-19:24.mqueuefs
Message-ID: <20190820201302.6F71D1F8EF@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:24.mqueuefs Security Advisory
The FreeBSD Project
Topic: Reference count overflow in mqueue filesystem 32-bit compat
Category: core
Module: kernel
Announced: 2019-08-20
Credits: Karsten K??nig, Secfault Security
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-20 17:45:22 UTC (stable/12, 12.0-STABLE)
2019-08-20 17:51:32 UTC (releng/12.0, 12.0-RELEASE-p10)
2019-08-20 17:46:22 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:51:32 UTC (releng/11.3, 11.3-RELEASE-p3)
2019-08-20 17:51:32 UTC (releng/11.2, 11.2-RELEASE-p14)
CVE Name: CVE-2019-5603
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
Note: This issue is related to the previously disclosed SA-19:15.mqueuefs.
It is another instance of the same bug and as such shares the same CVE.
I. Background
mqueuefs(5) implements POSIX message queue file system which can be used
by processes as a communication mechanism.
'struct file' represents open files, directories, sockets and other
entities.
II. Problem Description
System calls operating on file descriptors obtain a reference to
relevant struct file which due to a programming error was not always put
back, which in turn could be used to overflow the counter of affected
struct file.
III. Impact
A local user can use this flaw to obtain access to files, directories,
sockets, etc., opened by processes owned by other users. If obtained
struct file represents a directory from outside of user's jail, it can
be used to access files outside of the jail. If the user in question is
a jailed root they can obtain root privileges on the host system.
IV. Workaround
No workaround is available. Note that the mqueuefs file system is not
enabled by default.
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 i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "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-19:24/mqueuefs.patch
# fetch https://security.FreeBSD.org/patches/SA-19:24/mqueuefs.patch.asc
# gpg --verify mqueuefs.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r351255
releng/12.0/ r351261
stable/11/ r351257
releng/11.3/ r351261
releng/11.2/ r351261
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1cPglfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cIKGA/+Oh+ORvFs273SJwaYaf8LCJ21IJnzVxDp9vS6MSO79LmI6HeiqAy9apQs
Ec4zOXvE5MzYfA+E9jyRa6c4h7OY7uSSym15wCjLLi+DWPJ1lcCPAv01JuAgSw9E
GkLOprdk2aETTe1jc3DjXv0q56JZM79vegL2Nn/AJd7GZqSI4Qxf0M+87eWFMxd6
dFlvZtnh4QGuSC8w+ls5LpcGHfr8T6w4WwNv6hfvxu//Bg/6BRYKEIAnAu/P+udd
LrZO5lY9IwdaLQckk44nCr02lHVG/G3JgyW2iWAn5tm0CPkQmbawbc6V2WN+lwYf
ynn0ORfKWZpeLN6hd1QedlBhyEblUdjveVy9vaJI2KieHdRMlb56/HsPQqwZLdgV
QrpambGJ4J+48gYcgOXsOn52kIG7iKLfyEsiH4mrQtlZEjfluWt0cGcNuMLNqgPc
WZC1Kqpx3OI00u2M+85xnM8V4VL7iQnX7WWoe8qICZDksAsm4LDTwOP4HdfXkCgs
iSibovwF9ZcKwZjB8AZ+smjRyHGb2KEs+WlGI+ASE5UF8jYshCEZWKfJFd59BJZx
uw/lngCium0OgQ0Bzt0NnqR663kzSE1f7ZGLJtoc5+xaWbnTbifykYsM88hO/+/v
LH/fYRdgXkDTtShiMgppx/YrfTF33+hea18CdNdtdPJmH99lPmE=
=1dwe
-----END PGP SIGNATURE-----
From security-advisories at freebsd.org Thu Aug 22 19:26:11 2019
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Thu, 22 Aug 2019 19:26:10 +0000 (UTC)
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:23.midi
[REVISED]
Message-ID: <20190822192611.0104C500F@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-19:23.midi Security Advisory
The FreeBSD Project
Topic: kernel memory disclosure from /dev/midistat
Category: core
Module: sound
Announced: 2019-08-20
Credits: Peter Holm, Mark Johnston
Affects: All supported versions of FreeBSD.
Corrected: 2019-08-20 17:53:16 UTC (stable/12, 12.0-STABLE)
2019-08-20 17:50:33 UTC (releng/12.0, 12.0-RELEASE-p10)
2019-08-20 17:54:18 UTC (stable/11, 11.3-STABLE)
2019-08-20 17:50:33 UTC (releng/11.3, 11.3-RELEASE-p3)
2019-08-20 17:50:33 UTC (releng/11.2, 11.2-RELEASE-p14)
CVE Name: CVE-2019-5612
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
0. Revision history
v1.0 2019-08-20 Initial release.
v1.1 2019-08-21 Updated workaround.
I. Background
/dev/midistat is a device file which can be read to obtain a
human-readable list of the available MIDI-capable devices in the system.
II. Problem Description
The kernel driver for /dev/midistat implements a handler for read(2).
This handler is not thread-safe, and a multi-threaded program can
exploit races in the handler to cause it to copy out kernel memory
outside the boundaries of midistat's data buffer.
III. Impact
The races allow a program to read kernel memory within a 4GB window
centered at midistat's data buffer. The buffer is allocated each
time the device is opened, so an attacker is not limited to a static
4GB region of memory.
On 32-bit platforms, an attempt to trigger the race may cause a page
fault in kernel mode, leading to a panic.
IV. Workaround
Restrict permissions on /dev/midistat by adding an entry to
/etc/devfs.conf and restarting the service:
# echo "perm midistat 0600" >> /etc/devfs.conf
# service devfs restart
Custom kernels without "device sound" are not vulnerable.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot.
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
# shutdown -r +10min "Rebooting for 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-19:23/midi.patch
# fetch https://security.FreeBSD.org/patches/SA-19:23/midi.patch.asc
# gpg --verify midi.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
and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r351264
releng/12.0/ r351260
stable/11/ r351265
releng/11.3/ r351260
releng/11.2/ r351260
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl1d58xfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJ3pw//fbHMCysvmMh+2RZ47d4i9d61cdYEq51VUwT2Cp2pGz+mWAoac89c4k2v
coo+nuvsXfgNGjr6SHGjLw0kCjeJPdPBDstHLnrzqbmuUFeS8rbRS9AGySy8cW7Z
qYh8OuBPqczWRM2STtyIA1nuxrKBxpEKsWdCO41lTue/D6+1rPjFkRtzK5G/yNcJ
2gQjy8DKwX2RdUmjrWXoQbGheCKUz+euhkUOFHjiJYAdLAK4Bq+Dn/Nq36c6Dej0
wzYkeDwL+c/XxVPk1iucMJfDd+xrOi6HY4BLh4EFkJBKmQa6ciqa1B37ibARMtVb
QbGcjgoUQ1wJLxJEpD0JN5/Rbxg3KOq+8wH5if2pqW8Q9Ir89GNpbq2DjNVpBq28
1XEE0CpIJUsqZkSobkMlmwQkz4fYNm5PGkIxpVGAUUlhEpnPlHsIWX5ADhyUwS8y
qGkYWDrB7t5kn+66pwef6HOQdSA+76MdHzsb9NF+5ByvcgSqgEJqVpFs31+hAfTQ
fH+UefOm7E65GEARG8M2NUUQnMDY/GlXOaeVgbUu60FPbr3M3QlTuAZcBZZTwd+f
aDtQt4J2P33qfkJWoH4Lt5qNzcGkucFQliKZ0SI4W0IfpaqWlRTaUcaC6MZClgdN
hh/cTP3WruHVsgQKPPO1F1soFCP96cDI1LVeHiYYTLBX0n5JarQ=
=AI8Q
-----END PGP SIGNATURE-----
From trasz at freebsd.org Sun Aug 25 12:19:43 2019
From: trasz at freebsd.org (Edward Tomasz =?utf-8?Q?Napiera=C5=82a?=)
Date: Sun, 25 Aug 2019 12:19:43 -0000
Subject: [FreeBSD-Announce] FreeBSD Quarterly Status Report - Second Quarter
2019
Message-ID: <20190825121912.GA16278@v2>
FreeBSD Project Quarterly Status Report - 2nd Quarter 2019
This quarter our report includes some interesting topics easily
accessible to anyone, even if you are not a programmer: we report the
link to a presentation of the 2019 FreeBSD survey results at BSDCan
2019 and describe an interesting experience of a 3-person hackaton,
which might encourage you to host one yourself, possibly with more
participants. We also provide some up to date information about the
status of our IRC channels.
For those who have some more technical skills, we give some news about
the role of git in the FreeBSD project, describe the status of some
tools to hunt bugs or enhance security and announce a clone of sysctl.
Finally, those who are more experienced with programming will probably
be interested in the great work that has been done with drivers: in
particular, an aknowledgement is due to Alan Somers for having started
to bring up to date our FUSE implementation, which was about 11 years
behind. Other important improvements include a more user-friendly
experience with trackpoints and touchpads enabled by default, much low
level work on graphics, many new bhyve features, updates to the linux
compatibility layer, various kernel improvements.
Have a nice read!
-- Lorenzo Salvadore
__________________________________________________________________
FreeBSD Team Reports
* Continuous Integration
* FreeBSD Core Team
* FreeBSD Graphics Team status report
* IRC Admin
* Ports Collection
* Release Engineering Team
Projects
* bhyve - Live Migration
* bhyve - Save/Restore
* BIO_DELETE support for the swap pager
* ENA FreeBSD Driver Update
* FreeBSD SDIO and Broadcom FullMAC WiFi Support
* FUSE
* Fuzzing FreeBSD with syzkaller
* Kernel ZLIB Update
* Linux compatibility layer update
* Lock-less delayed invalidation for amd64 pmap
* Locking changes for vnodes during execve(2)
* Mellanox Drivers Update
* NFSv4.2 client/server implementation for FreeBSD
* NUMA awareness in the FreeBSD kernel
Architectures
* Broadcom ARM64 SoC support
* NXP ARM64 SoC support
Third-Party Projects
* Aberdeen Hackathon
* Bring more Security Intelligence to FreeBSD
* libvdsk - QCOW2 implementation
* nsysctl 1.0
__________________________________________________________________
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in
the Administration Page.
Continuous Integration
Links
FreeBSD Jenkins Instance
URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive
URL: https://artifact.ci.FreeBSD.org/
FreeBSD Jenkins wiki
URL: https://wiki.freebsd.org/Jenkins
freebsd-testing Mailing List
URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing
freebsd-ci Repository
URL: https://github.com/freebsd/freebsd-ci
Tickets related to freebsd-testing@
URL: https://preview.tinyurl.com/y9maauwg
Hosted CI wiki
URL: https://wiki.freebsd.org/HostedCI
FreeBSD CI weekly report
URL: https://hackfoldr.org/freebsd-ci-report/
Contact: Jenkins Admin
Contact: Li-Wen Hsu
The FreeBSD CI team maintains continuous integration system and related
tasks for the FreeBSD project. The CI system regularly checks the
committed changes can be successfully built, then performs various
tests and analysis of the results. The results from build jobs are
archived in an artifact server, for the further testing and debugging
needs. The CI team members examine the failing builds and unstable
tests, and work with the experts in that area to fix the code or adjust
test infrastructure. The details are of these efforts are available in
the weekly CI reports.
The FCP for CI policy is in "feedback" state, please provide any
comments to freebsd-testing@ or other suitable lists.
We had a testing working group in 201905 DevSummit
Please see freebsd-testing@ related tickets for more information.
Work in progress:
* Fixing the failing test cases and builds
* Adding drm ports building test against -CURRENT
* Adding powerpc64 tests job:
https://github.com/freebsd/freebsd-ci/pull/33
* Implementing automatic tests on bare metal hardware
* Extending and publishing the embedded testbed
* Planning for running ztest and network stack tests
* Help more 3rd software get CI on FreeBSD through a hosted CI
solution
__________________________________________________________________
FreeBSD Core Team
Contact: FreeBSD Core Team
The FreeBSD Core Team is the governing body of FreeBSD.
* Core approved source commit bits for Doug Moore (dougm), Chuck
Silvers (chs), Brandon Bergren (bdragon), and a vendor commit bit
for Scott Phillips (scottph).
* The annual developer survey closed on 2019-04-02. Of the 397
developers, 243 took the survey with an average completion time of
12 minutes. The public survey closed on 2019-05-13. It was taken by
3637 users and had a 79% completion rate. A presentation of the
survey results took place at BSDCan 2019.
* The core team voted to appoint a working group to explore
transitioning our source code 'source of truth' from Subversion to
Git. Core asked Ed Maste to chair the group as Ed has been
researching this topic for some time. For example, Ed gave a
MeetBSD 2018 talk on the topic.
There is a variety of viewpoints within core regarding where and how to
host a Git repository, however core feels that Git is the prudent path
forward.
* The project received many Season of Docs submissions and picked a
top candidate. Google will announce the accepted technical writer
projects on 2019-08-06. We are hoping for lots of new and refreshed
man pages.
__________________________________________________________________
FreeBSD Graphics Team status report
Links
Project GitHub page
URL: https://github.com/FreeBSDDesktop
Contact: FreeBSD Graphics Team
Contact: Niclas Zeising
The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD
graphics stack. This includes graphics drivers, graphics libraries such
as the MESA OpenGL implementation, the X.org xserver with related
libraries and applications, and Wayland with related libraries and
applications.
In the last report, half a year ago, several updates and changes had
been made to the FreeBSD graphics stack.
To further improve the user experience, and to improve input device
handling, evdev was enabled in the default configuration in late 2018.
Building on that, we have enabled IBM/Lenovo trackpoints and elantech
and synaptics touchpads by default as well.
The input device library libinput has been updated as the last in a
series of updates bringing the userland input stack up to date. This is
work that was started in 2018.
We have made several improvements to the drm kernel drivers. A
long-standing memory leak in the Intel (i915) driver has been fixed,
and several other updates and improvements have been made to the
various drm kernel driver components.
A port of the drm kernel drivers using the 5.0 Linux kernel sources has
been created and committed to FreeBSD ports as graphics/drm-devel-kmod.
This driver requires a recent Linux KPI and is only available on recent
versions of FreeBSD CURRENT.
This version of the driver contains several development improvements.
The generic drm (drm.ko) driver as well as the i915 (i915kms.ko) driver
can now be unloaded and reloaded to ease in development and testing.
This causes issues with the virtual consoles, however, so an SSH
connection is recommended. To aid debugging i915kms.ko use of debugfs
has been improved, but there are still limitations preventing it from
being fully functional. Since debugfs is based on pseudofs it is
possible that this will prevent a fully functional debugfs in its
current state, so we might have to look into adding the required
functionality to pseudofs or use another framework.
The new in-kernel drm driver for VirtualBox, vboxvideo.ko has been
ported from Linux. Support is currently an experimental work in
progress. For example the virtual console won't update after loading
the driver, but X- and Wayland-based compositors are working.
Mesa has been updated to 18.3.2 and switched from using devel/llvm60 to
use the Ports default version of llvm, currently devel/llvm80.
Several userland Xorg drivers, applications, and libraries have been
updated, and other improvements to the various userland components that
make up the Graphics Stack have been made.
We have also continued our regularly scheduled bi-weekly meetings,
although work remains in sending out timely meeting minutes afterwards.
People who are interested in helping out can find us on the
x11 at FreeBSD.org mailing list, or on our gitter chat:
https://gitter.im/FreeBSDDesktop/Lobby. We are also available in
#freebsd-xorg on EFNet.
We also have a team area on GitHub where our work repositories can be
found: https://github.com/FreeBSDDesktop
__________________________________________________________________
IRC Admin
Contact: IRC Admin
The FreeBSD IRC Admin team manages the FreeBSD Project's presence and
activity on the freenode IRC network, looking after:
* Registration and management of channels within the official
namespace (#freebsd*)
* Channel moderation
* Liaising with freenode staff
* Allocating freebsd/* hostmask cloaks for users
* General user support relating to channel management
While the FreeBSD Project does not currently endorse IRC as an official
support channel (see here and here), as it has not been able to
guarantee a consistent or positive user experience, IRC Admin has been
working toward creating a high quality experience, by standardising
channel administration and moderation expectations, and ensuring the
projects ability to manage all channels within its namespace.
In the last quarter, IRC Admin:
* Cleaned up (deregistered) registrations for channels that were
defunct, stale, out of date, or had founders that were inactive
(not seen for > 1 year). Channels that were found to be otherwise
active have been retained. FreeBSD now has ~40 channels registered
from a previous total of over 150.
* Documented baseline configuration settings in the Wiki for
channels, including ChanServ settings, channel modes, registration
policy, etc.
* Established multiple documented methods for reporting user abuse or
other channel issues to IRC Admin for resolution
Upcoming changes:
* Work with existing #freebsd* channels to standardise channel
management, settings and access.
* Migrate, forward and/or consolidate existing or duplicate #freebsd*
channels to channels with a standard naming convention.
* Work with unofficial ##freebsd* channels to migrate them to the
official #freebsd* channels if suitable
* Update existing IRC-related website and documentation sources the
describe the official state of project managed IRC presence on
freenode.
Lastly, and to repeat a previous call, while the vast majority of the
broader user community interacts on the freenode IRC network, the
FreeBSD developer presence still needs to be significantly improved on
freenode.
There are many opportunities to be had by increasing the amount and
quality of interaction between FreeBSD users and developers, both in
terms of developers keeping their finger on the pulse of the community
and in encouraging and cultivating greater contributions to the Project
over the long term.
It is critical to have a strong developer presence amongst users, and
IRC Admin would like again to call on all developers to join the
FreeBSD freenode channels to increase that presence.
Users are invited to /join #freebsd-irc on the freenode IRC network if
they have questions, ideas, constructive criticism, and feedback on how
the FreeBSD Project can improve the service and experience it provides
to the community on IRC.
__________________________________________________________________
Ports Collection
Links
About FreeBSD Ports
URL: https://www.FreeBSD.org/ports/
Contributing to Ports
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html
FreeBSD Ports Monitoring
URL: http://portsmon.freebsd.org/index.html
Ports Management Team:
URL: https://www.freebsd.org/portmgr/index.html
Contact: Ren? Ladan
Contact: FreeBSD Ports Management Team
The following was done during the last quarter by portmgr to keep
things in the Ports Tree going:
During the last quarter the number of ports rose to just under 37,000.
At the end of the quarter, there were 2146 open PRs and 7837 commits
(excluding 499 on the quarterly branch) from 172 committers. This shows
a slight decrease in activity compared to previous quarter.
People come and go, last quarter we welcomed Pedro Giffuni (pfg@),
Piotr Kubaj (pkubaj@) and Hans Petter Selasky (hselasky@). Pedro and
Hans Petter were already active as src committers. We said goodbye to
gordon@, kan@, tobez@, and wosch at .
On the infrastructure side, a new USES=cabal was introduced and various
default versions were updated: MySQL to 5.7, Python to 3.6, Ruby to
2.5, Samba to 4.8 and Julia gained a default version of 1.0. The web
browsers were also updated: Firefox to 68.0 and Chromium to
75.0.3770.100
During the last quarter, antoine@ ran a total of 41 exp-runs to test
various package updates, bump the stack protector level to "strong",
switch the default Python version to 3.6 as opposed to 2.7, remove
sys/dir.h from base which has been deprecated for over 20 years, and
convert all Go ports to USES=go.
__________________________________________________________________
Release Engineering Team
Links
FreeBSD 11.3-RELEASE schedule
URL: https://www.freebsd.org/releases/11.3R/schedule.html
FreeBSD 11.3-RELEASE announcement
URL: https://www.freebsd.org/releases/11.3R/announce.html
FreeBSD 12.1-RELEASE schedule
URL: https://www.freebsd.org/releases/12.1R/schedule.html
FreeBSD development snapshots
URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/
Contact: FreeBSD Release Engineering Team
The FreeBSD Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes and maintaining the respective branches, among
other things.
During the second quarter of 2019, the FreeBSD Release Engineering team
started the 11.3-RELEASE cycle, with the code slush starting May 3rd.
Throughout the cycle, there were three BETA builds and three RC builds,
all of which in line with the originally-published schedule. The final
RC build started June 28th, with the final release build targeted for
July 5th.
FreeBSD 11.3-RELEASE will be the fourth release from the stable/11
branch, building on the stability and reliability of 11.2-RELEASE.
The FreeBSD Release Engineering Team also published the schedule for
the 12.1-RELEASE, targeted to start September 6th. One important thing
to note regarding the published schedule is it excludes a hard freeze
on the stable/12 branch, as a test run for eliminating code freezes
entirely during a release cycle. Commits to what will be the
releng/12.1 branch will still require explicit approval from the
Release Engineering Team, however.
Additionally throughout the quarter, several development snapshots
builds were released for the head, stable/12, and stable/11 branches.
Much of this work was sponsored by the FreeBSD Foundation and Rubicon
Communications, LLC (Netgate).
__________________________________________________________________
Projects
Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.
bhyve - Live Migration
Links
Github wiki - How to Live and Warm Migrate a bhyve guest
URL: https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migration-using-bhyve
Github - Warm Migration branch
URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration
Github - Live Migration branch
URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration_dev
Contact: Elena Mihailescu
Contact: Darius Mihai
Contact: Mihai Carabas
The Migration feature uses the Save/Restore feature to migrate a bhyve
guest from a FreeBSD host to another FreeBSD host. To migrate a bhyve
guest, one needs to start an empty guest on the destination host from a
shared guest image using the bhyve tool with the -R option followed by
the source host IP and the port to listen to migration request. On the
source host, the migration is started by executing the bhyvectl command
with the --migrate or --migrate-live option, followed by the
destination host IP and the port to send to the messages.
New features added:
* Clear the dirty bit after each migration round
* Extend live migration to highmem segment
Future tasks:
* Refactor live migration branch
* Rebase live migration
* Extend live migration to unwired memory
This project was sponsored by Matthew Grooms.
__________________________________________________________________
bhyve - Save/Restore
Links
Github repository for the snapshot feature for bhyve
URL: https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_snapshot
Github wiki - How to Save and Restore a bhyve guest
URL:
https://github.com/FreeBSD-UPB/freebsd/wiki/Save-and-Restore-a-virtual-machine-using-bhyve
Github wiki - Suspend/resume test matrix
URL: https://github.com/FreeBSD-UPB/freebsd/wiki/Suspend-Resume-test-matrix
Phabricator review - bhyve Snapshot Save and Restore
URL: https://reviews.freebsd.org/D19495
Contact: Elena Mihailescu
Contact: Darius Mihai
Contact: Mihai Carabas
The Save/Restore for bhyve feature is a suspend and resume facility
added to the FreeBSD/amd64's hypervisor, bhyve. The bhyvectl tool is
used to save the guest state in three files (a file for the guest
memory, a file for the states of various devices and the state of the
CPU, and another one for some metadata that is used in the restore
process). To suspend a bhyve guest, the bhyvectl tool must be run with
the --suspend option followed by the guest name.
To restore a bhyve guest from a checkpoint, one simply has to add the
-r option followed by the main state file (the same file that was given
to the --suspend option for bhyvectl) when starting the VM.
New features added:
* Open ticket on Phabricator
* Apply feedback received from community
Future tasks:
* Add suspend/resume support for nvme
* Add suspend/resume support for virtio-console
* Add suspend/resume support for virtio-scsi
* Add TSC offsetting for restore for AMD CPUs
This project was sponsored by Matthew Grooms.
__________________________________________________________________
BIO_DELETE support for the swap pager
Contact: Doug Moore
Contact: Alan Cox
Contact: Mark Johnston
An ongoing project aims to teach the swap pager to send SCSI UNMAP or
ATA TRIM commands to the swap device when a block of swap space has
been freed, for example when the application owning that block is
exiting.
SSDs have become commonplace and feature low latency for random I/O
requests. This makes them appealing for use as swap devices, since
lower latencies mean that applications spend less time blocked while
waiting for a page-in from the swap device. To maximize write
performance, some SSDs require the operating system to send a
notification to the disk when a sector is no longer in use; this helps
the disk optimize their usage of NAND flash cells. In FreeBSD such a
notification is called a BIO_DELETE.
FreeBSD's UFS and ZFS filesystems have for a long time been able to
transmit BIO_DELETE requests to the devices backing the filesystem. For
example, for UFS this support is enabled by specifying -t in newfs(8)
or tunefs(8)'s parameters. However, FreeBSD has historically not had a
corresponding implementation for swap devices.
Thanks to Doug Moore, as of r349286 in -CURRENT and r349930 in
stable/12 swapon(8) can send BIO_DELETE to all blocks on the specified
device immediately prior to configuring it as a swap device. This is
enabled by specifying -E in the swapon(8) parameters, or by adding the
"trimonce" option to the swap device's /etc/fstab entry. Some
in-progress work on the swap pager implements online block deletion, in
which BIO_DELETE is transmitted for blocks as they are freed by
applications; this will hopefully be implemented in FreeBSD 13.0.
__________________________________________________________________
ENA FreeBSD Driver Update
Links
ENA README
URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README
Contact: Michal Krawczyk
Contact: Maciej Bielski
Contact: Marcin Wojtas
ENA (Elastic Network Adapter) is the smart NIC available in the
virtualized environment of Amazon Web Services (AWS). The ENA driver
supports multiple transmit and receive queues and can handle up to 100
Gb/s of network traffic, depending on the instance type on which it is
used.
ENAv2 has been under development for FreeBSD, similar to Linux and
DPDK. Since the last update internal review and improvements of the
patches were done, followed by validation on various AWS instances.
Completed since the last update:
* Upstream of the ENAv2 patches - revisions r348383 - r348416
introduce a major driver upgrade to version v2.0.0. Along with
various fixes and improvements, the most significant features are
LLQ (Low Latency Queues) and independent queues reconfiguration
using sysctl commands.
* Implement NETMAP support for ENA
Todo:
* Internal review and upstream of NETMAP support
This project was sponsored by Amazon.com Inc.
__________________________________________________________________
FreeBSD SDIO and Broadcom FullMAC WiFi Support
Links
FreeBSD Wiki SDIO page
URL: https://wiki.freebsd.org/SDIO
Contact: Bjoern Zeeb
SDIO is an interface designed as an extension to SD Cards to allow
attachments of various other peripherals, e.g., WiFi or Bluetooth.
Work has been ongoing by Ilya Bakulin on the MMCCAM stack to provide
the infrastructure to be able to have SD cards and SDIO devices
attached side-by-side facilitating FreeBSD's CAM framework. Based on
this excellent work over the last years, SDIO support was finished
earlier this year and committed to FreeBSD HEAD with the intention to
merge to 12 at a later time.
Facilitating the newly available SDIO bus, work started to port
Broadcom's FullMAC WiFi driver. This work is still in progress and
expected to complete later this year. With this WiFi support for the
Raspberry Pi and other embedded boards will become available. Likewise
drivers for other SDIO devices can be developed now.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
FUSE
Contact: Alan Somers
FUSE (File system in USErspace) allows a userspace program to implement
a file system. It is widely used to support out-of-tree file systems
like NTFS, as well as for exotic pseudo file systems like sshfs.
FreeBSD's fuse driver was added as a GSoC project in 2012. Since that
time, it has been largely neglected. The FUSE software is buggy and
out-of-date. Our implementation is about 11 years behind.
During Q2 I nearly finished the FUSE overhaul that I begain in Q1. I
raised the protocol level from 7.8 to 7.23, fixed many bugs (see
199934, 216391, 233783, 234581, 235773, 235774, 235775, 236226, 236231,
236236, 239291, 236329, 236379, 236381, 236405, 236327, 236466, 236472,
236473, 236474, 236530, 236557, 236560, 236647, 236844, 237052, 237181,
237588, and 238565), and added the following features:
* Optional kernel-side permissions checks (`-o default_permissions`)
* Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
* Allow interrupting FUSE operations
* Support named pipes and unix-domain sockets in fusefs file systems
* Forward UTIME_NOW during utimensat(2) to the daemon
* kqueue support for /dev/fuse
* Allow updating mounts with mount -u
* Allow exporting fusefs file systems over NFS
* Server-initiated invalidation of the name cache or data cache
* Respect RLIMIT_FSIZE
* Try to support servers as old as protocol 7.4
I also added the following performance enhancements:
* Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
* Cache file attributes
* Cache lookup entries, both positive and negative
* Server-selectable cache modes: writethrough, writeback, or uncached
* Write clustering
* Readahead
* Use counter(9) for statistical reporting
All that remains is to finish merging the branch, and deal with any
newly introduced bugs.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Fuzzing FreeBSD with syzkaller
Links
syzkaller
URL: https://github.com/google/syzkaller
Contact: Mark Johnston
Contact: Andrew Turner
Contact: Michael Tuexen
Contact: Ed Maste
See the syzkaller entry in the 2019q1 quarterly report for an
introduction to syzkaller.
syzkaller continues to find FreeBSD kernel bugs. A number of such bugs
have been fixed in the past quarter, and we continue to investigate and
fix bug reports from syzkaller. Work to extend syzkaller's capabilites
has progressed: Andrew Turner has implemented support for fuzzing the
32-bit compatibility layer in amd64 kernels, helping illuminate some of
the darker corners of the kernel, and it is now possible to use bhyve
as a VM backend to syzkaller, so it is now efficient and convenient to
fuzz FreeBSD on FreeBSD.
Some planned work includes: enabling the use of ZFS as the base
filesystem for fuzzer VMs; extending the range of system calls and
ioctls covered by syzkaller; enabling LLVM sanitizers in the kernel so
as to catch more issues; and making use of netdump(4) to capture kernel
dumps for panics found by syzkaller, making it much easier to diagnose
bugs for which syzkaller was unable to find a reproducible test case.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Kernel ZLIB Update
Links
Review D19706
URL: https://reviews.freebsd.org/D19706
Contact: Yoshihiro Ota
Kernel zlib upgrade is in progress.
Xin (delphij@) and I have been working closely for zlib upgrade. We
relocated contrib/zlib to sys/contrib/zlib in order for kernel code to
access zlib in the tree. We also deleted dead code that depended on
zlib and inflate - inflate is a fork of unzip to uncompress gzip files.
We also renamed crc.h to avoid conflicts with zlib/crc.h.
Next goal is to compile both old zlib and new zlib into the kernel
allowing to switch each zlib user independently.
__________________________________________________________________
Linux compatibility layer update
Contact: Edward Tomasz Napierala
The project aims to improve the Linux compatibility layer, to make it
more compatible with recent Linux releases, and also to lower the bar
for potential developers who want to start contributing to it.
The initial effort focused on tooling, to make it easier to debug
problems and to prevent future regressions. The first part involved
making it possible to use Linux strace(1) utility and providing it as
linux-c7-strace package. The reason is that while FreeBSD truss(1) and
ktrace(1) can trace Linux binaries, they cannot decode Linux-specific
flags and structures.
The second part involved providing Linux Test Project binaries as
linux-ltp package. There is ongoing work to hook it up to the FreeBSD
CI infrastructure http://ci.FreeBSD.org.
There was also a number of improvements and fixes to bugs discovered in
the process. One of them (not yet committed) fixes binaries linked
against newer version of libc, effectively unbreaking binaries from
recent Ubuntu releases.
This project was sponsored by FreeBSD Foundation.
__________________________________________________________________
Lock-less delayed invalidation for amd64 pmap
Contact: Konstantin Belousov
The Virtual Memory machine-dependent layer (pmap) on amd64 needs to
track all mappings for the managed physical memory pages, to be able to
either destroy all of them (for page-out), or change them from
writeable to read-only (e.g. to sync the page content to file, without
racing with modifications through user writes). The mappings are
accounted by creating pv_entry which records the address space
(implicitly, by linking the pv entry to pmap) and the virtual address
of the mapping.
Previous work split the lock protecting the pv entries lists from other
VM locks into the pvh_global_lock lock, which was global for all
address spaces. You can see it in i386 pmap.c still. Later, hashed
per-page pv lists locks were introduced, which would reduce contention
on pv lists maninulations for different pages, but unfortunately the
pvh_global_lock was still needed to guarantee the safety of some
operations.
Problem arises because amd64 pmap uses pmap lock to protect page tables
and TLB consistency, which is per-pmap locks different from pv lists
locks. When updating page table entry, we never drop pmap lock until
the necessary TLB invalidation is done globally, including signalling
other CPUs with IPI. But pv list locks can be unlocked before the
necessary invalidation is done. So for instance when pmap is asked to
remove all mappings of the specific page (pmap_remove_all(9)), it
checks pv list of the page to find the mappings. The list might appear
empty despite other CPUs TLB were not yet invalidated. If such page is
reused, other CPUs might change its content using cached TLB entries.
Allowing that means allowing both silent data corruption and opening
security hole.
So the global pvh lock was held until all pmaps invalidated their TLBs.
This mechanism has obvious scalability issues, and instead a
generation-count based scheme for handling delayed invalidation (DI)
was developed, where each thread that might remove entry from pv list
acquired a generation number and marked the page with it, see
pmap_delayed_invl_page(9). Then, on e.g. pmap_remove_all(9) or
pmap_remove_write(9), pmap code waits for the maximum current thread's
invalidation generation number to pass the page's generation, which
guarantees that all required TLB invalidations are done.
Original implementation of DI allowed to get rid of pvh_global_lock,
and only used a private mutex to handle sequential queueing of the
coming and leaving threads, protecting a bounded region. A problem with
that appeared e.g. in scalability benchmarks which did massive parallel
unmaps, causing most of the threads to contend on DI queueing.
Current implementation of DI switched to lock-less queue algorithm
using the approach proposed by T.L. Harris and relying on double-CAS to
coalesce generation count and queueing. It uses ifuncs to select either
previous locked DI or current lock-less implementation, only old AMD
Athlons which did not implemented the CMPXCHG16B instruction falls to
the locked implementation by default. Lock-less implementation still
blocks the waiting thread on turnstile to avoid priority-inversion
issues, but practically the wait occur very rare, typical parallel
buildworld generates single-digit number of the events.
The patch got a lot of testing from Peter Holm, continuous reviews by
Mark Johnston while I worked out bugs and live-lock problems in the
implementation, and additional testing by Mateusz Guzik who helped to
identify a priority inversion bug with the wait.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Locking changes for vnodes during execve(2)
Contact: Konstantin Belousov
The execve(2) family of syscalls replaces the executing image in the
current process. The file containing the program text, data, and
arbitrary other pre-initialized segments for the newly activated image
is usually called the text file. FreeBSD marks the text file as such,
the mark is mutually exclusive with any opening of the file for write.
In other words, file opened for write cannot be executed, and text file
cannot be opened for write.
During the execve(2) syscall processing, kernel needs to lock the text
file' vnode. This is done both to satisfy the VFS calls protocol, and
to ensure that there is no incompatible parallel changes occuring to
the text vnode. A vnode can be locked either in exclusive mode, which
is mutually incompatible with any other lock acquisition, or in shared
mode, which is only incompatible with exclusive requests, but allows
other shared owners.
In principle, there is no reason why would execve(2) need an exclusive
vnode lock, since it does not modify neither content nor metadata for
the text vnode. The only exception is the marking of the vnode as text,
which was done using VV_TEXT flag in v_vflag and protected by the vnode
lock. Since we modify v_vflag, the vnode lock protecting the
modification should be taken exclusive.
The end result is that execve(2)'s of the same file are serialized. For
instance, if user runs parallel build, which executes more than one job
for compiling, all invocation of the compiler are serialized during
execve(2).
The count of opens for write is contained in other struct vnode member
named v_writecount, which was protected by the vnode lock as well.
Since text is mutually exclusive with an open for write, I reused
v_writecount to indicate text references. Now, negative v_writecount
counts the number of text references. The v_writecount content is
literally protected by the vnode interlock, but normally all mutators
also own vnode lock at least in the shared mode.
This way, we no longer need to acquire exclusive text vnode lock during
execve(2), removing the serializing point. Additional positive effect
is that we started to account the precise number of text references on
the vnode. Before, we cleared VV_TEXT on the last unmap of the text
vnode, potentially allowing obscure DoS where mapping the text file
while it is executed prevented writes until the mapping is destroyed.
Now we mark the mappings for text explicitly in the vm_map_entry and
dereference v_writecount by +1 when such entry is unmapped.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Mellanox Drivers Update
Links
Mellanox OFED for FreeBSD Documentation
URL: http://www.mellanox.com/page/products_dyn?product_family=193&mtag=freebsd_driver
Contact: Slava Shwartsman Hans Petter Selasky Konstantin Belousov
The mlx5 driver provides support for ConnectX-4 [Lx], ConnectX-5 [Ex]
and ConnectX-6 [Dx] adapter cards. The mlx5en driver provides support
for Ethernet adapter cards, whereas mlx5ib driver provides support for
InfiniBand adapters and RDMA over Converged Ethernet (RoCE).
Following updates done in mlx5 drivers:
* 200Gb/s ConnectX-6 Ethernet: Added support for Mellanox Socket
Direct Adapters which allows, among the rest of the capabilities,
to run up to 200Gb/s on a PCIe Gen 3.0 on a LAG interface.
* Support for "BlueField" - Multicore System On A Chip: Added support
for RShim driver for BlueField Multicore System On A Chip(SOC). The
RShim driver provides access to the RShim resources on the
BlueField target accessible from an external host machine. The
current RShim version provides device files for boot image push and
virtual console access. It also creates virtual network interface
to connect to the BlueField target and provides access to internal
RShim registers.
* Firmware Burning and Diagnostics Tools: Added MSTFLINT to ports,
this package contains a burning and diagnostic tools for Mellanox
NICs. This package contains following tools: mstflint - Tools which
allows to query and burn firmware. mstconfig - This tool queries
and sets non-volatile configurable options for Mellanox HCAs.
mstregdump - This utility dumps hardware registers from Mellanox
hardware. mstmcra - This debug utility reads/writes a to/from the
device configuration register space. mstvpd - This utility dumps
the on-card VPD. and more.
* OFED-FreeBSD-v3.5.1 Upstream: Pushed upstream and MFCed
OFED-FreeBSD-v3.5.1 driver - more details on the content of this
update can be found in Mellanox OFED for FreeBSD documentation
page.
General updates:
* Submitted papers for EuroBSDcon for a joint talk with Netflix
titled "Kernel TLS and TLS Hardware Offload". The papers were
accepted.
* Mellanox is intensively working to improve its cooperation with the
FreeBSD community. As part of this effort, FreeBSD users are
invited to propose features and enhancements to further develop and
enrich the end-user experience. In addition, Mellanox continues to
identify and present the right solutions to meet customers' needs.
This project was sponsored by Mellanox Technologies.
__________________________________________________________________
NFSv4.2 client/server implementation for FreeBSD
Links
current sources
URL: https://svnweb.freebsd.org/base/projects/nfsv42
Contact: Rick Macklem
NFSv4.2 is a newer minor version of NFSv4, made up of a set of optional
operations/features. A majority of these operations are related to the
POSIX operations posix_fadvise(2), posix_fallocate(2) and lseek(2)'s
support for SEEKHOLE/SEEKDATA. There is also a Copy operation that
allows a byte range of a file to be copied to another file locally on
the NFS server, avoiding data transfer over the wire in both
directions. FreeBSD-current now has a Linux compatible
copy_file_range(2) syscall that will invoke this Copy operation on
NFSv4.2 mounts. There is also support for MAC labelling, but it
requires changes to the RPCSEC_GSS implementation to add V3 support
and, as such, may not happen soon.
The implementation of NFSv4.2 (RFC-7862) is progressing nicely. At this
time, the LayoutError, IOAdvise, Allocate and Copy operations have been
implemented. There is still work to be done on Copy, to add
asynchronous support, so that large copies do not result in a long
delay for the RPC's reply.
The major operation that will be implemented next is Seek, so that
lseek(SEEKHOLE/SEEKDATA) will work for the NFSv4.2 mounts.
It is hoped that this implementation will be ready for
FreeBSD-current/head in time for the FreeBSD-13 release.
Testing is always appreciated and can be done by downloading the
modified kernel from the svn repository in base/rojects/nfsv42 and then
building and testing it on a couple of recent FreeBSD-current systems.
If anyone is conversant with Kerberos and wants to take on the
challenge of adding RPCSEC_GSS_V3 support to the kernel RPC, a patch
that does that would also be greatly appreciated.
__________________________________________________________________
NUMA awareness in the FreeBSD kernel
Contact: Jeff Roberson
Contact: Andrew Gallatin
Contact: Mark Johnston
A set of patches to improve the state of NUMA awareness in the FreeBSD
kernel are being developed and refined. This work also aims to
generally improve the performance of FreeBSD's memory management
subsystem on systems with many CPUs.
FreeBSD 12.0 featured a number of large changes which improve its
performance on systems with a non-uniform memory architecture. That is,
systems in which memory access latency for a given address varies
depending on the CPU. Another round of improvements is being developed
and will soon be available in FreeBSD-CURRENT. Short descriptions of
some of these patches follow; a few have already been committed to
FreeBSD-CURRENT.
In FreeBSD terminology, a memory page whose contents may not be evicted
is referred to as "wired." Pages may be wired under different
circumstances: for instance, all kernel memory is wired, and userland
applications may request that ranges of memory be wired using the
mlock(2) and mlockall(2) system calls. FreeBSD has historically defined
a system-wide limit on the number of wired pages so as to avoid
deadlocks that may arise when too much of a system's memory cannot be
reclaimed to satisfy new memory allocations. This limit was applied
only to userland wiring requests, but kernel wirings were counted
against the limit, so a large source of kernel wirings could cause
mlock(2) failures. This occurs frequently with a large ZFS ARC, for
example. In FreeBSD-CURRENT this limit has been changed such that only
userland wirings are counted against the limit; the kernel contains a
number of mechanisms to apply back-pressure to kernel memory usage, so
the use of a global limit on all wirings did not provide much benefit.
This fixes a common problem on large ZFS systems, and helps enable some
other architectural improvements to the code which manages page
wirings.
FreeBSD has historically maintained two separate reference counters in
the structure which describes a single physical page of memory. These
counters initially had quite different properties, but have over time
become more and more similar. Some work to merge the two counters has
landed in FreeBSD-CURRENT. This does not have any user-visible effects,
but it simplifies the page management code and removes a large amount
of code which existed solely to transform references of one type to the
other. Such code also made use of heavily contended locks, so the
simplification improved kernel scalability for some workloads and has
enabled further scalability improvements.
UMA is the slab allocator used in FreeBSD's kernel. It is the backend
which services virtually all dynamic memory allocations performed in
the kernel. The first round of NUMA improvements added NUMA awareness
to the "keg" layer of UMA, which allocates and manages slabs. However,
the frontend of UMA, which provides several layers of caching for
objects, did not provide domain-aware caching, so over time the caches
would become "polluted" with objects from different memory domains.
However, this caching layer is being modified to ensure that objects
from different memory domains are partitioned, helping ensure that
consumers can perform domain-local allocations and frees efficiently.
This will enable a global "first-touch" allocation policy for
UMA-managed objects.
During boot, the FreeBSD kernel allocates a number of static data
structures to track physical memory. These structures have historically
lived in the lowest available range of physical memory, so they many
not inhabit the same NUMA domain as the memory that they track. This is
suboptimal when one tries to affinitize a workload to a particular NUMA
domain: if while executing the workload the kernel frequently accesses
page structures for local memory, and the page structures themselves
are not placed in local memory, the kernel will perform many remote
memory accesses. Some in-progress work for the amd64 platform creates
multiple arrays of page tracking structures, one per NUMA domain, and
ensures that each array is local to its domain. This complicates the
task of initializing kernel data structures during boot, but can
substantially reduce the amount of cross-domain communication that
occurs while the kernel is performing useful work. Similarly, some
patches to affinitize per-CPU structures are being developed; while
most per-CPU memory allocations already return CPU-local memory, some
structures allocated during boot are not yet properly placed with
respect to the accessing CPU's memory domain.
This project was sponsored by Netflix.
__________________________________________________________________
Architectures
Updating platform-specific features and bringing in support for new
hardware platforms.
Broadcom ARM64 SoC support
Contact: Michal Stanek
Contact: Kornel Duleba
Contact: Marcin Wojtas
The Semihalf team continued working on FreeBSD support for the Broadcom
BCM5871X SoC series
BCM5871X are quad-core 64-bit ARMv8 Cortex-A57 communication processors
targeted for networking applications such as 10G routers, gateways,
control plane processing and NAS.
Completed since the last update:
* iProc PCIe root complex (internal and external buses): fixes and
improvements, including adding a BCM58712 quirk to GICv2m driver
* BNXT Ethernet support: sys/dev/bnxt.c driver has been extended to
support the BCM58700 variant, and the iflib was made to work
without IO cache coherency
In progress:
* Crypto engine acceleration for IPsec offloading.
Todo:
* Upstreaming of work. This work is expected to be submitted/merged
to HEAD in the second half of 2019.
This project was sponsored by Juniper Networks, Inc.
__________________________________________________________________
NXP ARM64 SoC support
Contact: Marcin Wojtas
Contact: Artur Rojek
The Semihalf team initiated working on FreeBSD support for the NXP
LS1046A SoC
LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with
integrated packet processing acceleration and high speed peripherals
including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide
range of networking, storage, security and industrial applications.
Already completed:
* Platform base support (ramp-up multi-user SMP operation with UART)
* SATA 3.0
In progress:
* USB3.0
* SD/MMC
* I2C
Todo:
* Ethernet support
* GPIO
* QSPI
* Upstreaming of developed features. This work is expected to be
submitted/merged to HEAD in the Q4 of 2019.
This project was sponsored by Alstom Group.
__________________________________________________________________
Third-Party Projects
Many projects build upon FreeBSD or incorporate components of FreeBSD
into their project. As these projects may be of interest to the broader
FreeBSD community, we sometimes include brief updates submitted by
these projects in our quarterly report. The FreeBSD project makes no
representation as to the accuracy or veracity of any claims in these
submissions.
Aberdeen Hackathon
At BSDCam in Cambridge last year we had a discussion to create a
template Hackathon in the same way we have a template for Devsummits.
To test out the idea I was convinced (I swear tricked is the correct
word) to host a Hackathon in Aberdeen.
As a project I think we benefit a lot from hackathons, but they do take
a little organisation. The worst part of this is dealing with getting
money from attendees so you can pay for events. I spoke with Deb
Goodkin from the foundation at BSDCam and we arranged to use their new
EventBrite based system to handle ticketing.
Overall this system made it straight forward for attendees to register
and get me their details and requirements. After the event the expenses
were then recouped from the foundation. This was much easier than me
putting together a custom system or even setting up and using
EventBrite myself.
The hackathon went well, you can read in Benedict and Kristof's reports
that follow, but it was less well attended than I originally expected.
For hackers planning future hackathons remember to take heed of common
national holidays (we could have planned the event to not land at
Easter) and expect major geopolitical events to make things
unpredictable (we knew Brexit would do something, but not when).
I need to thank the University of Aberdeen for providing the location
for the Hackathon and to encourage you to run a hackathon where you
are. The next one should be in your home town.
Benedict Reuschling
The hackathon in Aberdeen was happening in the week of Easter at the
University of Aberdeen. Although only Kristof Provost (kp@) and myself
joined our host Tom Jones, I still consider it a productive week for
us. The overall theme of the hackathon was networking and each of us
provided something towards that goal (be it PRs, submitting unfinished
work, or other bits and pieces). We got together the night of Tuesday,
April 16 over dinner and talked about what our plans were for the week.
Kristof and I had talked at AsiaBSDcon when I took his tutorial about
Testing in FreeBSD that we should add a chapter about it in the
developers handbook. We also used our first meeting to synchronize each
other about the latest news in FreeBSD from our developers viewpoint.
The next day, we met up at the Frazer Noble building where the
hackathon was taking place. It was one of the newer buildings on
campus, nicely integrated into the older houses of the city. Since we
were only a handful, we sat in Tom's office for the hackathon, which
had plenty of room. He also showed us the room where we are supposed to
be having the hackathon if we were more people and Tom gave us a little
tour. Working in a university myself, I'm always interested in how
other education organizations are structured and the rooms and
equipment they provide for learning. Overall, my impression was that
there is a good amount of space and equipment available, which we could
have used in the hackathon.
After returning, we decided to use a special tag in the commits we
would be doing to identify them as coming from this hackathon. We chose
"Event:" for it as it is a general enough term to be used at other
events like conferences, too. The "Sponsored by:" line we used in the
past is more for companies or individuals sponsoring certain features,
so I created a review to add this line to the committers guide.
Kristof had a couple of changes to the pf chapter in the FreeBSD
handbook for me, so I started going through those. I created a review
for him and the commit was made there and then, making use of the short
feedback cycle. Originally, we thought about bringing in people via
hangouts, but then resolved to contact people via our usual IRC channel
if we needed their input.
Kristof and Tom worked on some network specific stuff, whereas I
started work on creating an initial draft for the testing chapter. We
would occasionally start talking about something and then return to our
work in silence. If we needed to coordinate or had questions, we simply
asked and could continue once we got our answer. This provided a nice
atmosphere to work in. I tackled some doc PRs while Kristof found a bug
in pf and fixed it.
The afternoons were spent at different locations within walking
distance. Tom made sure we got a good impression on how it is to be a
student and that there is both taste and variety of food available. In
the evenings, Tom drove us into town to have dinner at various
restaurants over the week.
Aberdeen has a lot to offer as a city. Starting from the second day,
Kristof and I would meet up at my hotel, which was close to the
Aberdeen beach and walk along it to the University. According to Tom,
it is possible to see Dolphins when the weather is right and the gulf
stream provides the city with enough warmth that the winters aren't as
bad as you'd think this far up north.
Tom also gave us a tour of the zoological department of the university,
which offered a beautiful garden with various plants and trees, as well
as a museum with zoological specimen. This offered a great spot for
photographs and to unwind a bit from the technical discussions we've
had. Tom also had t-shirts made for the event, which are already rare
collectors items.
I had to return on Sunday, so Tom took us on a tour of the Scottish
highlands in his car the day before. We stopped at a couple of places
to take pictures and Tom would explain at lot to us having lived there
all his life. We came to Stonehaven and had fish and chips there from a
take-out restaurant that had a lot of awards for sustainable fishing.
This was certainly a highlight for the week and even then, we couldn't
stop talking about FreeBSD and networking.
Although more people would maybe have produced more output, the three
of us were certainly productive as a small group. It also made planning
and coordination easier and more flexible. Tom Jones had done a lot of
preparation and was an excellent guide. I would encourage him to host
another such hackathon in the future and hope that next time, more
people will take a trip to Aberdeen to spend some time hacking on
FreeBSD
Kristof Provost
While I'd been to Scotland before I'd never seen Aberdeen. It's a
charming city, and I enthusiastically recommend visiting.
I arrived a little while after Benedict, but made it to my hotel
easily, and turned up in time to join Benedict and Tom for dinner.
Despite being small (or perhaps because of it), the hackathon was
remarkably productive. Benedict and I went through the pf documentation
in the handbook, so that Benedict could rework and improve it.
(Benedict's doing the work, but I'm going to take credit anyway.)
Tom and I looked at the GSoC proposals and tried to find potential
mentors for two promising proposals. Both of us are candidate mentors
as well. We should know soon if our students are awarded slots.
Tom also proposed a patch to eliminate RFC 2675 IPv6 Jumbograms. It has
my enthusiastic support.
I managed to look at a couple of open pf issues:
* pfctl's interface_group() function checks if a name is an interface
or an interface group. It still thought that interface names always
ended with a number, but this assumption has been wrong for several
years now. That's fixed in r346370.
* The DIOCRSETTFLAGS ioctl() misused copyin() (It held a lock calling
it), which could result in panics.
* That previous issue was actually discovered by my local instance of
syzcaller, which I'd set up to add pf support to it. That support
has now been merged, so we may see more issues detected by
syzcaller soon.
* Also for the DIOCRSETTFLAGS problem I extended the pf tests to
check for this issue.
* The pf tests will now fail if the pft_set_rules call fails to set
the rules. That didn't actually cause issues yet, but it'll make
debugging tests slightly easier, and they may catch more problems
now.
On Saturday Tom took us out to discover some of the pretty bits of
Scotland. It turns out there are a lot of them. I can't really do it
justice, but Tom has a promising career at the Scottish tourism board
when this computers fad blows over.
On my way home I passed through Oslo, and took the opportunity to meet
with (have lunch with) two of the EuroBSDCon local organisers.
EuroBSDCon is filling up fast, make sure to register now to secure your
place!
__________________________________________________________________
Bring more Security Intelligence to FreeBSD
Links
Maltrail - distributed Malware detection
URL: https://github.com/stamparm/maltrail
Wazuh - thread detection and incident response
URL: https://wazuh.com/
Contact: Michael Muenz
To bring more Security Intelligence we maintain the FreeBSD port of
zmaltail. This open source project based on Python can act as a sensor
and/or as a central server. It listens in defined ports or protocols
and compares IP addresses and domains against static and dynamic feeds,
contributed by the community.
As you can install this piece of software on multiple firewalls and let
them send to a central server, you are able to detect attacks and
compromises very fast. Within Q2 we updated the port to the latest
version and are constantly in contact with the core developer (also
co-author of SQLmap) to bring out new features.
The second project we are currently trying to add as a port is Wazuh.
Wazuh is a fork of Ossec which is already in the ports tree. Compared
to Ossec, Wazuh has some intelligent addition like full ELK-Stack
integration with own apps and dashboards.
With Wazuh installed on your webserver, or even on your windows desktop
you can monitor file integrity or log files for most kind of attacks.
Active response features let you e.g. send API calls to your firewalls
to dynamically block this offender.
As Wazuh offers a complete ELK-Stack you can use it also as a central
logging solution for better security insights into your network.
This project was sponsored by m.a.x. Informationstechnologie AG.
__________________________________________________________________
libvdsk - QCOW2 implementation
Links
Github - libvdsk repo
URL: https://github.com/xcllnt/libvdsk
Contact: Sergiu Weisz
Contact: Marcel Molenaar
Contact: Marcelo Araujo
Contact: Mihai Carabas
Add support for using QCOW in bhyve using the libvdsk library. Libvdsk
was used to substitute the regular disk operations from bhyve with a
call to libvdsk which will in turn call the disk-specific handler for
the operation.
To use this feature one has to install the libvdsk-enabled bhyve
version along with libvdsk from the libvdsk repo linked above.
New features added:
* Extend libvdsk to make it easier to implement new formats
* Improve read/write performance and stability
* Add support for Copy-On-Write
Future tasks:
* Integrate libvdsk in bhyve
Matthew Grooms
__________________________________________________________________
nsysctl 1.0
Links
gitlab.com/alfix/nsysctl
URL: https://gitlab.com/alfix/nsysctl
sysutils/nsysctl port
URL: https://www.freshports.org/sysutils/nsysctl/
Tutorial
URL: https://alfix.gitlab.io/bsd/2019/02/19/nsysctl-tutorial.html
Contact: Alfonso Sabato Siciliano
The nsysctl utility is a /sbin/sysctl clone, to get or set the kernel
state, supporting libxo and extra options.
nsysctl [--libxo=opts [-r tagname]]
[-DdFGgIilmNpqTt[V|v[h[b|o|x]]]Wy]
[-e sep] [-B ] [-f filename]
name[=value[,value]] ...
nsysctl [--libxo=opts [-r tagname]]
[-DdFGgIlmNpqTt[V|v[h[b|o|x]]]Wy]
[-e sep] [-B ] -A|a|X
You could use nsysctl to explore the sysctl MIB showing the value and
the info of an object. The output is explicitly indicated by the
options and is printed via libxo in human and machine readable formats,
moreover some value is parsed to display it in a structured mode (e.g.,
vm.phys_free). The support for efi_map_header was added but it is
untested, someone could help by trying it via machdep.efi_map.
Please refer to the tutorial for a more thorough description.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: not available
URL: