Date: Thu, 26 Mar 2026 05:22:25 +0000 From: Philip Paeps <philip@FreeBSD.org> To: ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org Subject: git: 1546840cdddf - main - security/vuxml: add FreeBSD SAs issued on 2026-03-25 Message-ID: <69c4c291.3a77f.792fa3f5@gitrepo.freebsd.org>
index | next in thread | raw e-mail
The branch main has been updated by philip: URL: https://cgit.FreeBSD.org/ports/commit/?id=1546840cdddfce0b88a4abc0c9949f5b9700c2eb commit 1546840cdddfce0b88a4abc0c9949f5b9700c2eb Author: Philip Paeps <philip@FreeBSD.org> AuthorDate: 2026-03-26 05:20:08 +0000 Commit: Philip Paeps <philip@FreeBSD.org> CommitDate: 2026-03-26 05:20:08 +0000 security/vuxml: add FreeBSD SAs issued on 2026-03-25 FreeBSD-SA-26:06.tcp affects FreeBSD 14.3R, 14.4R and 15.0R FreeBSD-SA-26:07.nvmf affects FreeBSD 15.0R FreeBSD-SA-26:08.rpcsec_gss affects all supported releases FreeBSD-SA-26:09.pf affects FreeBSD 14.3R, 14.4R and 15.0R --- security/vuxml/vuln/2026.xml | 151 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) diff --git a/security/vuxml/vuln/2026.xml b/security/vuxml/vuln/2026.xml index 387e87110fe1..89d4594f362f 100644 --- a/security/vuxml/vuln/2026.xml +++ b/security/vuxml/vuln/2026.xml @@ -1,3 +1,154 @@ + <vuln vid="c6d41ac8-28d2-11f1-b35e-bc241121aa0a"> + <topic>FreeBSD -- pf silently ignores certain rules</topic> + <affects> + <package> + <name>FreeBSD-kernel</name> + <range><ge>15.0</ge><lt>15.0_5</lt></range> + <range><ge>14.4</ge><lt>14.4_1</lt></range> + <range><ge>14.3</ge><lt>14.3_10</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <h1>Problem Description:</h1> + <p>A regression in the way hashes were calculated caused rules + containing the address range syntax (x.x.x.x - y.y.y.y) that only + differ in the address range(s) involved to be silently dropped as + duplicates. Only the first of such rules is actually loaded into + pf. Ranges expressed using the address[/mask-bits] syntax were not + affected.</p> + <p>Some keywords representing actions taken on a packet-matching rule, + such as 'log', 'return tll', or 'dnpipe', may suffer from the same + issue. It is unlikely that users have such configurations, as these + rules would always be redundant. The verification described in + "IV. Workaround" below will find these as well.</p> + <h1>Impact:</h1> + <p>Affected rules are silently ignored, which can lead to unexpected + behaviour including over- and underblocking.</p> + </body> + </description> + <references> + <cvename>CVE-2026-4748</cvename> + <freebsdsa>SA-26:09.pf</freebsdsa> + </references> + <dates> + <discovery>2026-03-25</discovery> + <entry>2026-03-26</entry> + </dates> + </vuln> + + <vuln vid="733febba-28d2-11f1-b35e-bc241121aa0a"> + <topic>FreeBSD -- Remote code execution via RPCSEC_GSS packet validation</topic> + <affects> + <package> + <name>FreeBSD-kernel</name> + <range><ge>15.0</ge><lt>15.0_5</lt></range> + <range><ge>14.4</ge><lt>14.4_1</lt></range> + <range><ge>14.3</ge><lt>14.3_10</lt></range> + <range><ge>13.5</ge><lt>13.5_11</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <h1>Problem Description:</h1> + <p>Each RPCSEC_GSS data packet is validated by a routine which + checks a signature in the packet. This routine copies a portion + of the packet into a stack buffer, but fails to ensure that the + buffer is sufficiently large, and a malicious client can trigger a + stack overflow. Notably, this does not require the client to + authenticate itself first.</p> + <h1>Impact:</h1> + <p>As kgssapi.ko's RPCSEC_GSS implementation is vulnerable, remote + code execution in the kernel is possible by an authenticated user + that is able to send packets to the kernel's NFS server while + kgssapi.ko is loaded into the kernel.</p> + <p>In userspace, applications which have librpcgss_sec loaded and run + an RPC server are vulnerable to remote code execution from any + client able to send it packets. We are not aware of any such + applications in the FreeBSD base system.</p> + </body> + </description> + <references> + <cvename>CVE-2026-4747</cvename> + <freebsdsa>SA-26:08.rpcsec_gss</freebsdsa> + </references> + <dates> + <discovery>2026-03-25</discovery> + <entry>2026-03-26</entry> + </dates> + </vuln> + + <vuln vid="11bf64f0-28d2-11f1-b35e-bc241121aa0a"> + <topic>FreeBSD -- Remote denial of service via null pointer dereference</topic> + <affects> + <package> + <name>FreeBSD-kernel</name> + <range><ge>15.0</ge><lt>15.0_5</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <h1>Problem Description:</h1> + <p>On a system exposing an NVMe/TCP target, a remote client can + trigger a kernel panic by sending a CONNECT command for an I/O queue + with a bogus or stale CNTLID.</p> + <h1>Impact:</h1> + <p>An attacker with network access to the NVMe/TCP target can + trigger an unauthenticated Denial of Service condition on the + affected machine.</p> + </body> + </description> + <references> + <cvename>CVE-2026-4652</cvename> + <freebsdsa>SA-26:07.nvmf</freebsdsa> + </references> + <dates> + <discovery>2026-03-25</discovery> + <entry>2026-03-26</entry> + </dates> + </vuln> + + <vuln vid="7aa913e9-28d1-11f1-b35e-bc241121aa0a"> + <topic>FreeBSD -- TCP: remotely exploitable DoS vector (mbuf leak)</topic> + <affects> + <package> + <name>FreeBSD-kernel</name> + <range><ge>15.0</ge><lt>15.0_5</lt></range> + <range><ge>14.4</ge><lt>14.4_1</lt></range> + <range><ge>14.3</ge><lt>14.3_10</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <h1>Problem Description:</h1> + <p>When a challenge ACK is to be sent tcp_respond() constructs and + sends the challenge ACK and consumes the mbuf that is passed in. + When no challenge ACK should be sent the function returns and leaks + the mbuf.</p> + <h1>Impact:</h1> + <p>If an attacker is either on path with an established TCP + connection, or can themselves establish a TCP connection, to an + affected FreeBSD machine, they can easily craft and send packets + which meet the challenge ACK criteria and cause the FreeBSD host + to leak an mbuf for each crafted packet in excess of the configured + rate limit settings i.e. with default settings, crafted packets + in excess of the first 5 sent within a 1s period will leak an mbuf.</p> + <p>Technically, off-path attackers can also exploit this problem by + guessing the IP addresses, TCP port numbers and in some cases the + sequence numbers of established connections and spoofing packets + towards a FreeBSD machine, but this is harder to do effectively.</p> + </body> + </description> + <references> + <cvename>CVE-2026-4247</cvename> + <freebsdsa>SA-26:06.tcp</freebsdsa> + </references> + <dates> + <discovery>2026-03-25</discovery> + <entry>2026-03-26</entry> + </dates> + </vuln> + <vuln vid="07d6b170-fed8-4ee2-ba96-b6d61b6d6a26"> <topic>chromium -- security fixes</topic> <affects>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69c4c291.3a77f.792fa3f5>