We are happy to announce that the Fall 2026 FreeBSD Vendor Summit will take place November 5-6, 2026, in San Jose, CA. The summit will be held at NetApp's San Jose campus. The summit will feature a single track of talks across two days. In addition, an on-campus reception will take place following the conclusion of the meeting sessions on Thursday, November 5th. We will share more details soon, including the detailed schedule, travel information, and the process for registration. We are now accepting talk proposals. Talks should be technical in nature and aim for 30-35 minutes in length, with an additional 10-15 minutes available for Q&A and will be given in person. Proposals for talks should include a brief abstract of the topic as well as a brief bio of the speaker(s). If you need more or less time, please include that detail in your proposal. Please submit talk proposals to devsummit@FreeBSD.org by September 16th. The summit is open to the public, and there will be a registration fee of US $150. Interested in sponsoring the Summit? Contact marketing@freebsdfoundation.org. Looking forward to seeing you in San Jose in November! -- Anne Dickison Deputy Director FreeBSD Foundation 510.332.8323
Thursday, August 6, 2026
Planning and gathering requirements for future Red Hat BugZilla replacement
Hello all, The BugZilla instance at bugzilla.redhat.com is planned to be decommissioned within the next ± half year. The Fedora project needs to plan for what to do in this rhbz-less future. As a first step, FESCo was tasked with documenting workflows ("gathering user stories") that currently rely on RHBZ ("requirements gathering"). We will also separately reach out to individual groups and stakeholders in the project (SIGs, working groups, initiatives, QE/QA, FOA, FCA, FPL, etc.) to ask these groups / people to document how they currently rely on bugzilla - and how these processes would be impacted by a move to a different bug tracking system and / or what potential alternatives could look like. I have set up a ticket tracker for this purpose - it is now open for workflow / "user story" ticket submissions: https://forge.fedoraproject.org/fesco/rhbz-replacement-requirements If there are any questions related to the process, the ticket tracker, or if there are problems with new submissions, feel free to reach out to me. On behalf of FESCo, Fabio -- _______________________________________________ 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
OpenBGPD 9.2 released
We have released OpenBGPD 9.2, which will be arriving in the OpenBGPD directory of your local OpenBSD mirror soon. This release includes the following changes to the previous release: * Require negotiation of the 'as-4byte' capability by default. Sessions with legacy speakers unable to handle this capability can still be downgraded through explicit configuration, but our long term goal is to drop support for old 2-byte only clients. * Rework fast reconnect and the IdleHold timer in a way that fixes too fast reconnects after a NOTIFICATION was sent out. * `bgpctl neighbor X up` now opens a connection to the neighbor for session in state active and sessions that are passive. * Various fixes in the Adj-RIB-Out handling and bring back optimized `addpath send all` updates. * Include example ASPA filter rule to the default config. * Further improve CH hash performance. * Automatically set 'fib-update no' when the extended nexthop encoding capability is configured. Currently IPv4 routes with IPv6 nexthops are supported only for the IX RS deployment use-case where there is no need for a FIB. * Enforce the use of 'fib-update no' when the extended nexthop encoding capability is configured. * Limit ASPATH and AS4_PATH attributes to a maximum of 750 elements. * Fix handling of unknown extended communities. * Improve the 'as-4byte' fixup handling for old 2byte only clients. When old clients use the extended message capability it is possible to trigger a case where the reconstructed ASPATH attribute would overflow the maximum buffer size. * Various fixes for defects found by a code review by 7ASecurity. According to their scoring system 0 critical, 1 high, 14 medium, and 3 low issues were found and fixed. One defect classified as medium is still open but only affects VPN and EVPN AFI/SAFI pairs. * Various minor fixes for defects detected by automated code review. OpenBGPD-portable is known to compile and run on FreeBSD and the Linux distributions Alpine, Debian, Fedora, RHEL/CentOS and Ubuntu. It is our hope that packagers take interest and help adapt OpenBGPD-portable to more distributions. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Wednesday, August 5, 2026
[announce] Tonight NYC*BUG: jpb on VIDAR
Note jpb will be remote, but there will be people watching at the Brass Monkey ** VIDAR - Server Protection for Internet facing FreeBSD Servers, Jim Brown 2026-08-05 @ 18:45 local (22:45 UTC) - Backroom of Brass Monkey 55 Little West 12th St Vidar is a combination of programs, a PostgreSQL database, and the SEC correlator engine that reads logfiles from authentication, email (postfix), and web server (nginx), (and potentially any other logs) and takes action based on SEC rules to add e ntries to an IPFW firewall. In concept it is similar to fail2ban and has some features in common with blocklistd. SEC reads the logs in real time and based on its rules and correlations, outputs metadata that is piped to a process that inserts the events into a PostgreSQL database and further pipes the offending IP address to a script that updates a table named “BAD” in IPFW. This table is read by IPFW rules to block offending external systems from wreaking havoc on a FreeBSD host. A corresponding table named GOOD contains whitelisted IP addresses so you don’t accidentally lock yourself out. <RANT> Are you sick and tired of seeing: 2a03:b0c0:3:d0::402:d001 - - [31/Jan/2026:17:37:17 -0500] \x16\x03\x01\x05\xDE\x01 ... in your nginx logs and sick of seeing: Feb 20 16:36:03 jimby dovecot[59472]: imap-login: Disconnected: Connection closed (no auth attempts in 5 secs): user=<>, rip=206.168.34.125, lip=174.136.97.66, TLS: Connection closed, ... in your mail logs and sick of seeing: Feb 20 12:47:58 jimby sshd-session[47730]: Invalid user zzzz from 2607:f170:44:12::5d0 port 520 in your authentication logs? With Vidar, you get to put the hammer down: “If you abuse my system, I will shut you out. Permanently.” </RANT> Vidar has additional tricks - a way to dump the IPFW BAD table and a way to import it later - you can keep this database of shame up to date on all those miscreants and keep them away. You can even import the BAD table on another FreeBSD system running IPFW. Also, there’s a handy audit script that lets you compare the entries in the database with what is actually in the IPFW BAD table. Also, Vidar keeps the evidence of the event in question that resulted in blocked access. Finally, using SEC rules, you can make the block last for an hour (for a misconfigured remote system) or a day (for a script kiddie), or permanently (for a determined hacker), or any length of time you choose. There is also a feature to check live processes and alert if, for example, the vi editor is running at 2:00am in the morning. Jim Brown is a long time BSD aficionado who currently lives in Durham, NC. Nearest NYC Subway is the 14th Street/Eighth Avenue station L, A, C, E. To get to the backroom, you must enter the front door, follow the long bar on your left, and walk all the way to the back. At the rear of the BrassMonkey, you will see an alcove for the 3 bathrooms our room is off to your right. _______________________________________________ announce mailing list announce@lists.nycbug.org https://lists.nycbug.org:8443/mailman/listinfo/announce
fedora-scm-requests has moved to Fedora Forge (Action: please update fedpkg)
Hello everyone, The fedora-scm-requests ticket queue has moved from pagure.io to Fedora Forge. New location: https://forge.fedoraproject.org/releng/fedora-scm-requests What this means for you ----------------------- This project is only the **request tracker** for new dist-git repositories, new branches, and related SCM admin automation. Dist-git itself has not moved; packages still live on https://src.fedoraproject.org/. `fedpkg request-repo` and `fedpkg request-branch` (and related flows that open tickets on this queue) now target Forge. Please update to a current fedpkg build so new requests go to the right place. Older fedpkg versions that still point at pagure.io will not work against the new queue. How to request repos and branches --------------------------------- Continue to use fedpkg as usual: fedpkg request-repo <package-name> <bugzilla-id> fedpkg request-branch --repo <package-name> <branch> See `fedpkg request-repo --help` and `fedpkg request-branch --help` for options. We strongly encourage using fedpkg rather than filing tickets by hand. The older pagure.io queue was migrated to Forge as https://forge.fedoraproject.org/releng/fedora-scm-requests-old and will live under the releng org as an archive for historical purposes. Do not open new requests there; use https://forge.fedoraproject.org/releng/fedora-scm-requests instead. If something goes wrong ----------------------- We are tracking migration follow-ups here: https://forge.fedoraproject.org/releng/tickets/issues/13108 If you hit a bug (failed request, wrong behaviour after updating fedpkg, etc.), please file a Releng ticket on the tracker: https://forge.fedoraproject.org/releng/tickets/issues You can also reach us in #releng:fedoraproject.org on Fedora Matrix. Thank you for your patience while we completed this move, and apologies for the delay. We know several of you were waiting for this cutover. Best, Samyak Jain Fedora Release Engineering Lead -- _______________________________________________ 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
Monday, August 3, 2026
CORRECTION: fedora-scm-requests migration start date and time
It was brought to my attention that I accidentally made a mistake in my previous announcement email. My apologies.
-- _______________________________________________ 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
List of long term FTBFS packages to be retired in a week
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 45 approximately one week before branching, i.e. 2026-08-05. 5 weekly reminders are required, this is the last one. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 42. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers ==================================================================== cvise mpolacek drumstick0 kkofler, yanqiyu golang-github-facebookincubator-go2chef @go-sig, dcavalca, salimma golang-github-jedib0t-pretty-6 @go-sig, eclipseo golang-github-kit @go-sig, alexsaezm gotun @go-sig, kushal knotes @kde-sig, orphan, than mingw-gsm valtri php-mtdowling-jmespath-php siwinski plotnetcfg jbenc rubygem-sinatra-cross_origin valtri tcl-pgtcl @db-sig, fjanus, praiskup tcl-tcludp spot tcl-tileqt spot tcl-tkpng spot tcl-tktreectrl spot The following packages require above mentioned packages: Depending on: drumstick0 (1) kmid2 (maintained by: cheeselee, kkofler) kmid2-2.4.0-34.fc44.src requires drumstick0-devel kmid2-2.4.0-34.fc44.x86_64 requires drumstick0, libdrumstick-alsa.so.0()(64bit), libdrumstick-file.so.0()(64bit) Depending on: knotes (1) kdepim (maintained by: @kde-sig, than) kdepim-7:17.12.3-20.fc45.x86_64 requires knotes Depending on: mingw-gsm (2) mingw-gstreamer1-plugins-bad-free (maintained by: elmarco, etrunko, mooninite) mingw-gstreamer1-plugins-bad-free-1.28.5-2.fc45.src requires mingw32-gsm, mingw64-gsm mingw32-gstreamer1-plugins-bad-free-1.28.5-2.fc45.noarch requires mingw32(libgsm-1.dll) mingw64-gstreamer1-plugins-bad-free-1.28.5-2.fc45.noarch requires mingw64(libgsm-1.dll) mingw-gtk4 (maintained by: elmarco) mingw-gtk4-4.22.2-3.fc45.src requires mingw32-gstreamer1-plugins-bad-free, mingw64-gstreamer1-plugins-bad-free mingw32-gtk4-4.22.2-3.fc45.noarch requires mingw32(libgstd3d12-1.0-0.dll), mingw32(libgstplay-1.0-0.dll) mingw64-gtk4-4.22.2-3.fc45.noarch requires mingw64(libgstd3d12-1.0-0.dll), mingw64(libgstplay-1.0-0.dll) Affected (co)maintainers @db-sig: tcl-pgtcl @go-sig: gotun, golang-github-jedib0t-pretty-6, golang-github-facebookincubator-go2chef, golang-github-kit @kde-sig: knotes alexsaezm: golang-github-kit cheeselee: drumstick0 dcavalca: golang-github-facebookincubator-go2chef eclipseo: golang-github-jedib0t-pretty-6 elmarco: mingw-gsm etrunko: mingw-gsm fjanus: tcl-pgtcl jbenc: plotnetcfg kkofler: drumstick0 kushal: gotun mooninite: mingw-gsm mpolacek: cvise praiskup: tcl-pgtcl salimma: golang-github-facebookincubator-go2chef siwinski: php-mtdowling-jmespath-php spot: tcl-tktreectrl, tcl-tcludp, tcl-tkpng, tcl-tileqt than: knotes valtri: rubygem-sinatra-cross_origin, mingw-gsm yanqiyu: drumstick0 -- _______________________________________________ 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
scm-requests moving to Forgejo, new fedpkg needed
-- _______________________________________________ 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
Thursday, July 30, 2026
F45 Changes TESTABLE deadline approaching - August 11, 2026
Hi all, If you are a change owner for F45, your change is required to be 'Testable'[1] by August 11, 2026 as per our release schedule[2]. Please ensure your tracker bug is updated with the latest information on the status of your change before this date and is in a testable state. If you are ahead of the game and your change is done, well done :) ! Please make sure you mark your change to ON_QA or Closed, or add a comment on the bug indicating what progress is made. F45 changes must be fully complete by August 25, 2026 before we enter Beta Freeze. If you would like to defer your change to F46[3], please let me know and I will update the tracking links accordingly. A full list of our current F45 change set can be found on the change set page[4]. Kindest regards, Aoife [1] https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process_milestones [2] https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html [3] https://fedorapeople.org/groups/schedule/f-46/f-46-key-tasks.html [4] https://fedoraproject.org/wiki/Releases/45/ChangeSet -- 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
Wednesday, July 29, 2026
Bouncing messages from freebsd-announce@FreeBSD.org
Hi, this is the Mlmmj program managing the <freebsd-announce@FreeBSD.org> mailing list. Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - 303, Message-ID: <20260729223421.2AD5715BF8@freefall.freebsd.org>
FreeBSD Security Advisory FreeBSD-SA-26:52.if_wg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:52.if_wg Security Advisory The FreeBSD Project Topic: Missing MAC validation in wg(4) packet decryption Category: core Module: if_wg Announced: 2026-07-29 Credits: Reo Shiseki Affects: All supported versions of FreeBSD. Corrected: 2026-07-29 17:48:41 UTC (stable/15, 15.1-STABLE) 2026-07-29 17:50:34 UTC (releng/15.1, 15.1-RELEASE-p2) 2026-07-29 17:50:08 UTC (releng/15.0, 15.0-RELEASE-p12) 2026-07-29 17:49:02 UTC (stable/14, 14.4-STABLE) 2026-07-29 17:49:36 UTC (releng/14.4, 14.4-RELEASE-p8) CVE Name: CVE-2026-58085 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 wg(4) is a kernel driver implementing the WireGuard VPN protocol. WireGuard uses ChaCha20-Poly1305, an authenticated encryption scheme, to protect tunnel traffic. The Poly1305 message authentication code (MAC) embedded in each data packet allows the receiver to verify that the packet has not been tampered with while in transit. The OpenCrypto framework (OCF) provides a generic interface to the kernel's implementation of various cryptographic transforms. Consumers submit a request via crypto_dispatch(), and OCF routes the request to a specific implementation of the requested transform. II. Problem Description After dispatching a decrypt operation to OCF and receiving the result, the wg(4) driver failed to check whether the MAC verification step succeeded. The driver thus silently accepted packets with an invalid Poly1305 authentication tag. III. Impact A remote attacker who can send UDP packets to a WireGuard endpoint, and who can guess the bounds of the receiver's replay window, can inject forged or modified transport data packets into the tunnel. A remote attacker who can intercept WireGuard packets bound for a FreeBSD host can modify the ciphertext and authenticated data without detection by the receiver. IV. Workaround No workaround is available. Systems that do not use wg(4) are not affected. 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:52/if_wg-15.patch # fetch https://security.FreeBSD.org/patches/SA-26:52/if_wg-15.patch.asc # gpg --verify if_wg-15.patch.asc [FreeBSD 14.x] # fetch https://security.FreeBSD.org/patches/SA-26:52/if_wg-14.patch # fetch https://security.FreeBSD.org/patches/SA-26:52/if_wg-14.patch.asc # gpg --verify if_wg-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/ 4c40cb62935f stable/15-n284645 releng/15.1/ b0254d23f508 releng/15.1-n283592 releng/15.0/ 13be8d6d86f3 releng/15.0-n281095 stable/14/ 825c6f45b147 stable/14-n274644 releng/14.4/ b20841b47153 releng/14.4-n273751 - ------------------------------------------------------------------------- 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-58085> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:52.if_wg.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmpqbkkbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvYT4P/1sjyQxTye1SElCc9UT5 DRVf9QXItIvjnWcsLAyNPd4EPLzhkiCUcnrYHirsSQoz3CiU1/DUev8WjWYJULoP 1zx8U/6xxz3x9aTFb9MEKRBt5jQ62PUGXCLf8SsYiFDFoKuIAYljl5q2J1QkfINc hwCaYZbqYLunCztREtyfI4NKx5PzqS9paAlY0h85u09hvXOGgz0NeZsaztSjNpTl i0VUbpP3KAtZyRRYgt1EpHxPkUEpvE9k2KU8cz7B5WZG3x7iwJQAk0kEq66MBx2L dxyPpTPOM0xkkgdffZ3rGFC0tCBF1uqij0Z07ltiOmJDRJBN2imHhHv1QH/8CtwA UpK3ukTq5ZRkh7dRy87v/ClirQCgMAHTy4L/sTI9imEp7m/6Hzv6Kse4UIhUo+wI sisC+Hmeb/tw716QNrZeF6CT7D3V82F3VYEBNc7+e6OACEYilmKyyKp6+3sczbv0 6IBgUjW8wQAWif2tbifQEUnxwpGhvVIAurZKnmKKN3y5OsHjaj48Lc36woVpxXPX jvuQflUEPPXsR6du4jPVceMAA+tN5fHnGmjWba5E1RtjSqIU6Q74L2hpfTA58Y2q yi/vSnOWk84jqXrUuL5JSGsSEQYGshOxHcWyeHndXxGMOjFmgmaoFDtVPvBQwuCo 0FQ8Cxd/bOL+VieyaGH14wtk =xml5 -----END PGP SIGNATURE-----
FreeBSD Security Advisory FreeBSD-SA-26:51.ktimer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:51.ktimer Security Advisory The FreeBSD Project Topic: Kernel stack disclosure via timer_settime(2) Category: core Module: ktimer Announced: 2026-07-29 Credits: Hazley Samsudin of GovTech CSG Affects: FreeBSD 15.1 and 15.0 Corrected: 2026-07-27 19:15:01 UTC (stable/15, 15.1-STABLE) 2026-07-29 17:50:30 UTC (releng/15.1, 15.1-RELEASE-p2) 2026-07-29 17:50:05 UTC (releng/15.0, 15.0-RELEASE-p12) CVE Name: CVE-2026-58084 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 POSIX interval timers, managed by timer_create(2) and timer_settime(2), allow a process to schedule periodic or one-shot notifications based on a specified clock source. When timer_settime(2) is called with a non-NULL old_value argument, the kernel returns the timer's previous setting. II. Problem Description To retrieve the previous timer value, the kernel calls realtimer_gettime(), which obtains the current time for the timer's clock. For a timer using CLOCK_TAI this can fail when no TAI offset has been configured, but the error return was not checked, so the uninitialized output buffer was copied to userspace. III. Impact An unprivileged local user can obtain uninitialized kernel stack memory by creating a POSIX timer with CLOCK_TAI and calling timer_settime(2), potentially disclosing sensitive kernel data. IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and 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:51/ktimer.patch # fetch https://security.FreeBSD.org/patches/SA-26:51/ktimer.patch.asc # gpg --verify ktimer.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/ a4b5ff57ef85 stable/15-n284618 releng/15.1/ e1c9b0b13a29 releng/15.1-n283589 releng/15.0/ 3254ef000750 releng/15.0-n281092 - ------------------------------------------------------------------------- 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-58084> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:51.ktimer.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmpqbkcbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv4p8P/3J3oX0usjnb08Xq+wBh u5GYBpPUUeTrJQkPqqmZon5UVRYoXobemhZ3k/sB1xX+VqxLZBbN9SO+7p5PYCAu cOfeirWH+sLj6vCK24ZHJ02mA3KASsHCKoaKxtxj77eKE+3dl3TT8ss9dzC7HgRy RqLDELyQnkOgeoXwm7jTxC1OhqP7rjZQiFdiOffy75C4wxWxJEqqpQazVBeqPefo gNnFdH5/6F8uJVrKysw+TJtGrVzoQnxVhJ3pho3YXJyPFBviA4FcTg3HJNjp0DrO Eg0/8W1R8s2ohyiBjFgoaTZGZyNaQ82F19eYp1XP/ZzeS0biZvYQZ6bTXjM4Pf92 NOGKM65/ZZguHZMce3Yqf/czUkn9yG0aK+eeD5oQnC3HutQdfrQw+vzL9w51DJ0f VyCTH1Gj/x4BcyuBSCLiiWjaL5VVKpPLx3BhNgkQv5KAKiJayLd+kqp42lqPAGwr cBNdhL1awbmQtGkicl2suoongpVS6Doth92LjeB3pLT5DKZy5g4T0a/bvSdb+ghi HS8wjhvJFMl9PiXJC7h03XdTS1EUD8nbwvq4g1ho0qeS7xVpcWcb/DWkhcVts2eI rXe0TQwWdiQvKP7dUWpp8zdpNgpRDp1mGLiH9ojx/xChnMH1Rsu2pStlhY6F1ZjS Q7CDj///8ewA1AcGomzzTei0 =A9FX -----END PGP SIGNATURE-----