FreeBSD Security Advisory FreeBSD-SA-26:72.bhyve

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:72.bhyve Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities in bhyve device models Category: core Module: bhyve Announced: 2026-10-14 Credits: Brian Delgado from Intel using Anthropic Opus 4.8 Credits: Claude and Ada Logics Credits: Joshua Rogers of AISLE Research Team Credits: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai Affects: All supported versions of FreeBSD. Corrected: 2026-10-14 16:03:00 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:40 UTC (releng/15.1, 15.1-RELEASE-p5) 2026-10-14 16:03:16 UTC (stable/14, 14.5-STABLE) 2026-10-14 16:04:14 UTC (releng/14.5, 14.5-RELEASE-p2) 2026-10-14 16:03:57 UTC (releng/14.4, 14.4-RELEASE-p11) CVE Name: CVE-2026-101309, CVE-2026-101310, CVE-2026-101311 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background bhyve(8) is a hypervisor that runs guest operating systems inside a virtual machine. II. Problem Description Several vulnerabilities were found in the bhyve hypervisor's device models. The xHCI (USB 3) device model did not validate or save the event ring size provided by the guest. The size was re-read from guest memory on each use, and Transfer Request Block (TRB) fields were loaded without protection against concurrent modification by the guest. This race condition could be triggered by a guest running malicious, privileged code. (CVE-2026-101309) The HDA audio device model did not check for zero-length Buffer Descriptor List (BDL) entries when starting a stream. A zero-length entry caused an out-of-bounds read or write during DMA transfer processing. BDL fields were also subject to modification by the guest after validation. (CVE-2026-101310) The framebuffer device model's maximum resolution constants were duplicated between the framebuffer and RFB modules and had gotten out of sync. Additionally, writes to the framebuffer BAR could set arbitrary width and height values without validation, and the framebuffer BAR I/O and RFB rendering threads were not synchronized. (CVE-2026-101311) III. Impact A malicious guest can crash the bhyve process or potentially execute arbitrary code in the host userspace context running the virtual machine, subject to bhyve's Capsicum sandbox. IV. Workaround No workaround is available. Virtual machines that provide none of the "xhci", "hda", and "fbuf" devices to guests are not affected. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Restart all bhyve virtual machines, or reboot the system. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base 2) To update your vulnerable system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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 15.x] # fetch https://security.FreeBSD.org/patches/SA-26:72/bhyve-15.patch # fetch https://security.FreeBSD.org/patches/SA-26:72/bhyve-15.patch.asc # gpg --verify bhyve-15.patch.asc [FreeBSD 14.x] # fetch https://security.FreeBSD.org/patches/SA-26:72/bhyve-14.patch # fetch https://security.FreeBSD.org/patches/SA-26:72/bhyve-14.patch.asc # gpg --verify bhyve-14.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart all bhyve virtual machines, or reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 07c15b75ff78 stable/15-n286008 releng/15.1/ febb02e3253c releng/15.1-n283638 stable/14/ fa7fe70671ee stable/14-n275355 releng/14.5/ 2e4ec07874a2 releng/14.5-n274893 releng/14.4/ 00ec12d48c63 releng/14.4-n273788 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://www.cve.org/CVERecord?id=CVE-2026-101309> <URL:https://www.cve.org/CVERecord?id=CVE-2026-101310> <URL:https://www.cve.org/CVERecord?id=CVE-2026-101311> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:72.bhyve.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwd8bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv2bwP/0+lymnNlkfbBG77FAa2 oaF/qeH2BOZ6ObCykMgevVuidI6NJQmaXrYfM3IaTla3+poi9UrInEz0ppGRpmar SJurTHSKfFMfs3javxDgbOl8bR5Sghi60wFkX0alhZmtQYms5nle+qBFf2rFyGSY I32W6wR+tTjH/Fp5kyqc/3j+CDrfnl2KFUJodu6gZbWIprPcoU+vIWVP3NH9hc68 RAOAyKXzgufOV+lyxyDbL8tCTO50W4sMvMeMxSguaffbfn/x0aG2Y6ohONAWdY0W 6rGrtDhqojg/zXWbau5tqFBLUy+Z+k7cCatr2TBGdHujvxTiQ7qV3taJGXol66yN K6PHRZzgYMcBE9eqjqxYMEr9pQyXHNLNspGnZxZVMSj/t4dD11MGV7GiG3jOL8Wz GBQIxE0ePvMYLudZPjsfrPmbAPTt1+KDq0ML/l7jFwGuDEbcsNum5IKtIGpkVmO3 ehrfIF8USvvsPrszviJ1bSorZsmAGoO1hO4JvvyxnO1WbMW+6TFV3KBl3Vuo3gVR gD9KRuM2aV3r4C5hRxTAx7386ryP6f0tR16JQo97O4pnFXz6SyNluWxdmf/3hkgo gOq9QCVxtBPL3k5TrCkz8dTpODz6Ji81NDLAADtK2M4+IPHV/5xMpLgXnfU9t/eV kCHlcMVuNaS38EzrcYtCWqQN =bQls -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:71.sound

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:71.sound Security Advisory The FreeBSD Project Topic: TOCTOU race between sound(4) buffer resizing and mmap Category: core Module: sound Announced: 2026-10-14 Credits: Hazley Samsudin of GovTech CSG Affects: All supported versions of FreeBSD. Corrected: 2026-10-14 16:02:57 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:37 UTC (releng/15.1, 15.1-RELEASE-p5) 2026-10-14 16:03:13 UTC (stable/14, 14.5-STABLE) 2026-10-14 16:04:10 UTC (releng/14.5, 14.5-RELEASE-p2) 2026-10-14 16:03:54 UTC (releng/14.4, 14.4-RELEASE-p11) CVE Name: CVE-2026-101308 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background FreeBSD provides audio support through the sound(4) driver, which presents each audio device as a set of character device nodes such as /dev/dsp. Applications can map a channel buffer via mmap(2) for low-latency audio I/O. II. Problem Description When an audio channel's buffer needs to be resized, the sound(4) driver checks that the buffer is not memory-mapped and then drops the channel lock to allocate a new buffer. An mmap(2) call on another thread can complete during this window, after which the resize path frees the now-mapped buffer without rechecking. III. Impact An unprivileged local user with access to a sound device can exploit this race to trigger a use-after-free in the kernel, potentially escalating privileges. IV. Workaround No workaround is available. Systems with no sound devices are unaffected. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 3) 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 15.x] # fetch https://security.FreeBSD.org/patches/SA-26:71/sound-15.patch # fetch https://security.FreeBSD.org/patches/SA-26:71/sound-15.patch.asc # gpg --verify sound-15.patch.asc [FreeBSD 14.x] # fetch https://security.FreeBSD.org/patches/SA-26:71/sound-14.patch # fetch https://security.FreeBSD.org/patches/SA-26:71/sound-14.patch.asc # gpg --verify sound-14.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 07eacba075ab stable/15-n286005 releng/15.1/ 908bde55f070 releng/15.1-n283635 stable/14/ d3b8957e2a82 stable/14-n275352 releng/14.5/ 658b24eba235 releng/14.5-n274890 releng/14.4/ ea6ecd1e3762 releng/14.4-n273785 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://www.cve.org/CVERecord?id=CVE-2026-101308> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:71.sound.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwdwbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvFyAQANMAY+KVmy+8+f7SBmeM scQrDyBXDF896i+sq3eaHDcx+gxrbQIIXWsO2oJ1fZOL15E1e/rSZGINWp/WzM3z xuUBaes3y84cTF0t7qOvDLCaYY/cWLcQzi0M6e/neCIlWYRLySQZtoBLW0JEBAa+ l+wkzvkNFwYXF+RchcdmHTXA9EXfOZWeb2dg97L5EPmI6LXbk7HgEEONoZQLNx+Q xVPbrXi5GMzwo+yurJ+FF1AMlQyIiWsxNy3qK4iNLMhrfc/Z3HSm4CvN1bVAVrMZ LpRNVKVcb6eyMI7A9a3SDeDsqaQ0CiFpasHwKyCHqANoI99Kd2qzKddZLxkK6Pqp yUH6+pBclL86jXatSN0oa27veNMe6KMXS0MqCBKnP8y1hsIsvJ6Omhh+a/70aPOu ZjhWmr1mHMST5wpqXc9yk82iESICYqxtTIbGzt3NSbjOkuwxrdGnNvJfGLPIfYZn EhVD/3yBeVbn8HHDA3p03Q/DJYcWm0sN2A7YLjX+ES/tRVKoJXHnupI6ljc5WQj9 LJx2jfs9ZJsjxlPksv5QxQmucCyylnBln75U85b6KnhQZH1I7akpimKvq8kM0X9C 5naxSM8P7T0mknElixq8JXf9kjFPEPI00jYqWhP6TGBiUYug48Mk0029mP52vyU0 SjKRu8UgqGFb94uCbEMoi+QC =ss5e -----END PGP SIGNATURE-----

