F45 Change Proposal: libxml215 (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/Libxml215 Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-libxml215-system-wide/193575 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 <code>libxml2</code> library from version 2.13.9 to 2.15.3. This release includes critical security fixes and requires a system-wide mass rebuild due to an ABI (soname) change. Additionally, this update marks the official deprecation of the libxml2 Python bindings, which are scheduled for removal in 2.16. == Owner == * Name: [[User:Amigadave| David King]] * Email: amigadave@amigadave.com == Detailed Description == The update to 2.15.3 is necessary to address several security vulnerabilities fixed only in version 2.15.2 and above. Version 2.14 introduces an ABI change, requiring all packages linked against libxml2 to be rebuilt. Furthermore, upstream has deprecated the libxml2 Python bindings. While these remain present in 2.15.3, they will be removed in 2.16. Fedora packages currently using these bindings must be ported to alternatives, such as python3-lxml or the standard library's xml.etree. Concretely, this will mean that the python3-libxml2 subpackage will be marked as deprecated. == Feedback == == Benefit to Fedora == * Security: Several security vulnerabilities, that are only fixed in 2.15.2 and above, are fixed in this release * Modernization: Aligns Fedora with the latest upstream release, which sees security and bugfixes. == Scope == * Proposal owners: ** Perform the {{package|libxml2}} library update in Rawhide. ** Coordinate the mass rebuild with Release Engineering. ** Deprecation Management: *** Audit all packages in Fedora using <code>python3-libxml2</code>. *** Notify maintainers of affected packages. *** Provide guidance/patches for migrating to <code>lxml</code> or <code>ElementTree</code>. * Other developers: ** Mass Rebuild: Maintainers of packages depending on <code>libxml2</code> must ensure their packages rebuild successfully against the new ABI. ** Migration: Maintainers of packages relying on the Python bindings in <code>python3-libxml2</code> must begin porting their code to alternative libraries before the planned removal in 2.16. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13382 #13382] ** A mass rebuild will be required due to the ABI change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == * C ABI: Applications not rebuilt will fail to run due to the soname change. * Python ABI: Although applications using the Python bindings will run, the applications will need to be ported to alternative APIs before libxml2 2.16 is released. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N Proposed MR for the package update to 2.15.3: https://src.fedoraproject.org/rpms/libxml2/pull-request/16 == How To Test == There should be no user-visible changes to test, as the majority of the upstream changes are removing old and unused code in the libxml2 library. A mass rebuild of dependent packages is the most effective test, but testing that functionality using libxml2 in those packages still works as expected will be useful. == User Experience == == Dependencies == Preliminary list of packages depending on libxml2: approximately 600 binary packages, including many critical path packages. Preliminary list of packages depending on python3-libxml2, which will be affected by the deprecation and eventual removal: *beaker-client *gnome-doc-utils *imagefactory *itstool *koji-vm *ovfenv- *python3-dmidecode *python3-libxslt *rteval *setroubleshoot-server *virt-manager-common == Contingency Plan == ** ABI Breakage: If the mass rebuild is unsuccessful or reveals widespread, unresolvable issues, revert to 2.13.9. ** Binding Deprecation: If a critical system package cannot be ported away from the libxml2 Python bindings in time, we will maintain the bindings in a separate legacy package (python3-libxml2-legacy) as a temporary measure until the migration is completed. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == There were many removals and deprecations between 2.13.9 and 2.15.3, including: * Removal of FTP, HTTP and LZMA support * Removal of the <code>libxml.m4</code> autoconf macros * Deprecation of direct struct access, with many accessor functions added In addition, many other bugfixes and security fixes were added, including: * CVE-2026-1757 fix: Memory leak in xmllint Shell - shell.c * CVE-2026-0990 fix: Prevent infinite recursion in xmlCatalogListXMLResolve * CVE-2026-0992 fix: Exponential behavior when handling * parser: Fix infinite loop in xmlCtxtParseContent * CVE-2025-10911 libxslt related: Ignore next/prev of documents when traversing XPath * CVE-2026-0989 fix: Add RelaxNG include limit == 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

F45 Change Proposal: Grub EFI For Confidential Computing (self-contained)

Wiki - https://fedoraproject.org/wiki/Changes/Grub2LightForConfidentialComputing Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-grub-efi-for-confidential-computing-self-contained/193574 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 == An independent separate incarnation (package) of the GRUB bootloader for UEFI only that contains a minimal number of built-in modules, and can quickly boot a Unified Kernel Image (UKI) using Bootloader Specification (BLS) files. It will be built separately from the main GRUB package, and does not replace it for general usage. == Owner == * Name: [[User:lsandova| Leo Sandoval]] | lsandova@redhat.com * Name: [[User:mlewando| Marta Lewandowska]] | mlewando@redhat.com == Detailed Description == There is a need for a smaller, lighter version of the GRUB bootloader on UEFI to support booting sealed bootable container images, such as for Confidential Computing. Since confidential VMs rely on remote attestation, TPM PCR values need to be stable and predictable over long periods of time. Updating the bootloader results in changes to PCRs, and should therefore be avoided if possible. Additionally, Unified Kernel Images (UKIs) have become the preferred choice over the regular signed kernel because the whole payload is bundled and signed for Secure Boot, thus removing the vulnerability of the unsigned initramfs. They are used often in virtual environments, for confidential computing, and by CoreOS. Taken together, the ideal bootloader for these types of environments should be small, light, and not get updated too often. The fewer modules are built-in, the smaller the attack surface, and the less frequent updates need to be. The resulting idea is to create a smaller version of GRUB, the supported bootloader in most Linux environments, for UEFI, which is built as a separate package from the main GRUB build, contains only the modules that are absolutely necessary for VMs, and natively supports UKI loading. This new package is not meant to be a replacement for GRUB for general use; rather it's an additional package for specific applications. A separate rpm that is still a part of the grub2 build is already available for [https://kojipkgs.fedoraproject.org//packages/grub2/2.12/60.fc45/x86_64/grub2-efi-x64-cc-2.12-60.fc45.x86_64.rpm x86_64] and [https://kojipkgs.fedoraproject.org//packages/grub2/2.12/60.fc45/aarch64/grub2-efi-aa64-cc-2.12-60.fc45.aarch64.rpm aarch64] in Fedora Rawhide for testing. It is signed for Secure Boot with the GRUB key. In the future, it is expected to get its own Secure Boot signing key. Work is in progress to add support for this new build of GRUB in bootupd to enable safe bootloader updates on bootable container systems: https://github.com/coreos/bootupd/issues/1080 == Feedback == The original idea was to use systemd-boot for this application, but this was rejected for a number of reasons: * While the systemd team can support sd-boot in its present form, they view any additional features as a no-go * Although sd-boot is a light and trivial bootloader, it has not been widely tested or fuzzed, like GRUB has been * Long term maintenance of more than one bootloader would result in a lack of parity and added technical debt * Potential expansion to other architectures would necessitate a compatible bootloader anyway. The new lighter GRUB build is already being tested by CoreOS, and is generally working as expected. Small changes are still being made, and suggestions for changes are welcome. == Benefit to Fedora == This change will create a minimal UEFI bootloader for virtual environments that can further be tailored for use in those environments. It will natively load UKIs, support Secure Boot, and be a part of a robust and tested bootloader used in many Linux environments. == Scope == * Proposal owners: The bootloader engineering team needs to create a new GRUB package, separate from the core package that includes all the changes mentioned. * Other developers: CoreOS, who will be the main users, at least in the beginning, need to test, provide feedback, and perhaps change some of their workflows as needed. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This is a new package, independent of the normal all-purpose GRUB, so unless a user installs it on purpose, there is no compatibility impact. == Early Testing (Optional) == This new package is designed specifically for VMs that run UEFI firmware, so an x86_64 or aarch64 VM is the environment to use. ===Prepare the test environment:=== * Install or create one or more UKIs ** Install `kernel-uki-virt` and add a command line addon using `ukify`, see instructions below ** Use `ukify` to create the UKI from scratch, see instructions below * If booting with Secure Boot enabled, sign your add-on or UKI, and enroll your public key in the MOK, see instructions below.<br> '''If you will not sign your UKI/addon, don't forget to disable Secure Boot.''' * Create the `/boot/efi/loader/entries` directory * Create BLS entries in that directory for each UKI. Specify the path to the UKI using the `efi` keyword, as you normally would use `linux` for the kernel. A minimal BLS file only needs to have a title and the path to the UKI: <pre> # cat /boot/efi/loader/entries/7.0.10-200-UKI.fc45.x86_64.conf title Fedora 45 UKI (7.0.10-200.fc45.x86_64) efi /EFI/Linux/7.0.10-200.fc45.x86_64.efi </pre> === (If you don't feel like doing all of that, you can boot regular kernels instead): === Because this version of GRUB is intended for UKIs, it expects those UKIs to be on the EFI system partition, but it can load a regular kernel too, as long as it's in the correct place. If you copy a kernel and its initrd from `/boot` to `/boot/efi/EFI/Linux` and that kernel's BLS configuration file from `/boot/loader/entries` to `/boot/efi/loader/entries` (and edit it to reflect the correct paths), then it should simply boot as usual. === Test: === * Download the [https://kojipkgs.fedoraproject.org//packages/grub2/2.12/60.fc45/x86_64/grub2-efi-x64-cc-2.12-60.fc45.x86_64.rpm grub2-efi-x64-cc rpm], unpack it, and replace your regular grub efi with it: <pre> # cp ./usr/lib/efi/grub2/1\:2.12-60.fc45/EFI/fedora/cc/grubx64-cc.efi /boot/efi/EFI/fedora/grubx64.efi </pre> * Reboot your machine You should see the GRUB menu with entries for each of the UKIs that you installed. If you press 'e' to edit an entry, you should see something like `chainloader /path/to/UKI` and when you execute any of the entries, they should successfully boot. You can check the size of the efi, and see that it is smaller than the normal grubx64.efi. Use the `tpm2_pcrread` command between reboots of different UKIs to see that the value of PCR8 does not change. ==== How to build your own UKI addon ==== The generic UKI that fedora ships has only `console=tty0 console=ttyS0` on its kernel command line. In order for it to actually boot on your system, it needs more information, like the root filesystem UUID, which you can see if you `# cat /proc/cmdline`. Since the UKI already has the command line bundled, you need to create a command line addon containing the additional information. You can do this using the [https://www.man7.org/linux/man-pages//man1/ukify.1.html ukify] command. First get the generic UKI by installing `kernel-virt-uki` and the command by installing `systemd-ukify`. Then something like this should work: <pre> # ukify build \ -cmdline "$(cat /proc/cmdline | cut -d' ' -f2-6)" \ --output set_root.unsigned.addon.efi </pre> You then need to copy the addon to the UKI's extra.d directory in `/boot/efi/EFI/Linux/` if you want to only apply it to a single UKI, or create `/boot/efi/loader/addons/` and copy it there, if you want it to work for all UKIs. (If you are planning to sign the addon, wait to move it until after you have signed it.) ==== How to build your own UKI ==== You can build your own UKI using kernels and initrds that you already have installed on your system once you have also installed `systemd-ukify`. Building one for the running kernel using the [https://www.man7.org/linux/man-pages//man1/ukify.1.html ukify] command, looks like this: <pre> # ukify build \ --linux /usr/lib/modules/$(uname -r)/vmlinuz \ --initrd /boot/initramfs-$(uname -r).img \ --uname $(uname -r) \ --cmdline "$(cat /proc/cmdline | cut -d' ' -f2-6)" \ --output kernel-$(uname -r | rev | cut -d'.' -f3-6 | rev)-UKI.efi \ --profile "kernel $(uname -r | rev | cut -d'.' -f3-6 | rev) UKI (Fedora $(cat /etc/os-release | grep VERSION_ID | sed -e 's/VERSION_ID=//g'))" </pre> You then need to copy the UKI to the correct directory. Typically this is `/boot/efi/EFI/Linux/` but can be the directory of your choosing, as long as you specify that in the UKI's BLS file. (If you are planning to sign the UKI, wait to move it until after you have signed it.) ==== How to sign for Secure Boot ==== It's actually possible to sign your UKI or addon during the ukify build, but this more generic procedure can be used to sign any artifact for Secure Boot. Install `openssl` and `pesign` and generate your signing key: <pre> # openssl req -quiet -newkey rsa:4096 -nodes \ -keyout custom_db.key -new -x509 -sha256 -days 3650 \ -subj "/CN=UKI Signing key/" \ --outform DER -out custom_db.der </pre> In this case the key size is 4096 bit, uses [https://en.wikipedia.org/wiki/RSA_cryptosystem RSA] for encryption, and can be used for signing for 10 years. Import the public key into the NSS database that `pesign` uses and give it a nickname: <pre> # certutil -A -t ",," -d /etc/pki/pesign -n \ 'My Secureboot Signer' -i custom_db.der </pre> Convert the public and private keys to PKCS12 format and import the result to enable signing using `pesign`: <pre> # openssl pkcs12 -export -out custom_db.pfx \ -inkey custom_db.key -in custom_db.der </pre> <pre> # pk12util -i custom_db.pfx \ -d/etc/pki/pesign -n 'My Secureboot Signer' </pre> Sign your UKI or addon with your private key: <pre> # pesign --certificate 'My Secureboot Signer' \ --in set_root.unsigned.addon.efi \ --out set_root.addon.efi --sign </pre> Move or copy the UKI or addon to the proper directory, see above. Import your public key into the Machine Owner Key (MOK) database: <pre> # mokutil --import custom_db.der </pre> You will be asked to create a password. You need to reboot the machine to complete the enrollment, and you will be asked for this password at that time. After rebooting, you can check that your key is actually in the MOK database: <pre> # mokutil --list-enrolled </pre> == Dependencies == N/A as this is a new package. == Documentation == N/A (not a System Wide Change) or to be determined. == Release Notes == To be determined. -- 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

FreeBSD Security Advisory FreeBSD-SA-26:32.elf

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:32.elf Security Advisory The FreeBSD Project Topic: ASLR bypass for setuid executables via procctl(2) Category: core Module: kernel Announced: 2026-06-09 Credits: Synacktiv Affects: All supported versions of FreeBSD Corrected: 2026-06-09 19:17:35 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:13 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:51 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-06-09 19:17:53 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:13 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:43 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-49414 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 Address Space Layout Randomization (ASLR) randomizes the base addresses of executable images and shared libraries in a process's address space. FreeBSD enables ASLR by default for Position-Independent Executables (PIEs). The procctl(2) system call allows a process to set per-process ASLR preferences, including force-disabling randomization. When a setuid or setgid binary is executed, the kernel is expected to ignore any such user-set preferences if they come from an unprivileged user. II. Problem Description The ELF image activator cleared per-process ASLR preference flags for setuid binaries after the code that computes the PIE base address, rather than before. As a result, a user-requested ASLR disable was still in effect at the point where the base address was chosen. III. Impact An unprivileged local user can disable ASLR for a setuid PIE binary by calling procctl(2) before execve(2). This makes exploitation of any separate memory corruption vulnerability in that binary significantly easier. 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 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:32/elf-15.patch # fetch https://security.FreeBSD.org/patches/SA-26:32/elf-15.patch.asc # gpg --verify elf-15.patch.asc [FreeBSD 14.4] # fetch https://security.FreeBSD.org/patches/SA-26:32/elf-14.4.patch # fetch https://security.FreeBSD.org/patches/SA-26:32/elf-14.4.patch.asc # gpg --verify elf-14.4.patch.asc [FreeBSD 14.3] # fetch https://security.FreeBSD.org/patches/SA-26:32/elf-14.3.patch # fetch https://security.FreeBSD.org/patches/SA-26:32/elf-14.3.patch.asc # gpg --verify elf-14.3.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ e1cdc49846c1 stable/15-n283888 releng/15.1/ 796579bcfbc4 releng/15.1-n283557 releng/15.0/ 6e51dfc401e7 releng/15.0-n281059 stable/14/ e417948e6139 stable/14-n274317 releng/14.4/ 547fc2a98a24 releng/14.4-n273721 releng/14.3/ 744f62ccbf82 releng/14.3-n271521 - ------------------------------------------------------------------------- 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-49414> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:32.elf.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmoolxcbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvzjAP/izsPLlrhPmUVbO6pLVA 22HiuxV4URIIzMe4SbVa8ALyWM85TNAKjRUyr7VwAslFvfzRCtL0o/w0Fypsvoss a4jpiC8QHjeUFlRz6fmYq4sgHZdi/sz0zOmGKHVYiCA1Jdrp1tM4NxkKeDquc61d iD1yulnjkr8axb4gv4Y/C1McT7fvECbiaK9ni/vgwwluy0cqRIz7rPe8NrAD6pYn 1WPgkHmGeNwpIhPHbBd9WCoQNiU+BLyNyuFASWjZWiIMiMwCKQdvm0qVJ1fPWxeP 2GxxpWfoftwDkRy1/tURs0dVuI+Ko40sTFKiUVUMyOu0ndnyuR8VGICWlwA903yY N05s8R65FpXJbERu3Bc4HO+fKzQxCqWocgcUHBI9VO9QGIcNRR1S1PgkltNUI0wI KTJith+ru6XFRK5ts74cBR7i2p2r+cVFs/FyzXXP1v4A1U+Fe6PwwdhWdwJy9r4s aOJPh5b5Go2BvRayptPt+18vdXm8N4L1xk94lk/h9X6lrMe9+WhWnH1BUnMD3dVm m8mSczWkkveFNiEfj3WGdbTlpVvXUqHdwIx+v2obj0fBUDkg9r1M2ZZjaW3DEPM9 aLOrjdK9t+ntJyNBQCnNCRZFaiFGHK9bdEjm9WhyfMAnxoKg1hNhzhq+jyxrPDZY OY6FBpNTQ9NhGUkgpkgArAEj =unW5 -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:31.arm64

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:31.arm64 Security Advisory The FreeBSD Project Topic: Arm CPU errata may bypass page table permission changes Category: core Module: arm64 Announced: 2026-06-09 Affects: All supported versions of FreeBSD Corrected: 2026-06-09 19:17:34 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:12 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:50 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-06-09 19:17:51 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:12 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:41 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2025-10263 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 Page tables control the translation of virtual addresses to physical addresses and the access permissions on those addresses. On Arm CPUs, when page table permissions are updated, a TLB Invalidate (TLBI) instruction followed by a Data Synchronization Barrier (DSB) must be issued to ensure subsequent accesses observe the new permissions. II. Problem Description Some Arm CPUs have errata where the ordering of stores and the TLBI+DSB sequence may be incorrect. If one CPU stores to a virtual address while another CPU invalidates the translation for that address, the second CPU's TLBI+DSB may complete before the first CPU's store has been globally observed. III. Impact This erratum may allow software to write to a previously writable location after the page table is modified to forbid writes to that location. Consequently this may allow software to write to memory owned by a higher exception level, possibly allowing software to escalate privilege to that higher exception level. IV. Workaround No workaround is available. The following ARM CPU models are affected: C1-Premium C1-Ultra Cortex-A76 Cortex-A76AE Cortex-A77 Cortex-A78 Cortex-A78AE Cortex-A78C Cortex-A710 Cortex-X1 Cortex-X1C Cortex-X2 Cortex-X3 Cortex-X4 Cortex-X925 Neoverse-N1 Neoverse-N2 Neoverse-V1 Neoverse-V2 Neoverse-V3 Neoverse-V3AE 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 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:31/arm64-15.patch # fetch https://security.FreeBSD.org/patches/SA-26:31/arm64-15.patch.asc # gpg --verify arm64-15.patch.asc [FreeBSD 14.4] # fetch https://security.FreeBSD.org/patches/SA-26:31/arm64-14.4.patch # fetch https://security.FreeBSD.org/patches/SA-26:31/arm64-14.4.patch.asc # gpg --verify arm64-14.4.patch.asc [FreeBSD 14.3] # fetch https://security.FreeBSD.org/patches/SA-26:31/arm64-14.3.patch # fetch https://security.FreeBSD.org/patches/SA-26:31/arm64-14.3.patch.asc # gpg --verify arm64-14.3.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 9d9d6c6e6081 stable/15-n283887 releng/15.1/ 81435fc0882c releng/15.1-n283556 releng/15.0/ a53619675cdc releng/15.0-n281058 stable/14/ e99aa8682dba stable/14-n274316 releng/14.4/ 889e306ded21 releng/14.4-n273720 releng/14.3/ 61d0cea4c00f releng/14.3-n271520 - ------------------------------------------------------------------------- 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-2025-10263> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:31.arm64.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmooiWIbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv4nwP/3M5KElYqojhl044KzbV UyoCXW3MoTm+aXnjlkf2f6+00EHtEkmboe3fYGwsUGFOp9uk0iNgDCE1jMmAhDY7 AJSegcxbUVhCcZwxfaUkIDRtv3iYt4vkN59se62/QrgA/2UiyBRWMJLYvLN4ZF0C 7xuwJVyJjHq65Z1jU4noaXQ/UqaCQgPJBmZ2XL+OMfJtdHZdproN3vL/7BLXaPwv wuiZSc/agrBQgnbv4IFlNWc/LtXo+Hh3/vSSw3U2GUnNHARLxb62Kj2vaMz9HWP3 ObykAXru4hpLXdRndf+dsqHCow6slbb89Iqzn93axbmvhxvuOdNNkNkS0Yfj+B9Y kMuDMqTR8Q+wXFY5JlTsTGGH8paDdyYWeZUHsI+2HqgYWS8CMQJwal2hErT4TG82 gU0xIIpZKHc09FMsw+z/TjNZO0aLQbbZAN45qpqdvZoQ174jX/ZVtkIGEOSQXyQA YT4O/yozBjNABBTYtCTVwdnJjM6L4sva2mKbtGnCTS/3tC2dVgEhsgE2zwzHtGPv lAtJwTbqyLBOP+aUFh2w0OaNwy0c5bB88AxyS/EKcliHtyAveedbXYFjLLVIMhLY tpodoCSwrM6PgkddWy6+YVCbcoD6JfS1U5T2IH0EJXPSQvV8SPbs3LRY4F7O5zDi x+jJy5JL/2hjps/C/581Iq5y =SmlG -----END PGP SIGNATURE-----

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: - 267, Message-ID: <20260609231335.2F2F41FC54@freefall.freebsd.org>

FreeBSD Security Advisory FreeBSD-SA-26:28.capsicum

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:28.capsicum Security Advisory The FreeBSD Project Topic: sigqueue(2) missing capability mode restriction Category: core Module: capsicum Announced: 2026-06-09 Credits: Ed Maste Affects: All supported versions of FreeBSD. Corrected: 2026-05-29 19:11:40 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:09 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:46 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-05-29 19:12:58 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:08 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:38 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-45259 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 Capsicum is a lightweight OS capability and sandbox framework. It provides two kernel primitives: capability mode, and capabilities. Capability mode restricts the ability of a sandboxed process to interact with the global namespace, including the ability to send signals to other processes, other than via capability-based interfaces. In capability mode, kill(2) restricts signal delivery to the calling process only, preventing a sandboxed process from signalling other processes. sigqueue(2) provides similar signal delivery functionality, and is similarly permitted in capability mode. II. Problem Description sigqueue(2) was marked as permitted in capability mode with the introduction of Capsicum in 2011, but the implementation of kern_sigqueue did not include a capability mode check restricting signal delivery to the calling process's own PID. III. Impact A process in capability mode can use sigqueue(2) to send signals to any process it could signal following standard Unix permissions, bypassing the Capsicum sandbox restriction. A compromised sandboxed process could interfere with other processes, for example by sending SIGKILL or SIGSTOP. This could be any process running as the same user, or any process, for a superuser sandboxed process. 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. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE 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.1] # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-15.1.patch # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-15.1.patch.asc # gpg --verify capsicum-15.1.patch.asc [FreeBSD 15.0] # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-15.0.patch # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-15.0.patch.asc # gpg --verify capsicum-15.0.patch.asc [FreeBSD 14.x] # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-14.patch # fetch https://security.FreeBSD.org/patches/SA-26:28/capsicum-14.patch.asc # gpg --verify capsicum-14.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ defd9b86ef99 stable/15-n283744 releng/15.1/ 871d33e8a66a releng/15.1-n283553 releng/15.0/ 77ee83d12625 releng/15.0-n281055 stable/14/ d11ff01b3aec stable/14-n274231 releng/14.4/ eab757f954ed releng/14.4-n273717 releng/14.3/ f56e8cb94df6 releng/14.3-n271517 - ------------------------------------------------------------------------- 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-45259> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:28.capsicum.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmoolxAbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv9xQQALSpP1xklc9UjGzlSpTo 2owWykX02TVDqd7a57jEFpak6F9sJ1B83jrkEQVIGjBGQpTIWYt/C34QEzeo502F +dqfqXr32MyudPDq+lsWB7HhafG/gktTDpibJrQkqPDdTc+TwzzhoHxGAdckAMsr vCqnUF6UmtmTzQEyoQBqPGPWbVnyVboOQ0ZvKouMZdMBVlC7IvWPDlbpMEOLePTE NPHeuxFYbFHMUkOLq97Dhg4XTqdIG0t3n/0jA1kjCDvJWDbXpR1bPy1USTNxHO35 xjeZshL2IWXDJSxLFBNE+cNFwg4dyp5vXcQXh3HtyMC9PMPMyIbJT7zQluV3CVI7 9gC6MMH7QiLssj5hJqMSXccrNzkag6Alu9ET5A/NtoGjyogbXmIPsQ9hLAqf/c9v 5m4O86dlHBL/JsGcPqsGw3+gucqgso2gy4yQ8h1GqGwNGv440TMAHRz5eAu+qOZq tDxo3OqK3HIEoChiQaRZp5bc/p0L1Rfka10J0HmIxB2KkdHEjdMn5SBsEYRsIv5v Sp34rl0cLm0oHraIQ0jNVTwZetrxl4CMIAexHYO1hJ+jZDRdBQ5CC7S83+t2Tbnu JgRsm6A+1TZfWsaflIx9ga42DEndXgqpmdrtjIFoO1zNQjrvcd3sqJH6GTMNdywg 2woyv6Bb/bwINWDE7EhicoJl =WJPW -----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:27.sound Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities in the sound(4) mmap path Category: core Module: sound Announced: 2026-06-09 Credits: Lexpl0it, 75Acol, ch0wn, zer0duck (CVE-2026-45258) Credits: Emmanuel Genier from Quarkslab (CVE-2026-45258) Credits: Hazley Samsudin of GovTech CSG (CVE-2026-45258) Credits: Lexpl0it, 75Acol, Liyw979, Rob1n (CVE-2026-49417) Affects: All supported versions of FreeBSD. Corrected: 2026-06-09 19:17:31 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:08 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:45 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-06-09 19:17:48 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:07 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:37 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-45258, CVE-2026-49417 CVE-2026-45258 was independently reported by multiple parties prior to publication. 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 use mmap(2) on these devices to map a channel's audio buffer directly into their address space. II. Problem Description The sound(4) driver contained two memory-safety errors in its mmap(2) support. First, dsp_mmap_single() validated the requested mapping by checking the sum of the user-supplied offset and length against the buffer size. This addition could overflow, so that a large offset and length wrapped around and passed the check. The offset was then narrowed from 64 to 32 bits when converted to a buffer address, yielding a mapping that extended past the audio buffer into unrelated kernel memory. (CVE-2026-45258) Second, the audio buffer backing a mapping could be freed when the device was closed even though the mapping remained valid. The freed memory could then be reused elsewhere while still accessible through the stale mapping. (CVE-2026-49417) III. Impact The /dev/dsp device nodes are world-accessible by default. On a system with an audio device, either issue allows an unprivileged local user to read and write kernel memory, which can be used to escalate privileges, potentially gaining full control of the affected system. At a minimum, an attacker can crash the kernel, resulting in a Denial of Service (DoS). 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 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.1] # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-15.1.patch # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-15.1.patch.asc # gpg --verify sound-15.1.patch.asc [FreeBSD 15.0] # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-15.0.patch # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-15.0.patch.asc # gpg --verify sound-15.0.patch.asc [FreeBSD 14.4] # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-14.4.patch # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-14.4.patch.asc # gpg --verify sound-14.4.patch.asc [FreeBSD 14.3] # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-14.3.patch # fetch https://security.FreeBSD.org/patches/SA-26:27/sound-14.3.patch.asc # gpg --verify sound-14.3.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 7628e1ddfd52 stable/15-n283884 releng/15.1/ abc077216bac releng/15.1-n283552 releng/15.0/ bda153dc04b4 releng/15.0-n281054 stable/14/ f8f9050d61dd stable/14-n274313 releng/14.4/ 0e8cc8d8a49f releng/14.4-n273716 releng/14.3/ de5fd56985c3 releng/14.3-n271516 - ------------------------------------------------------------------------- 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-45258> <URL:https://www.cve.org/CVERecord?id=CVE-2026-49417> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:27.sound.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmooiU8bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvWEsP/0Ge9wC58QJLIkykVAHl hZoU1NU0DaY6L03B4dDiQkbX03CZK4taPmOE6Wp4AjxJztw0gF2SyWY1xHeUafPY NzNGJFhSA+Y6yGiBhffDtewUdfFnHg7JVvmU5KYj5xfKrxSksYOnv8KOuGeI1Vw0 A25TIrP5bKVFu45s2SCNrCHeXMl2Nm2ObMFdd0ZF04abcXyMQbSLlWDA15ZvtSXB e1nOKZTrfHFSGXIx83SqtkTMY0SRbNvGZk3uUAlIXeQR2q4kInyNy42R3j/av4fh 0Il0ZLapO6lTfJwwl9E+ZB4OpE3LJdMap1rrspGo/XMFZOACFCkyrBiKSQHkhkDU WAHtGNOvKXCll4O0LZfEjQkQnGsBhJtmhthF95O8cADXZG+G1crj3+IBL8TLRUWw QsH9dGrD4rNUWaAueztPUEza4zJdbTAgEfSHvauuAlq6LCmrjiyJFmNYvPsNlRGG JMJa5PKEgguR/8054XHlsN8GdxYup8b8bYp55KcTbAjfyj+HAQIJp17tpZKiJjR5 wfaMtkNhCgzM44oGaWbVpwOMeWB/YtrkR3h+ROzAwVallVBoIuUWzu4as3sSOB+a GSwkPy+lD5m2qojRtXuGw7bzvdu2fx6iEeMt1XogXbHxiNxi1tDg0QJDNaWTojk2 Nh8uk5rUl64eHOU4DH+ztFLl =eTyF -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:26.ktls

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:26.ktls Security Advisory The FreeBSD Project Topic: Arbitrary file overwrite via the KTLS receive path Category: core Module: ktls Announced: 2026-06-09 Credits: Bumsrakete Affects: All supported versions of FreeBSD Corrected: 2026-06-09 19:17:28 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:06 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:43 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-06-09 19:17:46 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:05 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:35 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-45257 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 Kernel TLS (KTLS) moves Transport Layer Security (TLS) record processing into the kernel, allowing applications to encrypt and decrypt socket data without copying it to and from userspace and to serve TLS data with sendfile(2). When a connection uses software KTLS on the receive path, the kernel decrypts each incoming TLS record in place within the socket buffer. II. Problem Description The KTLS receive path decrypted each record in place, assuming that the mbufs holding received data were anonymous and safe to modify. This assumption does not hold for data placed on a socket by sendfile(2), which can reference file-backed memory directly through non-anonymous M_EXTPG pages or EXT_SFBUF mbufs. When the sender transmits such data over a loopback connection without enabling KTLS on the transmit side, the file-backed mbufs reach the receiver's decryption path unchanged. Decrypting a record in place then overwrites the backing file's page cache instead of a private copy of the data. III. Impact An unprivileged local user who can read a file can overwrite its contents with data of their choosing by sending the file over a loopback connection on which they have enabled KTLS receive. The write modifies the page cache directly, so it bypasses file flags such as schg and is written back to disk. By overwriting a setuid binary or other trusted file, a local user can escalate privileges, potentially gaining full control of the affected system. 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 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:26/ktls.patch # fetch https://security.FreeBSD.org/patches/SA-26:26/ktls.patch.asc # gpg --verify ktls.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ a51345704403 stable/15-n283882 releng/15.1/ 48c1c5e3c348 releng/15.1-n283550 releng/15.0/ 540a315cdb46 releng/15.0-n281052 stable/14/ 333bdd7e9427 stable/14-n274311 releng/14.4/ d43259dd66b3 releng/14.4-n273714 releng/14.3/ af3398862ac0 releng/14.3-n271514 - ------------------------------------------------------------------------- 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-45257> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:26.ktls.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmooiUwbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv6hQP/3x8lGHZpLeT8PjB5NMF xCfwzKQlu5vlkOqSv+9uEGsh3FQa9gHE/68SwZYa01waeFbTSKpBvrf1X4kRKGnE r3z8DSAPnVqSRzp4k0PNTxPLtF09FfWiMEBA+PIedL91WkG24gQ63k3fORVjkSvs a/uY1DQnmypV2mdV/S/hWmrtVCmi5itZKsVedZFoZHZ04GKwIObMoqXgtbUxdfhJ XvjSCqGgvpsUPVpE72nKYAbbL81w344tNOGtjoC07utitkLoHtMlYqMTfXCv0dY7 Oo3RZ408afAl1CalUdZ64KXJWqjCZt3FWxtn4ugZkewLc3cDyO5Y2ZUDMAb71P/V Sdq6+GRIC5wMOmd2C2Wb4C72FODhh4o4+n/E7qeIojT5jozWNFAFN0ugzNcqzuM9 b8ekwLWK9MbtjZWF1A0OhsLqQoYuBcwX4RymVJCfpEnlPEDwaf0fv/Sx/OyU9MBx zbT/Thqa9cB++4U6Obodcj55mXM9p23b9OpEnSD5FKlhxXPxCYW5gc2mK4k+yoKd 5ZCzzcdzbMoNgqyHnvrBgFGMsPggXJxaidsRFtVSb9E1GWQUweyN9hR10Gr8wX5j QL18EHe3Lcgg2Z+mi8NQ8lrqPoGpTIjZ8enEYHLrILe/p8JMjNU5fe+YqQTE0tyD pWQqqx8AYbHJsnCDELTeqt96 =lD4w -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:25.thr

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:25.thr Security Advisory The FreeBSD Project Topic: Missing permission check in thr_kill2(2) Category: core Module: thr Announced: 2026-06-09 Credits: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai Credits: Igor Gabriel Sousa e Souza Affects: All supported versions of FreeBSD Corrected: 2026-06-09 19:17:27 UTC (stable/15, 15.1-STABLE) 2026-06-09 19:20:05 UTC (releng/15.1, 15.1-RC3-p1) 2026-06-09 19:19:42 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-06-09 19:17:45 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:19:04 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:34 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-45256 This vulnerability was independently reported by multiple parties prior to publication. 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 The thr_kill2(2) system call delivers a signal to a specific thread of a process identified by its process and thread IDs. As with kill(2), the kernel verifies that the calling process is permitted to signal the target before the signal is delivered. II. Problem Description When used to deliver a signal to a specific thread, thr_kill2(2) called p_cansignal() to determine whether the operation was permitted but did not check the result before delivering the signal. The signal was sent even when the permission check failed. The system call returned the resulting error to the caller, but by then the signal had already been delivered. III. Impact The missing check allows an unprivileged local user who knows or can guess a target's process and thread IDs to send any signal to a process they would not normally be permitted to signal, including processes owned by other users or by root. The same check enforces jail boundaries, so a jailed process can signal processes on the host or in other jails. Thread IDs are allocated globally and sequentially, and so can be discovered by brute force with no visibility into the target. An attacker can stop or terminate arbitrary processes, including critical system daemons, resulting in a Denial of Service (DoS). 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 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:25/thr.patch # fetch https://security.FreeBSD.org/patches/SA-26:25/thr.patch.asc # gpg --verify thr.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ afa0c67a1ba3 stable/15-n283881 releng/15.1/ 068168fefd4b releng/15.1-n283549 releng/15.0/ 6f6c7b996719 releng/15.0-n281051 stable/14/ 72ad7baa99c7 stable/14-n274310 releng/14.4/ 31f6086db8fe releng/14.4-n273713 releng/14.3/ fa5581c379fe releng/14.3-n271513 - ------------------------------------------------------------------------- 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-45256> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:25.thr.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmooiUobFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvHNUQAMEmYLwDsVIj73SAnWE4 PN3KAVFvybeK4R4xYPiwPDtOrdV6HEb4G9O9VgZAomMzE9U7OIZVbXSjKdnEc4Ud /54Kg0VlURUCUxncndeBVnT56IzXf9uuT1HuAcSoyN2dDZedAGFbtIrg2YJvPyWL oOe1TyRrj03sP8VnznCZZsPYIqUb7UopdFHaVv2qONdlC0OSnODWiqeRJ8Z38tCd 918AbxTarEKwv5Qx8kV2mvvXIAaK1f6K7l2KqFGdp8HCf5C/plBd7vv6SEVvQhDj 8D6c1Syc/rUTkn6bmeLFinaPxK7OB1oS/Z+7DwJrjlusAhSKbBFcesE2hHYzxEhP 8rmevDJPMNZbouvuC4aJeDSKvGd5eUL+5Rt/EIijBsrlzZv1g/glllbTc/7+g3um aGP9c4BCDUJVjWxui5ACqR9pe2LWQwDtA7YbukXZqkH0M2OroxLRWWCyOLrAlela Eilf64XI6KliSMR+rAL6dmPLxFXVMpJXRKxJmUK3FXDi+Vm0bGaeRwCz49Ts+6XV oU7MRQG/F1w+lZRkS2XQ6YJTv4DBiDAofl7i0Rcjlq1JbWxBjpF8ArZX5VqSSi1y bOkum8QekuU/sbBIij7JyiEPx2r0ICm/pGXDYnxYuwd0+48orpu9uB6M0gKYEe6D mYgtjqeBtUCJwPKOzr36faXQ =rFeT -----END PGP SIGNATURE-----

FreeBSD Errata Notice FreeBSD-EN-26:15.openssl

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-26:15.openssl Errata Notice The FreeBSD Project Topic: Update OpenSSL to 3.0.20 and 3.5.6 Category: contrib Module: openssl Announced: 2026-06-09 Affects: All supported versions of FreeBSD. Corrected: 2026-04-12 02:15:10 UTC (stable/15, 15.0-STABLE) 2026-06-09 19:19:33 UTC (releng/15.0, 15.0-RELEASE-p10) 2026-04-13 00:12:11 UTC (stable/14, 14.4-STABLE) 2026-06-09 19:18:58 UTC (releng/14.4, 14.4-RELEASE-p6) 2026-06-09 19:18:25 UTC (releng/14.3, 14.3-RELEASE-p15) CVE Name: CVE-2026-2673, CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-31789, CVE-2026-31790 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 FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit for the Transport Layer Security (TLS) protocol. It is also a general-purpose cryptography library. II. Problem Description The OpenSSL releases included with the affected FreeBSD versions predate OpenSSL 3.0.20 (FreeBSD 14) and 3.5.6 (FreeBSD 15). This update imports the current upstream point release on each branch. The import resolves several issues affecting different OpenSSL versions, and therefore different FreeBSD versions. Instead of listing detailed writeups for each issue, please see the referenced advisory from OpenSSL. Issues affecting FreeBSD 15 (OpenSSL 3.5): CVE-2026-2673 - DEFAULT keyword corrupts the key-agreement group list CVE-2026-28387 - Possible use-after-free in DANE client code CVE-2026-28388 - NULL dereference when processing a delta CRL CVE-2026-28389 - NULL dereference processing CMS KeyAgreeRecipientInfo CVE-2026-31789 - Heap buffer overflow in hexadecimal conversion CVE-2026-31790 - NULL dereference processing CMS KeyTransRecipientInfo Issues affecting FreeBSD 14 (OpenSSL 3.0): CVE-2026-28387 - Possible use-after-free in DANE client code CVE-2026-28388 - NULL dereference when processing a delta CRL CVE-2026-28389 - NULL dereference processing CMS KeyAgreeRecipientInfo CVE-2026-31789 - Heap buffer overflow in hexadecimal conversion CVE-2026-31790 - NULL dereference processing CMS KeyTransRecipientInfo III. Impact The issues include missing input validation, NULL pointer dereferences, a use-after-free, and a heap buffer overflow. Impact is generally limited to a crash and a Denial of Service. See the OpenSSL advisory for specific details. IV. Workaround No workaround is available. V. Solution Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. A reboot is required following the upgrade to ensure that all applications and kernel code are rebuilt with the updated OpenSSL-provided code. Perform one of the following: 1) To update your system installed from base system packages: Systems running a 15.0-RELEASE 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. [FreeBSD 15.0] # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-15.0.patch # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-15.0.patch.asc # gpg --verify openssl-15.0.patch.asc [FreeBSD 14.4] # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-14.4.patch # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-14.4.patch.asc # gpg --verify openssl-14.4.patch.asc [FreeBSD 14.3] # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-14.3.patch # fetch https://security.FreeBSD.org/patches/EN-26:15/openssl-14.3.patch.asc # gpg --verify openssl-14.3.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart all daemons that use the library, 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/ 51a80be04fe6 stable/15-n282933 releng/15.0/ 0f6e90c4cc4f releng/15.0-n281050 stable/14/ 27ac9d336f71 stable/14-n273945 releng/14.4/ 1bfe60bae8b8 releng/14.4-n273712 releng/14.3/ d95a8c20f3bc releng/14.3-n271512 - ------------------------------------------------------------------------- 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://openssl-library.org/news/secadv/20260407.txt> <URL:https://www.cve.org/CVERecord?id=CVE-2026-2673> <URL:https://www.cve.org/CVERecord?id=CVE-2026-28387> <URL:https://www.cve.org/CVERecord?id=CVE-2026-28388> <URL:https://www.cve.org/CVERecord?id=CVE-2026-28389> <URL:https://www.cve.org/CVERecord?id=CVE-2026-31789> <URL:https://www.cve.org/CVERecord?id=CVE-2026-31790> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-26:15.openssl.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmoolw4bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrv5ewP/3XwoJ809Y0eVU/MrvNM VujyPzQFeMYHg9Od8AYqCfL9AsJaPPnI9sDLHLTIlwfC34ahC8xksEhfpKAoVn/9 kSgKG8Evmb2xOxxz9mnH3cj/4IuyfvDoA7bWLI1yjdjXdm7rP9dE+nI0xktm1aeX TkMHrpTzeR0F/M1fehjuUuYKdHzINvorKFA49fZm3GvDWogLPWGzU2fLhpHwGa8Z D7Maxi9U+cuv5zlw6GxKHvPTJTwzLy7F9GejFEq+25YFdhvyKe7ZB8J33ttz1nlc Ee8z/QkJM/O8/YrvX2i4ZqFmSjgOPbOrbSOiLo13Yusj1TQn/wmsuymP4Vjxf7xM 7ERML9TW1yti0ZCxriwcWUNSt7agPqP18Gjo2las1v8EVuGZ3PB/EhMmP+s0RPtd ZhVSK7UVJiX0zrIhE5bse+2A67l71rDNLKh7pt7P2FFID2yKLDBgUjMoUbNODsvO rOeZ09ndMQT24yrkjYM7uKHqmicQs/uBJzXItEr8NU5psKe4gIAfzrWDSl6Lg53y yJPtEitkcGPHRwDV4fdCcauri2fiw1S8yWH6DXl/CLviAApE9w7NRpD181g0eo5E QkRHy/rge2A9vK00KGpZsm7HPeIggdob3iK9TkYg3N+tZhBRfh7WtnQR7ZN7iMpv J6mK8Rm9NoDASI4IXgdRR5gs =Ocgt -----END PGP SIGNATURE-----