FreeBSD Errata Notice FreeBSD-EN-26:27.tcp

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-26:27.tcp Errata Notice The FreeBSD Project Topic: TCP timers may overflow and fire late or not at all Category: core Module: tcp Announced: 2026-10-14 Credits: Lukas Book Affects: FreeBSD 15.1 and 14.4 Corrected: 2026-08-06 09:07:02 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:33 UTC (releng/15.1, 15.1-RELEASE-p5) 2026-08-06 05:55:09 UTC (stable/14, 14.5-PRERELEASE) 2026-10-14 16:03:51 UTC (releng/14.4, 14.4-RELEASE-p11) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background Each TCP connection maintains a set of timers, covering retransmission, persist, keepalive, 2MSL (TIME_WAIT and FIN_WAIT_2), and delayed ACK. Since FreeBSD 14.0, the default TCP stack multiplexes all of these timers onto a single callout(9) per connection. Whenever a timer is started or stopped, the stack selects the earliest pending timer, together with the allowed scheduling precision, and reschedules the callout accordingly. A stopped timer is marked by setting its expiry time to SBT_MAX. II. Problem Description When a timer was stopped, its previously computed precision was left in place. While selecting the next timer to schedule, the stack added that precision to the SBT_MAX expiry of the stopped timer, causing a signed integer overflow. The resulting negative value was then used to compute the precision passed to callout(9) for the connection's callout. III. Impact The per-connection callout may be scheduled with an invalid precision, causing TCP timers to run far later than intended. Affected connections may fail to retransmit, send keepalives, or leave TIME_WAIT and FIN_WAIT_2 in a timely manner, and can remain in the connection table indefinitely, consuming memory, protocol control blocks, and local ports. Affected connections can be recognized by negative or implausibly large values in the timer columns (rexmt, persist, keep, 2msl, delack) reported by "netstat -nxptcp". Only connections using the default FreeBSD TCP stack are affected. IV. Workaround Affected connections can be listed with netstat(1) and terminated with tcpdrop(8). The following prints the local and foreign endpoints of all connections with a negative value in any of the rexmt, persist, keep, 2msl, or delack timer columns: # netstat -nxptcp | \ awk 'NR > 2 && ($14 < 0 || $15 < 0 || $16 < 0 || $17 < 0 || $18 < 0) \ { print $4, $5 }' Review the output, then drop each connection by passing the two endpoints exactly as printed to tcpdrop(8), which accepts the netstat(1) address format directly, for example: # tcpdrop 192.0.2.1.80 198.51.100.7.53211 Note that connections whose timers have been deferred without becoming negative are not detected by this method, and that dropping a connection resets it for the peer. V. Solution Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) To update your system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base # shutdown -r +10min "Rebooting for an erratum fix" 2) To update your system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for an erratum fix" 3) 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-26:27/tcp.patch # fetch https://security.FreeBSD.org/patches/EN-26:27/tcp.patch.asc # gpg --verify tcp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ e8d1cee43741 stable/15-n284741 releng/15.1/ cf95af02eb15 releng/15.1-n283632 stable/14/ 85485a570d4f stable/14-n274777 releng/14.4/ 11f0c61eecb8 releng/14.4-n273783 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://reviews.freebsd.org/D58484> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-26:27.tcp.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwdcbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvwe8P/jP7gDz4gtYvhzd4W2v2 v02GxryG8zdoHTRdNh2T4ZGXrg1vLRCuINZazJWtZKXpWHTnFXluUXimpB6Gk8oP yBix+d/vgdB7H4OWkSn9PFqEcTtLDLxdLgVdyfYjugqG3hKE86op724sujWbcyKg mKjZNyk29NqXrH0gGiU/KzOI6iwHmsxJMeglk4Yw7z4cFf+NNslhZlKnH241aI1x SCTwm6vT8mdFc6h6vHQ77IMnNCzsGY8/BN3OtcCaFijB4gU/VsplwiZC3r+cUmnF aZLeabLGcmT1xemR4nDssI+qAc9+f6fuEi/enWoZFH6ZA8OFq6YubR9vjBQeslGW EApxRD/HoURuSwZCKwET7B6CZSWVeuGQya8bG86PbXDjAXQUhI7kG4LTFAkHAqoq zllJYxmKvBU3fZnJrcbVGD/39cMZ9XZYfEOfCrHMpCU0z+H2F7Q0TP88xRecbVsE 0Khk3CA8hdqHn7qKzgNHrGJ8jwNGZ8ms9+QIXtUeirSQGBK1gOwNFyf2ehwmo8S1 kb6FjcanX50PIJGKV3XMtyUBQFuBKxNxI/L/wjUUgCwcMTM8WEGjrTECO1O2+1ZX xhKf4WmiMy8cyoIqmCyzdcKtHYegVzpqr1XWjasYunAmKcyJVeQV02VBlB5TDc3I TIuOY6BPvFsN/4AOoY7eo0vy =Fmg2 -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:70.tcp

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:70.tcp Security Advisory The FreeBSD Project Topic: Remotely triggerable buffer overflow in tcp_rack Category: core Module: tcp_rack Announced: 2026-10-14 Credits: Raffaele Bova at Nozomi Networks Security Research Affects: FreeBSD 15.1 Corrected: 2026-10-14 16:02:55 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:34 UTC (releng/15.1, 15.1-RELEASE-p5) CVE Name: CVE-2026-101307 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background FreeBSD supports multiple pluggable TCP stacks. The RACK stack implements the Recent ACKnowledgment (RACK) loss detection algorithm and is provided as the loadable kernel module tcp_rack.ko. The RACK stack includes a path capacity measurement (PCM) module that records per-ACK samples in a dynamically growing array. II. Problem Description When the PCM sample array needs to grow, the RACK stack doubles a 16-bit allocation counter. Repeated doublings caused the counter to wrap to zero, resulting in a near-zero-length allocation followed by a copy of the existing samples into the undersized buffer. A remote peer can trigger the expansion by sending a sufficient number of ACKs on an established connection. III. Impact A remote attacker who can establish a TCP connection to a system using the RACK stack can trigger an out-of-bounds write of approximately 512 KB in the kernel heap possibly resulting in a kernel panic. IV. Workaround Systems that have not loaded the tcp_rack.ko kernel module are not affected. To check whether it is loaded, run: # kldstat -m tcp_rack The tcpsso(8) utility can be used to migrate existing TCP connections to a different TCP stack. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 3) 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-26:70/tcp.patch # fetch https://security.FreeBSD.org/patches/SA-26:70/tcp.patch.asc # gpg --verify tcp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 57818a298ee1 stable/15-n286003 releng/15.1/ 5dd20a06fe9e releng/15.1-n283633 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://www.cve.org/CVERecord?id=CVE-2026-101307> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:70.tcp.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwdkbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvxDcQANjx497pJcMBMEkbXX2y GgWhda1BNnenRPuIzZGREXGrP/XvcWCe55lIqE5yf2j5OoDNLm8+N5bog8l/qawd oK/M8FUdsoRawyr3PClHKinHYYhaHsLneih9RHeTbQEcyTHCyE+lbfOiE0+mMit3 I6F2Mj5K4m0bcCTyj52bjg+GgSZp0SWAlaEvg0FFBx5vAzql6BDPsPAO5Hz+3XmA 5OXz0feVLmAA9wqY/H8GVnZcK37ty80KAj/vNPpSiHFBimcl9GxyincukggpU0fH si9G1aAgik6lyQtv78J1n/roLKajBr43isEeKRi10LgYTlUy8w6Qd/acCU20EDay 9Ent9TJizJp8RkTsygooAMZS+gq2jowBiOXqpEfFzQq1fk/T77QavE082yOSkXy8 x8NXk3QVH6A7Fmbse2At/pVvcIboJyBQrqWy6GPZibf20Q5Uv1mU/5yx7nd0vNW9 JGFNhgQybTTrGpm10C/HReuMchtEgduFnxZVQLCF9+5egg9sBrhXcHuo5KQgYJIy UJDgEcvntvOKQiySZVMf0ICMsluSzLXqULX9RdpYlNJMM/4I3KRzW36tcgDQPAhn rS4waz3LAThxbMHLrZBx9TlblpXKRWlbXJt2hjQnpS/4gpMEt9NfQmiihQDoBnWm 121Qq1WcQ6FEumRgnwN9jAZT =9SEJ -----END PGP SIGNATURE-----

FreeBSD Errata Notice FreeBSD-EN-26:26.hastd

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-26:26.hastd Errata Notice The FreeBSD Project Topic: Multiple issues in hastd(8) Category: core Module: hastd Announced: 2026-10-14 Credits: Alessandro Sagratini, Martin Vidovic, Glen Barber Affects: All supported versions of FreeBSD. Corrected: 2026-09-20 17:07:37 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:32 UTC (releng/15.1, 15.1-RELEASE-p5) 2026-09-20 17:07:56 UTC (stable/14, 14.5-STABLE) 2026-10-14 16:04:08 UTC (releng/14.5, 14.5-RELEASE-p2) 2026-10-14 16:03:50 UTC (releng/14.4, 14.4-RELEASE-p11) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background hastd(8) allows transparent replication of a block of storage (the resource) between a pair of systems connected over a TCP/IP network. At any given time, only one system (the primary node) can access the resource. Writes performed on the primary node are continuously transmitted to the other system (the secondary node). hastctl(8) is a command-line program used to control a hastd(8) instance on the same machine. II. Problem Description All communication between hastd nodes, between hastd and hastctl, and between the main hastd process and its child processes relies on a shared set of networking routines and an early implementation of name-value pair lists similar to but distinct from libnv(3), which was a later development. 1. Control messages between hastd and hastctl can be empty, consisting solely of a header with no payload. However, after receiving the header, the function used to receive control messages asserts that buffer space for the payload was successfully allocated. When there is no payload, this assertion fails. 2. The nvpair implementation used by hastd and hastctl pads names and values out to multiples of eight bytes, but does not initialize the padding. As a result, small amounts of data from reused heap allocations can find their way into that padding. 3. The main hastd process uses local domain sockets to communicate with its workers. When the main hastd process hands off an incoming connection to a worker, it first sends a variable-length string indicating the type of socket. The child receives this message using a function which does not allow short reads. This previously worked due to a bug in the local domain socket code which forced a short read if a normal message was followed by one that passed a descriptor. III. Impact 1. Depending on the exact configuration, certain hastctl commands may result in an empty response from hastd, causing hastctl to print an error message and abort. This does not affect the operation of hastd itself, but may make it difficult to inquire into its status or change its mode of operation. 2. The most obvious symptom of the padding issue is that small amounts of text from the configuration file end up embedded in the metadata at the start of the backing store for a HAST resource, because the memory that was first used to read the configuration is later reused to assemble the metadata before writing it out. Small amounts of hastd memory, potentially including data previously written to the resource, may also end up embedded in network messages passed between hastd nodes. 3. As a pair of HAST nodes transition from initialization to operation, the primary node will attempt to establish a network connection to the secondary node. The secondary node accepts the connection, then hands the socket off to a worker child. The worker child then hangs forever trying to read the socket type, preventing the node from transitioning to secondary. The pair remains forever in degraded mode, where the primary is able to operate normally but no replication to the secondary occurs. IV. Workaround No workaround is available, but systems that do not use hastd(8) are not affected. V. Solution Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Restart hastd(8), or reboot the system. Perform one of the following: 1) To update your system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base 2) To update your system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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-26:26/hastd.patch # fetch https://security.FreeBSD.org/patches/EN-26:26/hastd.patch.asc # gpg --verify hastd.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart hastd(8), or reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ cd8eef45d2d0 stable/15-n285597 releng/15.1/ c8fe55b4726a releng/15.1-n283631 stable/14/ 9401bfb06108 stable/14-n275205 releng/14.5/ 49baaf01c26a releng/14.5-n274888 releng/14.4/ 1c821dc49b53 releng/14.4-n273782 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://bugs.freebsd.org/292322> <URL:https://bugs.freebsd.org/298085> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-26:26.hastd.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwdUbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvNkMP/1iZxLmeolrPLftdjdBr NKTK4/EYKQupuCKhuGrJKRIbDcuz3aKoU+0lO821ra0ktly1mdzuO7xrNXIhzH6J nTg+8MTPpM943sR2HP5vIyGPE+sXFd+YpSWjA0UHBhWIE25BFADhV0BC1UK1pGlD nLYO/3eaPtmNAoP0UUo/YD/92JaoG2piqkPFYmPOVdbMwY3uphNzwhilJCuBdCMs yxqhO/dpU+TYgv0vXs02p7iBvxwVHqgbZGHZHHBg+xnXBeFpMOXQ2jrtUJVc1FKZ gVaHEoC0zO6VRg0pXCKU+SCYCvH0jlVGu/rBcpHgxTREN0Uf95lmO0NBWS5WgfBa bl9mP3kwXc/rW59y36tY8vMTjg28J0h4DdTgPy2iJVcrYPWFx+ufUyVIdGCiuZat Y3AjHwS/tPBAH15ovUBtkF1l7vB/LLRAi0qODnQmhgVkeZX2/PjGtzftyOES9P1T zhehQnl1Twe+JiJgdtei/6UrnYHv2NKdmoW74tdi5WYizbnatN0P6uMLSCKdfbsZ 7q2i/8GUY4Js1yDqDAWGbg5fpq8fAKSY1GJtebK83E9MVjLaIl87llgS1KQASpXi gmW4h9L8ZKZJPcysUk2YgXEDgMRKvuyj2soNVyL1V4oZtCJ4Tga4pdnjcyJlwpUT JlT5dlSJCp7ed7hNh4wgOTTo =kksa -----END PGP SIGNATURE-----

FreeBSD Errata Notice FreeBSD-EN-26:25.tzdata

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-26:25.tzdata Errata Notice The FreeBSD Project Topic: Timezone database information update Category: contrib Module: zoneinfo Announced: 2026-10-14 Affects: All supported versions of FreeBSD. Corrected: 2026-10-03 06:56:13 UTC (stable/15, 15.1-STABLE) 2026-10-14 16:04:29 UTC (releng/15.1, 15.1-RELEASE-p5) 2026-10-03 07:59:46 UTC (stable/14, 14.5-STABLE) 2026-10-14 16:04:05 UTC (releng/14.5, 14.5-RELEASE-p2) 2026-10-14 16:03:47 UTC (releng/14.4, 14.4-RELEASE-p11) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background The IANA Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. FreeBSD releases install the IANA Time Zone Database in /usr/share/zoneinfo. The tzsetup(8) utility allows the user to specify the default local time zone. Based on the selected time zone, tzsetup(8) copies one of the files from /usr/share/zoneinfo to /etc/localtime. A time zone may also be selected for an individual process by setting its TZ environment variable to a desired time zone name. II. Problem Description Several changes to future and past timestamps have been recorded in the IANA Time Zone Database after previous FreeBSD releases were released. This affects many users in different parts of the world. Because of these changes, the data in the zoneinfo files need to be updated. If the local timezone on the running system is affected, tzsetup(8) needs to be run to update /etc/localtime. III. Impact An incorrect time will be displayed on a system configured to use one of the affected time zones if the /usr/share/zoneinfo and /etc/localtime files are not updated, and all applications on the system that rely on the system time, such as cron(8) and syslog(8), will be affected. IV. Workaround The system administrator can install an updated version of the IANA Time Zone Database from the misc/zoneinfo port and run tzsetup(8). Applications that store and display times in Coordinated Universal Time (UTC) are not affected. V. Solution Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Please note that some third party software, for instance PHP, Ruby, Java, Perl and Python, may be using different zoneinfo data sources, in such cases this software must be updated separately. Software packages that are installed via binary packages can be upgraded by executing 'pkg upgrade'. Following the instructions in this Errata Notice will only update the IANA Time Zone Database installed in /usr/share/zoneinfo. Perform one of the following: 1) To update your system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base 2) To update your system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) 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-26:25/tzdata-2026e.patch # fetch https://security.FreeBSD.org/patches/EN-26:25/tzdata-2026e.patch.asc # gpg --verify tzdata-2026e.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart all the affected applications and daemons, or reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 961a842fdd3a stable/15-n285756 releng/15.1/ 92af638d5ee7 releng/15.1-n283628 stable/14/ 7b8c80572256 stable/14-n275286 releng/14.5/ 672090209998 releng/14.5-n274885 releng/14.4/ 24aef4c96a12 releng/14.4-n273779 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://github.com/eggert/tz/blob/2026e/NEWS> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-26:25.tzdata.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwckbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvxXQP/RBHlpRIZF+Djt9Lia47 mENgVI08p5/rQzw6bT1EB8UlfYyeKU6azMCIEG8R1N8aAXf3aknls3ANpCI0IJ6W 7LJoEmTH/DxOGAty5u5zNL/pRXc6wtNQCoF/YJgVIspctQ3qG92PDjc6hRXnPz6+ JrVo/6T5VjMnYK73VXYzX2xlfRoUVU10zIruX5GwxBXWmcbIMgwSYvoJ9MkUBCDv FOtTfqVR+2tGlLlFCPacJjLVxapwItmF3+TPXYxGdTnJuMTujU3XCuL/RsUVwFLB 8BD5z5hb4tEhILZvh3v4pTUkOiIlraDp+NDWujGLt8I+j+rKXoUsnVs2mvIzXr3E K2SjOFO54ePTyCDALk+SZe76z77fJTCWioRfvT+WWiRH4f/7CfozFt2femzsdYzG JB5BKQgBN4wjpcEH6t+NYn+pGC8fg03cFlcPVKEkPxbiCvNdIJlbY5dKi+D0OOF4 7Ak/fhGT4VRF4qIKn0/K2hdEBTN5UIaVynwJ8KHXqwWDIKZ8ZaRmHXbbx9o3Xahx WE6ESkZ9DmcyK+jjODkb46MhBKYjBsrMyBKyIOFh6PWzp2OHyKlsa61qf/HJZNL3 M3wqglYdcxvIBPi4qTrxwQk3VhEXR95MjXr10x00WJWnNFpMbLv/3Ey7ABE2G3mK cy+wB3o/QeR6+6n7XRUi65F/ =Fnl8 -----END PGP SIGNATURE-----