FreeBSD Errata Notice FreeBSD-EN-26:14.syslogd

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-26:14.syslogd Errata Notice The FreeBSD Project Topic: syslogd(8) memory leak in casper_ttymsg() Category: core Module: syslogd Announced: 2026-06-09 Affects: FreeBSD 15.0 and later Corrected: 2026-05-26 20:41:22 UTC (stable/15, 15.1-STABLE) 2026-05-28 22:16:09 UTC (releng/15.1, 15.1-RC2) 2026-06-09 19:19:32 UTC (releng/15.0, 15.0-RELEASE-p10) 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 syslogd(8) is the system log daemon, responsible for receiving log messages from the kernel and from userland programs and dispatching them according to syslog.conf(5). It can be configured to log messages to a system console or to logged-in users' TTYs. As of FreeBSD 15.0, syslogd runs in a Capsicum sandbox, and delegates the actual writing of console messages to a libcasper(3) service. II. Problem Description When delivering a message to the console or to a terminal, the libcasper service retrieved the message text with nvlist_take_string_array(9), which transfers ownership of the array and its strings to the caller. The casper_ttymsg() and casper_wallmsg() functions never freed them, leaking memory on every message routed to the console or a terminal. III. Impact On long-running systems that emit a steady stream of log messages routed to /dev/console or to user terminals, the resident size of syslogd.casper helper process grows without bound. This may eventually lead to memory pressure, including swap usage, or process termination by the out-of-memory killer. syslogd itself continues to function. IV. Workaround Periodically restarting syslogd will reclaim leaked memory. Systems that do not direct syslog output to /dev/console, terminals, or wall destinations are not affected. V. Solution Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Perform one of the following: 1) To update your system installed from base system packages: Systems running a 15.0-RELEASE 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 # service syslogd restart 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 # service syslogd restart 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:14/syslogd.patch # fetch https://security.FreeBSD.org/patches/EN-26:14/syslogd.patch.asc # gpg --verify syslogd.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart syslogd(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/ be03b0fb2241 stable/15-n283693 releng/15.1/ d51d91b07f5b releng/15.1-n283540 releng/15.0/ 998de2d14e25 releng/15.0-n281049 - ------------------------------------------------------------------------- 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/bugzilla/show_bug.cgi?id=295488> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-26:14.syslogd.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmooiS0bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvi2gQAMf5aER4RND+DWh7qbbQ ZuQwejCwW1MeX/oex0TAD8tvGgaBXOztAMMPQ4KRyrzjIYeo5+NpWAYlhqiAOOKE DCctvWY2hMylj5NNV2etV4QpK0h2R4ZTRj2gnWhYIr/PkzRmaJu9tc3dOH5DQSQZ WZTwo+Wu/vcAnevgIe4cOPI07YdZjl6bGlOo8q0qBaJ1xKk5NbY3Se9IJX3pCf31 KODaPY1Py9EuYyW1HoDfrZV7V0iV3X51lgLNmHa2l8Z2cFD/U7Xsk08wU/vtcY0o la+hvXwMjzHrtie6a2FNV2twyH534B/2ye5Olsf/QnI+g6mEKr3Xif9tt5fYQHXW Lku+Auc3Hy1d1vK5MUOUpf53SEtvLFkISBAAFIT5x/4kC9W+Kjvl7vspSw+2whuM S4iLfBbx3DN9aHCNvL1rnkTvn9H7/nOtiaJ5SHBXmtWyYDS/ZptBuzq8L0NaLRfp lHoSCwND6HXQNZZi3QGVctthFg24ZJoxZOZrx7cDHIphtf/AHMlYkpIPZMaCuiBa Pw0B/m03VBFYgHCyXlKjQ1EKbAHpS3/pNv5EtCnAAWPNGNoiAjQDa5CnUg0nlz3d wI+qXBAAM7dUndhvs10/ta/n15Dn6hf89Eojx4SDvPWWAmvtmhd0dDn7kIRDVzVf 2nqvCHY/6icyLLm3vbwjwgv5 =nmHp -----END PGP SIGNATURE-----

confirm e1c12e0117b07c525dc66e657e95fa71f25fd69f

Your membership in the mailing list ubuntu-security-announce has been disabled due to excessive bounces The last bounce received from you was dated 25-May-2026. You will not get any more messages from this list until you re-enable your membership. You will receive 1 more reminders like this before your membership in the list is deleted. To re-enable your membership, you can simply respond to this message (leaving the Subject: line intact), or visit the confirmation page at https://lists.ubuntu.com/mailman/confirm/ubuntu-security-announce/e1c12e0117b07c525dc66e657e95fa71f25fd69f You can also visit your membership page at https://lists.ubuntu.com/mailman/options/ubuntu-security-announce/reallost1.fbsd2233449%40blogger.com On your membership page, you can change various delivery options such as your email address and whether you get digests or not. As a reminder, your membership password is quicker If you have any questions or problems, you can contact the list owner at ubuntu-security-announce-owner@lists.ubuntu.com