F46 Change Proposal: Unprivileged eBPF: RBAC Daemon with LSM Enforcement and Rootless Access (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedEBPFRBACDaemon Discourse poll - https://discussion.fedoraproject.org/t/f46-change-proposal-unprivileged-ebpf-rbac-daemon-with-lsm-enforcement-and-rootless-access-system-wide/204731/2 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Ship <code>bpf-rbacd</code>, a system daemon that enables unprivileged, policy-controlled eBPF access in Fedora. It delegates BPF privileges to containers via BPF tokens with in-kernel LSM enforcement, and provides rootless BPF access to desktop users via proxy execution — both governed by a single YAML policy and gated by an <code>ebpf</code> system group. == Owner == * Name: [[Fedora eBPF SIG|https://fedoraproject.org/wiki/SIGs/eBPF]] * FAS group: [https://accounts.fedoraproject.org/group/ebpf-sig/ @ebpf-sig] * Email: dmellado@redhat.com * Members: ** Daniel Mellado — dmellado@redhat.com ** Toke Høiland-Jørgensen — toke@redhat.com ** Viktor Malik — vmalik@redhat.com == Detailed Description == === Background === eBPF is a powerful kernel technology for networking, observability, and security, but its use requires system-wide capabilities (<code>CAP_BPF</code> combined with <code>CAP_PERFMON</code>, <code>CAP_NET_ADMIN</code>, or <code>CAP_SYS_ADMIN</code>). This is an all-or-nothing proposition: applications need privileges close to root, which blocks adoption in containers and restricts desktop developers. The kernel's BPF token mechanism (Linux 6.9+) allows a privileged issuer to delegate a constrained set of BPF operations to unprivileged consumers inside user namespaces. However, tokens alone have two significant limitations: # '''No per-entity enforcement.''' Token constraints are set at the bpffs mount level and apply uniformly to all consumers. There is no mechanism to give different containers different allowed program types, or to revoke access dynamically. # '''No desktop path.''' BPF tokens are not supported in the initial user namespace (<code>BPF_TOKEN_CREATE</code> returns <code>EOPNOTSUPP</code>). Desktop developers running tracers or profilers must still use <code>sudo</code>. This change addresses both gaps through a single daemon that operates in two complementary modes simultaneously. === Dual-mode architecture === <code>bpf-rbacd</code> serves two distinct classes of eBPF consumers from a single process, using the same policy engine and the same YAML configuration: {| class="wikitable" ! Mode !! Target environment !! Mechanism !! LSM enforcement |- | '''Capability granting''' || Containers and services in user namespaces || BPF token delegation via bpffs mount + "nsenter dance" || Yes — three LSM hooks enforce per-namespace policy bitmaps in-kernel |- | '''Proxy execution''' || Desktop users and applications in the initial user namespace (<code>init_user_ns</code>) || Daemon executes <code>bpf()</code> on behalf of clients, passes FDs via <code>SCM_RIGHTS</code> over a Unix socket || N/A — policy enforced daemon-side before executing the syscall |} '''Why two modes?''' BPF tokens only work inside user namespaces — the kernel explicitly rejects <code>BPF_TOKEN_CREATE</code> in <code>init_user_ns</code> with <code>EOPNOTSUPP</code>. Containers naturally have user namespaces, so tokens are the right mechanism there. Desktop users do not, so they need a different path. The proxy mode fills that gap without requiring application changes: standard tools like bpftrace or bcc can be adapted to request FDs from the daemon instead of calling <code>bpf()</code> directly. Both modes share the same policy model (allow-list only, fails closed, system-policy intersection) and the same group-based role resolution (<code>ebpf</code>, <code>ebpf-net</code>, <code>ebpf-admin</code>). An administrator writes one policy file and both modes obey it. <pre> bpf-rbacd (privileged daemon) ┌──────────────────────────────┐ │ Policy Engine │ │ (YAML → role → bitmaps) │ └──────┬───────────┬────────────┘ │ │ ┌───────────▼──┐ ┌────▼──────────────┐ │ Capability │ │ Proxy execution │ │ granting │ │ (SCM_RIGHTS) │ │ mode │ │ mode │ └──────┬───────┘ └────┬───────────────┘ │ │ ┌───────────▼──┐ ┌────────▼────────────┐ │ Container / │ │ Desktop user │ │ service in │ │ (init_user_ns) │ │ user ns │ │ │ │ │ │ $ bpf-rbac create-map│ │ Uses BPF │ │ → daemon executes │ │ token from │ │ → FD passed back │ │ bpffs │ │ via SCM_RIGHTS │ │ ↓ │ └──────────────────────┘ │ LSM enforces │ │ per-ns policy│ └──────────────┘ </pre> === What this change delivers === ==== BPF token delegation and the ebpf system group ==== <code>bpf-rbacd</code> uses systemd-driven bpffs delegation to provide BPF tokens to containers and services in user namespaces: * A fixed <code>ebpf</code> system group gates who may consume the delegated bpffs/token path. The group is for OS-level discovery and packaging defaults; the kernel still enforces token constraints independently. * The daemon performs the '''"nsenter dance"''' — entering the target user namespace via <code>setns()</code> before mounting bpffs, so the <code>s_user_ns</code> is set correctly and <code>BPF_TOKEN_CREATE</code> works inside the namespace. * Integration with systemd <code>PrivateBPF=</code> (upstream [https://github.com/systemd/systemd/pull/36134 PR #36134]) enables automatic namespace delegation for systemd-managed services. * Libraries such as libbpf, bpftool, and bcc automatically discover and use delegated tokens without requiring <code>sudo</code>. ==== In-kernel eBPF LSM policy enforcement ==== The daemon loads eBPF LSM programs at startup that attach to the kernel's security hooks for BPF operations. Each hook looks up the calling process's user namespace inode ID in an eBPF hash map, retrieves the policy bitmaps for that namespace's role, and returns allow or deny. This gives administrators '''per-namespace, per-role granularity''' enforced in-kernel, on top of the bpffs mount-level token constraints. '''Core hooks''' (implemented in both the Aya and C codebases): {| class="wikitable" ! LSM Hook !! What it controls !! Policy dimension |- | <code>security_bpf</code> || Every <code>bpf()</code> syscall invocation || <code>allowed_cmds</code> bitmap (PROG_LOAD, MAP_CREATE, etc.) |- | <code>security_bpf_prog_load</code> || Program loading — inspects program type || <code>allowed_prog_types</code> bitmap (kprobe, xdp, etc.) |- | <code>security_bpf_map_create</code> || Map creation — inspects map type || <code>allowed_map_types</code> bitmap (hash, array, etc.) |} '''Extended hooks''' (implemented in the C codebase — [https://github.com/tohojo/bpf-rbac-lsm tohojo/bpf-rbac-lsm]): {| class="wikitable" ! LSM Hook !! What it controls !! Why it matters |- | <code>security_bpf_prog</code> || FD-level access to existing programs || Controls who can inspect or reuse loaded programs |- | <code>security_mmap</code> || Memory-mapping of BPF maps || Controls map data access mode (read/write/exec) |} '''Bytecode walking for helper/kfunc policy:''' The C implementation also uses open-coded iterators to walk BPF program bytecode at <code>security_bpf_prog_load</code> time, extracting the helper function IDs and kfunc BTF IDs that the program calls. This enables a future policy dimension: restricting ''which kernel functions'' a program may invoke, not just which program type it is. Events are reported to userspace via a BPF ring buffer for audit logging and policy decisions. '''How LSM and tokens complement each other:''' <pre> Token says "you may load LSM checks: "your namespace kprobe programs" role only permits tracepoint" ↓ → DENIED </pre> Even if a token is overly permissive (broad bpffs mount options), the per-namespace LSM policy restricts actual operations to the role's intersection with the system policy. '''eBPF program loading at daemon startup:''' The daemon loads and attaches the LSM programs before accepting any delegation requests. This requires <code>CAP_BPF</code> + <code>CAP_SYS_ADMIN</code> on the daemon itself (granted via the systemd unit's <code>AmbientCapabilities</code>). Once loaded, the LSM hooks are active system-wide; the eBPF policy map serves as the control plane between the daemon and the LSM. ==== Rootless BPF for desktop users (proxy mode) ==== For users in the initial user namespace (desktops, developer workstations), <code>bpf-rbacd</code> provides a proxy execution mode: # User runs <code>bpf-rbac <command></code> (e.g., <code>bpf-rbac create-map --type hash ...</code>) # The CLI connects to the daemon's Unix socket at <code>/run/bpf-rbac.sock</code> # The daemon reads <code>SO_PEERCRED</code> — kernel-verified, tamper-proof credentials # Group membership is resolved to a policy role # The daemon executes the allowed <code>bpf()</code> syscall with its own privileges # Resulting file descriptors are passed back via <code>SCM_RIGHTS</code> # Denied operations return actionable error messages === Policy model === Policies are defined in <code>/etc/bpf-rbac/policy.yaml</code> using an allow-list model that always fails closed: <pre> system_policy: # System-wide ceiling commands: [PROG_LOAD, MAP_CREATE, MAP_LOOKUP_ELEM, MAP_UPDATE_ELEM, LINK_CREATE, OBJ_PIN, OBJ_GET, BTF_LOAD] prog_types: kprobe: [load, attach, detach] tracepoint: [load, attach, detach] xdp: [load, attach, detach] map_types: hash: [create, read, write] array: [create, read, write] ringbuf: [create, read] roles: ebpf: # Tracing role groups: [ebpf] commands: [PROG_LOAD, MAP_CREATE, MAP_LOOKUP_ELEM, MAP_UPDATE_ELEM, LINK_CREATE, BTF_LOAD] prog_types: kprobe: [load, attach] tracepoint: [load, attach] map_types: hash: [create, read, write] array: [create, read, write] ringbuf: [create, read] ebpf-net: # Networking role groups: [ebpf-net] prog_types: xdp: [load, attach, detach] sched_cls: [load, attach, detach] map_types: hash: [create, read, write] devmap: [create, read, write] ebpf-admin: # Unrestricted groups: [ebpf-admin, wheel] commands: [any] prog_types: {any: [any]} map_types: {any: [any]} </pre> The effective policy for any role is the '''set intersection''' of the role policy and the system policy. A role can never exceed administrator-defined system limits. === Two LSM implementations and the Rust BPF toolchain gap === The eBPF LSM programs exist in two parallel implementations. This is not redundancy — it is a deliberate response to a Rust compiler limitation that currently prevents the Aya-based implementation from using advanced BPF features. ==== The Rust/DWARF/BTF problem ==== eBPF programs that call kernel functions (kfuncs) or reference kernel symbols (ksyms) require BTF (BPF Type Format) metadata in the compiled ELF. The toolchain flow is: <pre> Rust source → rustc (BPF target) → LLVM → ELF with DWARF → bpf-linker → ELF with BTF (including .ksyms DATASEC) → kernel verifier resolves kfuncs/ksyms at load time </pre> The problem: '''<code>rustc</code> does not emit DWARF debug info for <code>extern</code> declarations on BPF targets.''' When a Rust eBPF program declares: <pre> #[link_section = ".ksyms"] extern "C" { static LINUX_KERNEL_VERSION: u32; // ksym fn bpf_iter_num_new(it: *mut bpf_iter_num, start: i32, end: i32); // kfunc } </pre> …the compiler produces the LLVM global/function declaration but attaches no <code>DIGlobalVariable</code> or <code>DISubprogram</code> metadata. Without DWARF, <code>bpf-linker</code> cannot generate the <code>.ksyms</code> BTF DATASEC entry, and the kernel verifier cannot resolve these symbols at load time. The program fails to load. This blocks: * '''Open-coded iterators''' (<code>bpf_iter_num_new/next/destroy</code>) — needed for bytecode walking in the <code>security_bpf_prog_load</code> hook * '''kfunc calls''' (<code>bpf_task_acquire</code>, etc.) — needed for CO-RE task/namespace introspection * '''The userns ID resolver''' — <code>current->nsproxy->user_ns->ns.inum</code> access via BTF, currently stubbed to return 0 The three core bitmap-based hooks (<code>security_bpf</code>, <code>security_bpf_prog_load</code>, <code>security_bpf_map_create</code>) work today with Aya because they only use map lookups and context argument reads — no kfuncs or ksyms. But the extended hooks (bytecode walking, FD access control, mmap control) require kfuncs and are blocked. ==== The upstream Rust compiler fix ==== We are driving the fix in [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390] ("Generate debug info for BPF extern declarations"). This patch: * Allows <code>#[link_section]</code> on <code>ForeignStatic</code> and <code>ForeignFn</code> (gated to BPF targets) * Adds an <code>LLVMRustDIBuilderCreateGlobalVariableExpression</code> wrapper exposing the <code>isDefinition</code> parameter (the LLVM-C API hard-codes it to <code>true</code>) * Emits <code>DIGlobalVariable</code> with <code>isDefinition: false</code> for extern statics * Emits <code>DISubprogram</code> without <code>SPFlagDefinition</code> for extern functions This is a reworked version of [https://github.com/rust-lang/rust/pull/152899 #152899], rebased on current <code>main</code> with review feedback addressed. It is currently in review with the Rust compiler team (assigned to @jdonszelmann, reviews from @bjorn3 and @tamird). The Aya maintainer (@vadorovsky) is also involved. Once this lands in nightly <code>rustc</code>, the full chain works: Rust eBPF → DWARF with extern metadata → <code>bpf-linker</code> → BTF with <code>.ksyms</code> → kernel loads kfuncs. This unblocks the complete Aya-based LSM. ==== The C implementation: tohojo/bpf-rbac-lsm ==== [https://github.com/tohojo/bpf-rbac-lsm tohojo/bpf-rbac-lsm] is an actively developed C-based LSM implementation (Toke Høiland-Jørgensen, latest commits Sep 2026) that sidesteps the Rust toolchain limitation entirely. It uses: * '''C for the eBPF programs''' — compiled with clang/llvm, full BTF/CO-RE support, no DWARF issues * '''Rust + libbpf-rs for userspace''' — loads the C eBPF programs via libbpf skeleton generation, processes ring buffer events, manages policies This implementation is more capable than the Aya version today: {| class="wikitable" ! Feature !! Aya (Rust eBPF) !! C eBPF + libbpf-rs |- | <code>security_bpf</code> (command filtering) || ✅ || ✅ |- | <code>security_bpf_prog_load</code> (type filtering) || ✅ || ✅ |- | <code>security_bpf_map_create</code> (type filtering) || ✅ || ✅ |- | <code>security_bpf_prog</code> (FD access) || ❌ || ✅ |- | <code>security_mmap</code> (map mmap control) || ❌ || ✅ |- | Userns ID resolution (CO-RE/BTF) || ❌ (stubbed) || ✅ |- | Bytecode walking (open-coded iterators) || ❌ (blocked on rustc) || ✅ |- | Helper/kfunc ID extraction || ❌ (blocked on rustc) || ✅ |- | Policy enforcement per namespace || ❌ (stub returns 0) || ✅ |- | Ring buffer event reporting || ❌ || ✅ |} ==== Integration strategy and the path to a pure Rust/Aya stack ==== The two implementations share the same userspace daemon (<code>bpf-rbacd</code>) and the same policy engine. They are designed to converge: '''Phase 1 — Fedora 46 delivery (C eBPF + Rust userspace):''' Use the C eBPF programs from <code>bpf-rbac-lsm</code> loaded via <code>libbpf-rs</code> in the <code>bpf-rbacd</code> Rust userspace daemon. This gives us the full feature set (all hooks, bytecode walking, namespace resolution, policy enforcement) without waiting for the Rust compiler fix. The daemon, policy engine, CLI, and all userspace logic remain in Rust; only the eBPF kernel programs are in C. This is a pragmatic split — the same pattern used by many production eBPF projects (e.g., Cilium, bpfman). '''Phase 2 — After <code>rustc</code> fix lands (Aya catches up):''' Once [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390] is merged and reaches stable <code>rustc</code>, we migrate the eBPF programs to Rust/Aya. The groundwork is already done: * The Aya-based LSM in [https://github.com/danielmellado/bpf-rbacd danielmellado/bpf-rbacd] already compiles and produces correct ELF relocations for the three core hooks. * The [https://github.com/tohojo/bpf-rbacd/tree/load-lsm load-lsm branch] already has kfunc declarations and open-coded iterator code that compiles — it only needs the BTF DATASEC generation that the <code>rustc</code> fix enables. * Aya's kfunc relocation support ([https://github.com/aya-rs/aya/pull/1372 aya-rs/aya#1372]) is progressing upstream. The migration is a drop-in replacement: the userspace daemon, policy engine, and CLI are unchanged. Only the eBPF binary source changes from C to Rust. '''Phase 3 — Target state (pure Rust):''' A fully Rust stack — daemon, CLI, policy engine, ''and'' eBPF kernel programs — all built with <code>cargo</code>. This is the desired end state for <code>bpf-rbacd</code> because: * '''Single toolchain:''' One <code>cargo build</code> compiles everything. No separate clang/llvm dependency for the eBPF programs. * '''Shared types:''' The <code>bpf-rbacd-common</code> crate already defines <code>#[repr(C)]</code> policy types (<code>PolicyKey</code>, <code>PolicyValue</code>) that compile for both <code>no_std</code> (eBPF target) and <code>std</code> (userspace). With Aya, these types are shared at compile time with full type safety — no manual struct layout synchronization between C and Rust. * '''Memory safety:''' Rust's borrow checker and type system apply to the eBPF programs too. While eBPF's verifier provides runtime safety, compile-time guarantees from Rust catch bugs earlier. * '''Ecosystem alignment:''' Aya is the standard Rust eBPF framework. Contributing improvements back (kfunc support, LSM patterns) benefits the entire Rust eBPF community. The <code>rustc</code> fix is not just a <code>bpf-rbacd</code> concern — it unblocks kfunc/ksym usage for ''every'' Rust eBPF program. We are driving this upstream because it is the right thing for the ecosystem, and <code>bpf-rbacd</code> is a concrete, high-profile consumer that validates the fix. This phased approach means the Fedora 46 deliverable is '''not blocked by the Rust compiler fix''', while the Rust/Aya migration remains a first-class goal tracked by the eBPF SIG. === Kernel requirements === {| class="wikitable" ! Config !! Required for !! In Fedora? |- | <code>CONFIG_BPF_SYSCALL=y</code> || All BPF operations || Yes |- | <code>CONFIG_BPF_LSM=y</code> || LSM hook attachment || Yes |- | <code>bpf</code> in active LSM list || LSM program loading || Needs verification |- | <code>CONFIG_DEBUG_INFO_BTF=y</code> || CO-RE/BTF for portable eBPF || Yes |- | <code>CONFIG_BPF_TOKEN</code> || BPF token delegation || Yes |} '''Action item:''' Verify that <code>bpf</code> is in the kernel's compiled-in LSM list or <code>lsm=</code> boot parameter. If not, a kernel config change is needed to add <code>bpf</code> to the LSM order alongside <code>lockdown,yama,integrity,selinux</code>. == Feedback == The design of <code>bpf-rbacd</code> is being presented at [https://lpc.events/event/20/contributions/2441/ Linux Plumbers Conference 2026] (Oct 6, eBPF Track) to solicit community feedback. The talk covers the architecture, policy model, and LSM enforcement, with the goal of making the design useful to other distributions and operators. Community consultation with kernel, systemd, and security stakeholders is ongoing. == Benefit to Fedora == * '''Security posture:''' Moves eBPF access from all-or-nothing capabilities toward granular, role-based delegation. LSM enforcement adds a mandatory kernel-level policy layer that token delegation alone cannot provide. * '''Per-entity granularity:''' Different containers, services, or users get different eBPF permissions based on their role — not a single system-wide delegation. * '''Developer experience:''' Desktop developers and operators can run eBPF tools without <code>sudo</code>, with clear errors when an operation is outside their role's policy. * '''Unified policy:''' One YAML file governs both container (LSM + tokens) and desktop (proxy) access. Administrators learn one model. * '''Dynamic policy and revocation:''' Policies can be updated at runtime; removing a namespace's map entry causes the LSM to deny subsequent operations without killing processes. * '''Downstream alignment:''' Establishes the reference RBAC implementation for RHEL, OpenShift (user namespaces GA in 4.21+), and CoreOS. Kubernetes user namespaces are GA as of v1.36. * '''Rust BPF ecosystem:''' The upstream <code>rustc</code> fix ([https://github.com/rust-lang/rust/pull/161390 #161390]) benefits the entire Rust eBPF community. <code>bpf-rbacd</code> is designed to become a fully pure-Rust eBPF project (daemon + kernel programs via Aya) once the toolchain gap is closed, demonstrating that production eBPF LSM programs can be written entirely in Rust. * '''Community leadership:''' Fedora becomes the first distribution with a complete, integrated eBPF RBAC stack spanning containers and desktops. == Scope == * Proposal owners: ** Package <code>bpf-rbacd</code> (daemon), <code>bpf-rbac</code> (CLI client), and <code>bpf-rbacd-common</code> (shared types) as RPMs. Source is hosted on [https://forge.fedoraproject.org/ebpf/bpf-rbacd Fedora Forge]. ** Ship the eBPF LSM programs from [https://github.com/tohojo/bpf-rbac-lsm tohojo/bpf-rbac-lsm] (C eBPF + libbpf-rs for loading). Migrate to Rust/Aya once [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390] lands. ** Deliver systemd unit (<code>bpf-rbacd.service</code>) with security hardening (<code>ProtectSystem=strict</code>, <code>ProtectHome=true</code>, capability bounding). ** Deliver default policy (<code>/etc/bpf-rbac/policy.yaml</code>) reviewed with the Security Team. ** Create <code>ebpf</code>, <code>ebpf-net</code>, and <code>ebpf-admin</code> system groups via <code>systemd-sysusers</code>. ** Implement systemd-driven bpffs delegation (mount units, <code>PrivateBPF=</code> coordination). ** Coordinate with kernel team to ensure <code>bpf</code> is in the active LSM list. ** Drive the Rust compiler fix ([https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390]) or use C fallback. ** Complete the CO-RE/BTF userns ID resolver in the eBPF LSM. ** Wire container/namespace discovery into the daemon (cgroup events or CRI hooks). ** Coordinate library/tool updates for automatic token usage (libbpf, bpftool, bcc). ** File Fedora package review, FESCo process, and tracker bugs. ** Write Fedora Quick Docs article on usage and security model. * Other developers: ** Kernel maintainers: Confirm <code>CONFIG_BPF_LSM=y</code> and <code>bpf</code> in LSM list; advise on LSM hook semantics and regression triage. ** systemd maintainers: Coordinate on <code>PrivateBPF=</code> integration so systemd-launched services automatically get delegated namespaces. ** Rust compiler team: Review and land [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390]. ** Aya maintainers: kfunc relocation support ([https://github.com/aya-rs/aya/pull/1372 aya-rs/aya#1372]). ** Security Team: Review default policy, group membership model, and LSM enforcement guarantees. ** eBPF tooling maintainers (bcc, bpftool, libbpf consumers): Ensure tools work with proxy-mode FD passing and token-based flows. ** Container runtime maintainers (podman, CRI-O): Test user namespace + BPF token + LSM enforcement end-to-end. ** Edition WGs (Workstation, Server, CoreOS): Consider default group membership and documentation per edition. * Release engineering: No release engineering changes required. <code>bpf-rbacd</code> is a new opt-in package with standard RPM packaging — no mass rebuild, no installer image changes, and no compose modifications. * Policies and guidelines: The initial delivery uses C eBPF programs compiled with clang/llvm and loaded via libbpf-rs — this follows standard Fedora packaging (clang and libbpf are already packaged). The future Aya-based path targets <code>bpfel-unknown-none</code> and requires nightly Rust + <code>rust-src</code>, which may need a packaging exemption or pre-built binary vendoring when that migration occurs. Default policy requires Security Team review. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Aligns with secure-by-default, developer-friendly platform, and upstream-first goals. The change drives fixes in <code>rustc</code>, Aya, and systemd rather than carrying downstream patches. == Upgrade/compatibility impact == This change introduces a new opt-in package. It does not modify existing system behavior. * '''Existing systems:''' No change unless <code>bpf-rbacd</code> is installed. Workflows that use root or explicit capabilities continue to work. * '''New path:''' Users or administrators who want unprivileged eBPF install <code>bpf-rbacd</code>, add users to the <code>ebpf</code>, <code>ebpf-net</code>, or <code>ebpf-admin</code> groups, and enable the service. * '''Kernel config:''' If <code>bpf</code> needs to be added to the LSM list, this could interact with other LSM consumers (notably SELinux). Must be coordinated with the kernel team. * '''ABI:''' No Fedora-specific ABI commitment beyond documented <code>bpf()</code> semantics and the policy YAML format. Tools that gain automatic token discovery may succeed in situations where they previously failed without sudo. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == # '''Hardware/data:''' Standard x86_64 or aarch64 Fedora install. VM acceptable if BPF features are not stripped. # '''Prepare:''' Install <code>bpf-rbacd</code>, start the service, add test user to <code>ebpf</code> group. # '''Proxy mode (desktop):''' #: <pre> # As a user in the ebpf group: $ bpf-rbac status Connected to: /run/bpf-rbac.sock Your roles: ebpf Allowed operations: Maps: hash, array, percpu_hash, percpu_array, ringbuf Programs: kprobe, uprobe, tracepoint, perf_event # Create a map (should succeed) $ bpf-rbac create-map --type hash --name test \ --key-size 4 --value-size 8 --max-entries 64 # Attempt a denied operation (should fail with clear error) $ bpf-rbac create-map --type devmap --name test \ --key-size 4 --value-size 8 --max-entries 64 Error: map type 'devmap' is not allowed by your role 'ebpf' </pre> # '''LSM enforcement (requires root for setup):''' Launch a podman container in a user namespace (<code>podman run --userns=auto ...</code>). Verify that the daemon delegates bpffs and populates the policy map. Inside the container, attempt to load an allowed program type (should succeed) and a denied type (should fail with <code>EPERM</code>). # '''Non-member:''' As a user NOT in any ebpf group, verify that all operations are denied. # '''Unit tests (no root required):''' #: <pre> cargo test --lib # Policy parsing, bitmaps, intersection cargo test --test integration # Non-privileged integration tests </pre> # '''Expected results:''' Delegated operations succeed within the role's allowlist; out-of-scope operations fail with clear errors; no system instability or privilege escalation beyond the documented policy. == User Experience == * Most users see no change unless they use eBPF tooling. * Desktop developers who run tracers or networking experiments may stop needing <code>sudo</code> for supported scenarios, with clear errors when an operation is denied. * Container workloads are transparent — applications use standard <code>bpf()</code> with automatic token acquisition; the LSM silently enforces the namespace's policy. * Administrators get a single documented policy file (<code>/etc/bpf-rbac/policy.yaml</code>) and <code>journalctl -u bpf-rbacd</code> for audit logging. == Dependencies == * Linux kernel: 6.9+ with <code>CONFIG_BPF_TOKEN</code>, <code>CONFIG_BPF_LSM=y</code>, <code>bpf</code> in active LSM list, <code>CONFIG_DEBUG_INFO_BTF=y</code> * Rust: Stable 1.85+ (daemon and CLI) * [https://github.com/libbpf/libbpf libbpf] and [https://github.com/libbpf/libbpf-rs libbpf-rs]: For loading C-based eBPF LSM programs from the Rust daemon (initial delivery path) * clang/llvm: For compiling the C eBPF programs with full BTF/CO-RE support * [https://github.com/aya-rs/aya Aya]: eBPF library for Rust (long-term target once [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390] lands; requires nightly Rust + <code>bpfel-unknown-none</code> target) * systemd: <code>PrivateBPF=</code> support ([https://github.com/systemd/systemd/pull/36134 PR #36134]) * Optional: podman with <code>--userns=auto</code>, CRI-O with user namespace support == Contingency Plan == * Contingency mechanism: ** The primary delivery path already uses the C eBPF programs (via libbpf-rs), so the Rust compiler fix ([https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390]) is not on the critical path for F46. ** If BPF LSM cannot be enabled in the Fedora kernel (e.g., SELinux interaction with <code>bpf</code> in the LSM list): disable LSM loading in <code>bpf-rbacd</code>; ship proxy mode only and rely on token-level constraints for container workloads. ** If proxy mode has unresolved security concerns: ship LSM/container path only; desktop users fall back to <code>sudo</code>/<code>CAP_BPF</code>. ** If neither component is ready: do not ship <code>bpf-rbacd</code>. eBPF access continues to work as it does today (privileged only). No regression. * Contingency deadline: Beta freeze * Blocks release? No. <code>bpf-rbacd</code> is an opt-in package. == Documentation == * Upstream code: [https://forge.fedoraproject.org/ebpf/bpf-rbacd Fedora Forge ebpf/bpf-rbacd] (primary), [https://github.com/danielmellado/bpf-rbacd GitHub mirror] * C reference implementation: [https://github.com/tohojo/bpf-rbac-lsm tohojo/bpf-rbac-lsm] * Rust compiler fix: [https://github.com/rust-lang/rust/pull/161390 rust-lang/rust#161390] * Kernel docs: [https://docs.kernel.org/bpf/bpf_token.html BPF Token documentation] * systemd: [https://github.com/systemd/systemd/pull/36134 PrivateBPF= PR] * LPC 2026 talk: [https://lpc.events/event/20/contributions/2441/ BPF-RBACd: Delegating BPF permissions with high granularity] * Fedora: Quick Docs article covering installation, group membership, policy customization, security model, and container vs. desktop usage paths. * eBPF SIG: [https://fedoraproject.org/wiki/SIGs/eBPF SIGs/eBPF], Matrix: [https://matrix.to/#/#ebpf:fedoraproject.org #ebpf:fedoraproject.org] == Release Notes == Fedora 46 introduces <code>bpf-rbacd</code>, a system daemon that enables unprivileged, policy-controlled eBPF access through two complementary modes: * '''Capability granting''' for containers and services in user namespaces — transparent eBPF access via BPF token delegation with mandatory in-kernel LSM enforcement (three hooks: <code>security_bpf</code>, <code>security_bpf_prog_load</code>, <code>security_bpf_map_create</code>). * '''Proxy execution''' for desktop users in the initial user namespace — rootless BPF access via the <code>bpf-rbac</code> CLI, with the daemon executing allowed operations on the user's behalf and passing file descriptors back via <code>SCM_RIGHTS</code>. Both modes are governed by a single YAML policy file (<code>/etc/bpf-rbac/policy.yaml</code>) and gated by role-based groups (<code>ebpf</code>, <code>ebpf-net</code>, <code>ebpf-admin</code>). Install with <code>sudo dnf install bpf-rbacd</code>. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal: RPM v6 package format (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/RPMv6_package_format Discourse Poll - https://discussion.fedoraproject.org/t/f46-change-proposal-rpm-v6-package-format-system-wide/204730/2 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Move the entire distribution from the aging RPM v4 format to the native v6 format of RPM 6.x. == Owner == * Name: [[User:pmatilai|Panu Matilainen]] * Email: <pmatilai@redhat.com> == Detailed Description == This change is about switching the default output format of RPM from the aging RPM v4 format to the native and default v6 format of RPM 6.x. The v6 format is an evolution of the v4 format rather than something entirely new, and as such, is widely compatible with RPM 4.x versions. The v6 format benefits are mostly security and consistency oriented, such as: * Use of contemporary cryptographic algorithms for checksums * Consistent payload format and 64bit size tags regardless of package size * Payload is always independently verifiable * Tag conflicts between the signature and main header eliminated * Strings are always UTF-8 encoded * Per-file classification uses standard MIME instead of highly libmagic version dependent "magic" strings == Feedback == == Benefit to Fedora == The currently used v4 format is a quarter century old, and this shows in things like use of obsolete cryptography, size limitations and so on. The v6 format is a essentially a face-lift to bring the RPM package format up to date, and eliminate some quirks and dark corners in the process. Many of the features already exist as extensions to the v4 format, silently used as necessary. As such, this change is largely invisible to the average user. It's about future-proofing the packaging ecosystem. == Scope == The v6 format is considered stable and complete and has been the default format in the upstream RPM project since the 6.0 release, but exposure to distribution machinery could reveal unforeseen papercuts and the like. This is a one-line change in the RPM config but an enormous change for the distribution. The last RPM format change took place around the turn of the millenium, so there's a quarter century worth of assumptions around the v4 format built into tooling and projects. This should be done in small controllable steps. * Proposal owners: ** Test critical package set build pipeline in a throw-away side-tag, address any blocker issues ** Switch a couple of packages (eg. popt and rpm itself) to v6 manually, address any blocker issues ** Switch v6 on in rpm configuration ** Watch out for build/test/infra failures caused by the change ** Address any encountered RPM issues with high priority ** Assist with dealing with possible fallout in other projects ** Before mass-rebuild, switch back to v4 if too many issues remain and postpone to F47 * Other developers: ** Test that any RPM related software they use or maintain continues to function ** Report discovered issues for awareness ** Address incompatibilities in their software * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13546 #13546] * Policies and guidelines: N/A(not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This is a leading development in the Linux distro space. == Upgrade/compatibility impact == In general, there's little user visible impact, v4 and v6 packages can peacefully coexist where needed. Local scripts with custom rpm queries may need adjusting if they assume certain v4 package characteristics. The full breakdown of the v6 format compatibility aspects can be found in [https://rpm.org/releases/6.0.0#compatibility-notes RPM 6.0 release notes], but in broad strokes the format is compatible down to around RHEL 8 era RPM. It's still possible to build v4 format by setting the %_rpmformat macro to 4 when building packages. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Use RPM as you'd normally would, with v6 packages (from the distro or self-built). In particular, test any local scripts and similar you may have. All current Fedora versions are equally capable of handling v6 packages, you don't need to be on rawhide to test. It's possible to manually set the version in several ways: # add <code>%_rpmformat 6</code> to your <code>~/config/rpm/macros</code> or <code>~/.rpmconfig</code> # add <code>%global _rpmformat 6</code> to a spec to force a particular package to v6 # use <code>--define "_rpmformat 6"</code> when running <code>rpmbuild</code> Report any incompatibilities you think are not adequetely handled by the transition. == User Experience == For an end-user, this change is practically invisible. == Dependencies == Potentially affected components include (but not limited to): * Build systems and related components * Testing systems * Signing server systems * Errata systems Unaddressed incompatibilities in the critical pipeline would obviously block this change. In addition to the above, any software that assumes certain specific "under the hood" characteristics of packages, such as the existence of MD5 and SHA1 hashes of v4 packages, could be affected. The relative importance and severity would have to be assessed case-by-case. == Contingency Plan == * Contingency mechanism: ** Revert to v4 format (change owners) ** Rebuild existing v6 packages to v4 (as a side-effect of the mass rebuild) * Contingency deadline: just before the mass rebuild * Blocks release? No With a change like this, it's necessary to expect the unexpected. To minimize impact, it should be enabled early and also reverted early in case of substantial trouble. A 100% v6 package set is not necessary for completion, v4 and v6 packages can coexist peacefully. FTBS packages or similar that remain in v4 format are not a blocker. == Documentation == Format description and compatibility breakdown: https://rpm-software-management.github.io/rpm/manual/format_v6.html https://rpm.org/releases/6.0.0#compatibility-notes Background material: https://github.com/rpm-software-management/rpm/discussions/2919 https://github.com/rpm-software-management/rpm/discussions/3602 https://github.com/rpm-software-management/rpm/discussions/3349 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal: Remove DNF4 Stack and Modularity (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/RemoveModularityAndDNF4Support Discourse poll - https://discussion.fedoraproject.org/t/f46-change-proposal-remove-dnf4-stack-and-modularity-system-wide/204728/2 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Remove the entire legacy DNF4 software stack—including `dnf` (version 4.x), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, `dnf-plugins-extras`, and `libmodulemd`—from Fedora 46. Because `libmodulemd` cannot be retired while the legacy `libdnf` v1 stack and related components import it, removing the legacy package manager stack and auditing its consumers enables the complete retirement of Modularity. System package management will rely exclusively on DNF5, `libdnf5`, and `dnf5-plugins`. == Owner == * Name: [[User:fellipeh| Fellipe Henrique]], [[User:ppisar| Petr Pisar]], [[Subprojects/ReleaseEngineering|Fedora Release Engineering / Maintainers]] * Email: fpedrosa@redhat.com, ppisar@redhat.com, fedora-release-maintainers@fedoraproject.org == Detailed Description == Official Fedora modularity builds were retired as a distribution feature in Fedora 39 (see [[Changes/RetireModularity]]). However, Fedora continued to parse and support modular content from third-party repositories due to legacy modularity logic maintained inside `libdnf` v1, `libmodulemd`, and related tooling. Removing `libmodulemd` from the distribution requires either a heavy refactoring of the deprecated `libdnf` v1 codebase or the complete retirement of the DNF4 stack, along with dropping or updating modularity-handling dependencies across the ecosystem. Given that `dnf5` replaced DNF4 as the default system package manager in Fedora 41, modifying legacy code is impractical. This proposal completes the package management modernization by removing the legacy DNF4 stack and retiring `libmodulemd` and its consumer stack. Targeting Fedora 46, this change will: # '''Retire the DNF4 & legacy tool stack:''' Remove `dnf` (v4), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, and `dnf-plugins-extras`. # '''Retire Modularity & `libmodulemd`:''' Drop `libmodulemd` and `python3-libmodulemd` from the distribution entirely, along with adjusting or retiring packages that depend on them. # '''Port ecosystem dependencies:''' Update or retire affected downstream packages depending on `libdnf` v1, `python3-dnf`, `libmodulemd`, and `python3-libmodulemd`. === Affected Packages & Scope Breakdown === To provide full scope transparency, the following packages are affected and must be ported (e.g., to `libdnf5`, `dnf5-plugins`, or direct RPM APIs) or retired alongside this change: ==== Direct Modularity Consumers ==== * '''Direct `libmodulemd` consumers:''' ** `createrepo_c` (remove modularity metadata processing support) ** `dnf` (retired by this change) ** `dnf5` (remove residual/optional `libmodulemd` bindings) ** `libdnf` (retired by this change) ** `module-build` (retired/dropped) ** `python-ModulemdTranslationHelpers` (retired/dropped) ** `rpm-ostree` (remove modularity metadata handling) ** `ursa-major` (retired/dropped) * '''Direct `python3-libmodulemd` consumers:''' ** `modulemd-tools` (retired/dropped) ** `pungi` (remove modularity metadata generation routines) ** `rpkg` (remove modularity build subcommand support) ==== DNF4 / `python3-dnf` / `libdnf` Reverse Dependencies ==== The following components currently depend on DNF4, `libdnf` v1, or `python3-dnf` and need to be ported to `libdnf5` / `dnf5`, or retired if deprecated: * '''Infrastructure & Build Tooling:''' `copr-rpmbuild`, `fedora-review`, `kiwi`, `livecd-tools`, `mock-core-configs`, `osbuild`, `pungi`, `python-coprtree` * '''System Management & Diagnostics:''' `etckeeper`, `fedora-easy-karma`, `fedrq`, `libreport`, `needrestart`, `retrace-server`, `subscription-manager`, `system-config-language` * '''DNF4 Plugin Family (Retire or Port to DNF5 Plugins):''' `dnf-plugin-cow`, `dnf-plugin-diff`, `dnf-plugin-flunk_dependent_remove`, `dnf-plugin-perfmetrics`, `dnf-plugins-core`, `dnf-plugins-extras` * '''Package Managers / Core Libraries (Retire / Replaced by DNF5 stack):''' `dnf`, `libdnf`, `microdnf` == Feedback == * '''Retire Modularity (Fedora 39):''' Modular builds and Module Build Service (MBS) infrastructure were decommissioned. * '''Default Package Manager Switch to DNF5 (Fedora 41):''' DNF5 successfully replaced DNF4 for `/usr/bin/dnf`. * '''Combined Removal Rationale:''' DNF maintainers and community feedback recommended unifying the removal of DNF4, `libdnf`, `dnf-plugins-*`, `microdnf`, and `libmodulemd` into a single System-Wide Change Proposal rather than spending effort decoupling `libmodulemd` from `libdnf` v1. == Benefit to Fedora == * '''Elimination of State Corruption & System Inconsistencies:''' Running DNF4 and DNF5 concurrently on the same system is explicitly discouraged. Dual usage leads to broken transaction histories, missing package install reasons, and inconsistent configuration handling (see [https://dnf5.readthedocs.io/en/latest/migrating_to_dnf5.7.html DNF5 Migration Guidance]). Removing DNF4 prevents users and legacy scripts from unintentionally triggering these conflicts. * '''Elimination of Technical Debt:''' Cleans up thousands of lines of unmaintained code across the distribution, eliminating the security and maintenance overhead of parallel package manager stacks (`libdnf` v1 and `libdnf5`). * '''Complete Retirement of Modularity:''' Strips out `libmodulemd` completely, removing dead metadata handling across remaining packaging toolchains (`createrepo_c`, `pungi`, `rpm-ostree`, `rpkg`). * '''Focused Development:''' Allows the DNF development team to focus 100% of bug fixes, features, and optimizations exclusively on `dnf5` and `libdnf5`. == Scope == * Proposal owners: ** Coordinate the orphan and retirement process for `dnf` (v4), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, `dnf-plugins-extras`, `libmodulemd`, and `python3-libmodulemd`. ** Coordinate with maintainers of `createrepo_c`, `dnf5`, `rpm-ostree`, `pungi`, and `rpkg` to disable or remove `libmodulemd` build options and dependencies. ** Assist maintainers of affected DNF4 reverse dependencies (`copr-rpmbuild`, `osbuild`, `kiwi`, `subscription-manager`, `libreport`, `mock-core-configs`, etc.) with porting to `libdnf5` or standard `dnf5` invocations. ** Retire dead modularity utilities no longer needed in the distribution (`module-build`, `python-ModulemdTranslationHelpers`, `ursa-major`, `modulemd-tools`). * Other developers: ** Package Maintainers & Script Authors: Update tools (`createrepo_c`, `pungi`, `rpkg`, `rpm-ostree`, `subscription-manager`, etc.) to drop `libmodulemd` and DNF4 dependencies. Update any spec files or local automation referencing `import dnf` (DNF4) or `dnf-plugins-core` to use `dnf5` / `libdnf5` alternatives. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> ** Ensure compose and build tools (Koji, Pungi, Mock) rely exclusively on DNF5 / `libdnf5` native toolchains and do not emit modularity metadata. * Policies and guidelines: ** Update Packaging Guidelines and documentation to remove references to DNF4 subcommands, DNF4 macro helpers, and legacy Modularity packaging standards. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: ** Directly aligns with maintaining system architecture efficiency, eliminating deprecated technical debt, and maintaining core reliability. == Upgrade/compatibility impact == * Packages belonging to the DNF4 stack and legacy modularity tools will be retired from the Fedora 46 repositories. Unless explicitly obsoleted, existing installs will remain on upgraded machines as orphan packages until removed by the user. * Custom scripts explicitly targeting `/usr/bin/dnf-3`, `/usr/bin/dnf4`, `/usr/bin/microdnf`, or importing `python3-dnf` will fail and must be ported to DNF5 CLI or `libdnf5` bindings. * Standard interactive `dnf` invocations remain unchanged, as `/usr/bin/dnf` already points to DNF5. == Early Testing (Optional) == Do you require 'QA Blueprint' support? No == How To Test == # Audit repository dependencies (`dnf repoquery --whatrequires`) to verify no packages in Fedora 46 depend on `libdnf.so.2`, `python3-dnf`, `libmodulemd`, or `python3-libmodulemd`. # Perform routine system administration tasks (`dnf install`, `dnf upgrade`, `dnf remove`) to verify operations function smoothly via DNF5 without referencing DNF4 libraries. # Verify that core compose, build, and system tools (`createrepo_c`, `pungi`, `rpm-ostree`, `rpkg`, `osbuild`, `kiwi`, `subscription-manager`) build and run successfully without `libmodulemd` or `python3-dnf` installed. # Confirm that running legacy subcommands (such as `dnf module`) returns an explicit unrecognized command error from DNF5. == User Experience == Interactive terminal users will notice no difference, as DNF5 has been the default package manager since Fedora 41. System administrators or developers using legacy DNF4 Python scripts (`import dnf`), `microdnf` binaries, or `modulemd-tools` will need to update their workflows to `libdnf5` or DNF5 subcommands. == Dependencies == * `dnf5` / `libdnf5` / `dnf5-plugins` * Tools requiring updates to drop `libmodulemd`: `createrepo_c`, `pungi`, `rpm-ostree`, `rpkg` * Reverse dependencies requiring migration off DNF4/`python3-dnf`: `copr-rpmbuild`, `etckeeper`, `fedora-easy-karma`, `fedora-review`, `fedrq`, `kiwi`, `libreport`, `livecd-tools`, `mock-core-configs`, `needrestart`, `osbuild`, `python-coprtree`, `retrace-server`, `subscription-manager`, `system-config-language` * Build and compose tools (`mock`, `koji`, `pungi`) * Core administrative utilities (`ansible-core`, `cockpit`) == Contingency Plan == * Contingency mechanism: If critical infrastructure or blocking packages cannot finish migrating off `libdnf` v1 / `python3-dnf` or dropping `libmodulemd` before freeze, keep the legacy `dnf4`, `libdnf`, and `libmodulemd` packages in the repositories as standalone compatibility packages for one additional release cycle. * Contingency deadline: Beta Freeze. * Blocks release? No == Documentation == * Update system administration documentation on `docs.fedoraproject.org` to reflect the complete removal of DNF4, `microdnf`, and Modularity. * Refer developer and script authors to the official [https://dnf5.readthedocs.io/en/latest/tutorial/api-changes/index.html DNF5 API Migration Guide]. == Release Notes == Support for the legacy DNF4 stack (`dnf` 4.x, `microdnf`, `libdnf` v1, `python3-dnf`, `dnf-plugins-core`, `dnf-plugins-extras`) and Modularity (`libmodulemd`, `python3-libmodulemd`) has been completely removed in Fedora 46. All package management operations are driven exclusively by DNF5 and `libdnf5`. Custom scripts relying on `import dnf` or legacy `microdnf` calls must be updated to use DNF5 CLI or `libdnf5` Python bindings. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal: LMDB 1.0 Transition (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/LMDB_1_transition Discourse Poll - https://discussion.fedoraproject.org/t/f46-change-proposal-lmdb-1-0-transition-system-wide/204727/2 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the default LMDB to 1.0. Keep existing consumers on 0.9 through compatibility packages until they are ready to migrate. == Owner == * Name: [[User:spichugi|Simon Pichugin]] * Email: spichugi@redhat.com * Name: [[User:vashirov|Viktor Ashirov]] * Email: vashirov@redhat.com == Detailed Description == LMDB 1.0 changes the library ABI and database format. It cannot open databases created with LMDB 0.9. Update <code>lmdb</code>, <code>lmdb-libs</code>, <code>lmdb-devel</code> and <code>lmdb-doc</code> to 1.0.2. Add co-installable <code>lmdb0.9</code>, <code>lmdb0.9-libs</code> and <code>lmdb0.9-devel</code> at 0.9.36. The compatibility packages will preserve the old runtime SONAME and provide tools with <code>-0.9</code> suffixes, such as <code>mdb_dump-0.9</code>. All existing Fedora packages using system LMDB will be pinned to 0.9 and rebuilt in one side tag. Both libraries will use distinct ELF symbol versions so rebuilt consumers use the intended library when both versions are loaded into one process. Change approval, upstream agreement on the symbol versions and successful validation are required before merging. The compatibility packages will be maintained through at least Fedora 48's support lifetime. Retirement requires a separate Change, with no remaining Fedora consumers or supported upgrade paths depending on them. This transition targets Rawhide for Fedora 46; existing stable releases remain on 0.9. == Feedback == [https://bugzilla.redhat.com/show_bug.cgi?id=2495052 Bugzilla 2495052] raised upstream-readiness and database-compatibility concerns. Pinning existing consumers to 0.9 avoids rebuilding them against a library that cannot read their databases. == Benefit to Fedora == Make LMDB 1.0 available while preserving existing applications and databases. == Scope == * '''Proposal owners:''' package both versions, file a Bugzilla issue for every affected package, prepare dependency and build changes, provide migration tooling and documentation, and coordinate side-tag rebuilds and validation before merging. * '''Other developers:''' review these changes and test their packages with existing data. Migration to 1.0 can follow when upstream support and data migration are ready. * '''Release engineering:''' review the coordinated side-tag build, merge and rollback plan; https://forge.fedoraproject.org/releng/tickets/issues/13543 * '''Policies and guidelines:''' no changes. * '''Trademark approval:''' not needed. * '''Alignment with the Fedora Strategy:''' N/A. Affected consumers include applications and services, shared libraries and plugins, language bindings, and development packages used by downstream builds. Their Bugzilla issues will specify the required build, runtime, tool and transitive dependency changes and tests. Build dependencies will select <code>lmdb0.9-devel</code>, with explicit selection of the 0.9 headers and library. The co-installable development-package layout and build instructions will be finalized before rebuilds. == Upgrade/compatibility impact == Upgrades will install the 0.9 compatibility libraries required by pinned applications. Their database format remains unchanged; no automatic conversion occurs. The default <code>mdb_*</code> tools and <code>lmdb-devel</code> will use 1.0. Use tools such as <code>mdb_dump-0.9</code> and <code>mdb_copy-0.9</code> for 0.9 databases. Packaged consumers that invoke these tools will be updated to select the matching version; locally maintained scripts and build configurations may also need changes. Later migrations require tested export with <code>mdb_dump-0.9</code> and import with the 1.0 <code>mdb_load</code> into a new database, or regeneration for disposable data. Packages sharing databases must move together; bindings and libraries must document the impact on user-managed data. The planned <code>mdb_convert-0.9</code> helper must preserve main and named databases and leave originals intact for recovery. Custom comparators require application-specific migration. == Early Testing (Optional) == [https://copr.fedorainfracloud.org/coprs/vashirov/lmdb-1.0.0-soname-bump/ Initial COPR rebuilds] are available. Final compatibility-package and symbol-versioning tests are pending. == How To Test == * Verify co-installability of runtime, tool and development packages, including multilib. * Confirm rebuilt consumers use 0.9 headers, SONAME and symbol versions, including through transitive dependencies. Test bindings on supported architectures, including i686 where built. * Test upgrades with existing 0.9 data and confirm applications and their tool invocations continue to work. * Test processes loading both libraries in both load orders and confirm each consumer uses the intended version. * Test conversion of main and named databases, recovery from failures, and the package rollback procedure without losing access to either database format. == User Experience == Existing applications continue using their data. Maintainers control when each application moves to 1.0. == Dependencies == Compatibility-package availability, upstream symbol-version agreement and complete consumer pinning. OpenLDAP 2.7 uses bundled LMDB and is covered by a separate Change. == Contingency Plan == * '''Contingency mechanism:''' if validation is incomplete, the proposal owners will defer the side-tag merge and keep 0.9 as the default. If already merged, coordinate a package rollback with Release Engineering, using an Epoch bump if needed. Retain compatibility dependencies and keep 1.0 tools and their runtime available for data already created with 1.0. Package rollback will not convert databases back to 0.9. * '''Contingency deadline:''' Fedora 46 branching, 2027-02-09. * '''Blocks release?''' No. == Documentation == [https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_7_1/libraries/liblmdb/upgrading.doc Upstream upgrade notes]. Fedora instructions for selecting a library version, using the matching tools, migration and recovery will be published before the side-tag merge. == Release Notes == LMDB 1.0 becomes the default library for new builds and the default version of the command-line tools. Existing Fedora consumers remain on 0.9 compatibility packages, and their databases are not converted. Use the <code>-0.9</code> tools for 0.9 databases. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new