NetBSD's hdaudio(4) driver in sys/dev/hdaudio/hdaudio.c contains a missing access control vulnerability that allows unprivileged local attackers to invoke the HDAUDIOFGRPSETCONFIG ioctl without elevated permissions by exploiting the absence of an access check on /dev/hdaudioN device nodes. Attackers can repeatedly issue HDAUDIOFGRPSETCONFIG from one thread while keeping DMA and IRQs live from a second thread to trigger a use-after-free race condition in hdafgdetach() between streamstop() and streamdisestablish(), where a latched DMA interrupt dereferences a freed callback pointer, resulting in outcomes ranging from audio-subsystem denial of service and kernel panic to potential local kernel privilege escalation.

Latest version: 11.0

https://bugzilla.redhat.com/showbug.cgi?id=2462085 [CVE-2026-16277] & https://bugzilla.redhat.com/showbug.cgi?id=2502719 [CVE-2026-16461] disclose a pair of related buffer overflows in the rpcinfo command from ONC RPC (aka Sun NFS) when parsing & printing the information returned from a remote rpcbind server.

CVE-2026-16277 covers an overflow when using the -l option: c char buf[128]; sprintf (buf, "%s/%s/%s ", re->rncprotofmly, re->rncproto, re->rncsemantics == NCTPICLTS ? "clts" : re->rncsemantics == NCTPICOTS ? "cots" : "cotsord"); CVE-2026-16461 covers another overflow when using the -s option: c char buf[256]; char p = buf; for (vl = rs->vlist; vl; vl = vl->next) { sprintf (p, "%d", vl->vers); p = p + strlen (p); if (vl->next) sprintf (p++, ","); } The bug reports note they were generated with AI analysis. Red Hat credits Aisle Research for reporting both issues, and Michalis Vasileiadis (GitHub: vmihalis) for reporting CVE-2026-16277 in their advisories at: https://access.redhat.com/security/cve/cve-2026-16277 https://access.redhat.com/security/cve/cve-2026-16461

A fix for CVE-2026-16277 for Linux NFS is published at: https://git.linux-nfs.org/?p=steved/rpcbind.git;a=commitdiff;h=bb9bb7286a4c345442946dc2ce3c9e7f67e96d4d Unfortunately, that server seems overloaded and I haven't found if it has a fix for CVE-2026-16461 or not yet.

NetBSD appears to have fixed both in 2011: https://github.com/NetBSD/src/commit/e95e36baeccc24159378f422fd3dffb97979b415

OpenBSD's rpcinfo does not support the affected options (it uses -s for a different function, and has no -l option).

Fixes for both for OpenSolaris-based distros were integrated in 2010: https://github.com/illumos/illumos-gate/commit/791dfaa708ef5838f55bf4e97e7c960beb186419

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

NetBSD prior to commit ec8451e contains a race condition vulnerability in cryptodevop() within the opencrypto subsystem that allows local attackers to trigger a double-free condition by concurrently issuing CIOCCRYPT operations on the same session identifier on SMP systems. Attackers can exploit mutable per-operation state embedded in the csession struct to corrupt kernel heap memory.

NetBSD prior to commit ec8451e contains a signed integer overflow vulnerability in the cryptodevop() function in sys/opencrypto/cryptodev.c where the local variable iovlen is declared as a signed int but assigned from an unsigned cop->dstlen value, causing undefined behavior when cop->dstlen exceeds INTMAX. A local attacker with access to /dev/crypto and a compression session type can exploit this vulnerability by providing a dstlen value exceeding INTMAX to trigger a kernel panic through NULL pointer dereference when CONFIGSVS is disabled and corrupted UIO pointer arithmetic.

On Sat, Mar 07, 2026 at 02:20:11AM +0200, Justin Swartz wrote: WHITELISTING

The obsolete blacklist, implemented by scrubenv(), has been removed. The daemon now clears the inherited environment and enforces a default whitelist (USER, LOGNAME, TERM, LANG, and LC) for all NEWENVIRON values. Makes sense to me.

Note that this list is different from Linux NetKit's, which is:

/ Allow only these variables. / if (!strcmp(varp, "TERM")) return 1; if (!strcmp(varp, "DISPLAY")) return 1; if (!strcmp(varp, "USER")) return 1; if (!strcmp(varp, "LOGNAME")) return 1; if (!strcmp(varp, "POSIXLYCORRECT")) return 1;

I also checked the major BSDs. telnetd was removed from OpenBSD in 2005, so I didn't look further. It was removed from FreeBSD in 2022:

https://cgit.freebsd.org/src/commit/?id=d701f45aba19f232ce7817085935f33dd609ed8b

where it used this at time of removal:

static const char acc[] = { "XAUTH=", "XAUTHORITY=", "DISPLAY=", "TERM=", "EDITOR=", "PAGER=", "LOGNAME=", "POSIXLYCORRECT=", "PRINTER=", NULL };

Curiously, there was CVE-2009-0641 where FreeBSD 7.x would accept even LDPRELOAD, but I couldn't quickly find where the bug was exactly:

https://lists.openwall.net/full-disclosure/2009/02/14/1

Message-ID: <72f8221d0902131846h6c77a8d1t90c3352f978b8732 () mail gmail com> Date: Sat, 14 Feb 2009 03:46:07 +0100 From: Kingcope Kingcope <kcope2 () glemail com> To: full-disclosure () ts grok org uk Subject: FreeBSD zeroday

https://www.freebsd.org/security/advisories/FreeBSD-SA-09:05.telnetd.asc

"recent changes in FreeBSD's environment-handling code rendered telnetd's scrubbing inoperative"

We could want to find the detail in order to avoid the same pitfall.

NetBSD still has telnetd:

https://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/telnetd/

and in systerm.c it has:

/ scrubenv() We only accept the environment variables listed below. /

void scrubenv(void) { static const char reject[] = { "TERMCAP=/", NULL };

static const char acceptstr[] = { "XAUTH=", "XAUTHORITY=", "DISPLAY=", "TERM=", "EDITOR=", "PAGER=", "LOGNAME=", "POSIXLYCORRECT=", "TERMCAP=", "PRINTER=", NULL };

char cpp, cpp2; const char p;

for (cpp2 = cpp = environ; cpp; cpp++) { int rejectit = 0;

for(p = reject; p; p++) if(strncmp(cpp, p, strlen(p)) == 0) { rejectit = 1; break; } if (rejectit) continue;

for(p = acceptstr; p; p++) if(strncmp(cpp, p, strlen(p)) == 0) break; if(p != NULL) cpp2++ = cpp; } cpp2 = NULL; }

I'm not saying you should revise the list in any way - just sharing what others have. It may well be that allowing those other env vars by default is obsolete since use cases for telnet are now more specialized, and maybe allowing LANG and LC is desirable for current use cases.

Separately note that I didn't check the BSDs telnet client (which I think is still present in all BSDs) for being (hopefully not) willing to export arbitrary env vars. The maintainers could want to check this. And you could want to check the telnet client in InetUtils, now that we know this package missed telnet[d] security fixes in general. This was CVE-2005-0488 (and CVE-2005-1205 on Windows).

"Certain BSD-based Telnet clients, including those used on Solaris and SuSE Linux, allow remote malicious Telnet servers to read sensitive environment variables via the NEW-ENVIRON option with a SEND ENVUSERVAR command." TELOPTTTYPE INTERCEPTION

The whitelist validation has been extended, in the second version of the patch set, to intercept raw terminal type negotiations (aka TELOPTTTYPE), to prevent questionable TERM payloads from bypassing the NEWENVIRON filter. Good idea. The daemon now clears the inherited environment (preserving PATH and TERM, respectively, if present) before calling telnetdsetup(). Inherited from inetd or the like? It's supposed to be trusted input and env vars in there may be set on purpose, so dropping them is unexpected. I think e.g. sshd doesn't do that, why would telnetd? Think things like LDPRELOAD=/lib64/libhardenedmalloc.so (although /etc/ld.so.preload is a more reliable way to do this when practical to do it globally). +++ b/telnetd/state.c @@ -1495,10 +1495,18 @@ suboption (void) case NEWENVVAR: case ENVUSERVAR: cp = '\0'; - if (valp) - setenv (varp, valp, 1); - else - unsetenv (varp); + if (isenvvarallowed (varp, valp)) + { + if (valp) + { + if (valp && valp != 0) + setenv (varp, valp, 1); + } + else + { + unsetenv (varp); + } + } cp = varp = (char ) subpointer; valp = 0; break; @@ -1514,10 +1522,18 @@ suboption (void) } } cp = '\0'; - if (valp) - setenv (varp, valp, 1); - else - unsetenv (varp); + if (isenvvarallowed (varp, valp)) + { + if (valp) + { + if (valp && valp != 0) + setenv (varp, valp, 1); + } + else + { + unsetenv (varp); + } + } break; } / end of case TELOPTNEWENVIRON / Some code duplication here. Not new with these changes, but could be worth moving to a new function e.g. setenvvarifallowed(). +/ A default whitelist for environment variables. / +static const char allowedenvvars[] = { + "USER", + "LOGNAME", + "TERM", + "LANG", + "LC", + NULL +}; Can make not only the strings but also the pointers const:

static const char const allowedenvvars[] = {

so that both may end up in a read-only section. +int +isenvvarallowed (const char var, const char val) +{ + const char p; + int allowed = 0; + + for (p = allowedenvvars; p; p++) + { + if (fnmatch (p, var, FNMNOESCAPE) == 0) + { + allowed = 1; + break; + } + } + + if (!allowed) + return 0; You didn't strictly need the "allowed" variable, you could check p after the loop. But maybe it's more readable the way you wrote it.

My review above isn't in full context - I only looked at the patches.

Alexander

Date: Fri, 16 May 2025 21:52:14 -0500 From: Jacob Bachmeyer <jcb62281 () gmail com>

On 5/16/25 13:07, Eli Schwartz wrote: On 5/16/25 12:31 PM, Taylor R Campbell wrote: [...] (a) the same pkgsrc packages are available on, e.g., NetBSD 9.x (which is not EOL); and

(b) pkgsrc is used on platforms other than NetBSD, including macOS, SmartOS, and various Linux distributions (e.g., for unprivileged use on HPC clusters where it is more flexible and up-to-date than the Linux distribution's package manager).

That is why it would be more accurate for the report to say pkgsrc-2025Q1', not NetBSD 10.1'. I strongly dispute this. It should instead list both, as both are affected. Would "systems using pkgsrc-2025Q1, notably including NetBSD 9.x and NetBSD 10.1" have been a fair way of describing that set? Sure, that's fine, or just ...notably including NetBSD' instead of specifying versions since NetBSD and pkgsrc versions advance independently.

If I gave anyone the impression that I'm trying to conceal its impact on NetBSD users, as Eli has insinuated with fabricated quotes, I apologize (for that and for all the off-topic noise this minor point has generated) -- we did not escape this, and we are working to address it for all pkgsrc users on NetBSD or otherwise.

This will be my last message on the subject in this thread; I'm sure everyone is tired of hearing about it now.

Jacob Bachmeyer <jcb62281 () gmail com> wrote: Would "systems using pkgsrc-2025Q1, notably including NetBSD 9.x and NetBSD 10.1" have been a fair way of describing that set? I think that's a lot better, although I would probably have phrased it as:

Systems using screen(1) built from pkgsrc, including binary packages installed on NetBSD using e.g., pkgadd(1) or pkgin(1) before screen-5.0.0nb3 are affected.

The details can get confusing, because you can use pkgsrc from sources from -current or a quarterly tagged branch across a range of operating systems, but can also install binary packages using at least two different tools, so ultimately neither the date nor the OS themselves matter as much as the package version number. (The "nb3" here signals that this is the 3rd pkgsrc specific version bump of the 5.0.0 upstream version.)

But no need to further argue over the precise language. :-)

-Jan

On 5/16/25 13:07, Eli Schwartz wrote: On 5/16/25 12:31 PM, Taylor R Campbell wrote: [...] (a) the same pkgsrc packages are available on, e.g., NetBSD 9.x (which is not EOL); and

(b) pkgsrc is used on platforms other than NetBSD, including macOS, SmartOS, and various Linux distributions (e.g., for unprivileged use on HPC clusters where it is more flexible and up-to-date than the Linux distribution's package manager).

That is why it would be more accurate for the report to say pkgsrc-2025Q1', not NetBSD 10.1'. I strongly dispute this. It should instead list both, as both are affected.

(Again, b is the same distinction as "Gentoo, but also portage-20250508, are both affected".)

-- Jacob

On 5/16/25 12:31 PM, Taylor R Campbell wrote: It is not nonsensical, and it is not the inconsequential pedantry you are suggesting. Please consider avoiding sarcastic disparagement when publicly discussing the factual matters of security reports.

The report says that NetBSD 10.1' is affected. This is not quite right, and it matters even if you set aside the fact that NetBSD 10.1 itself (which does ship tmux!) does not ship screen, because: NetBSD 10.1 (and earlier) is affected (if you use its package manager to install screen).

Arch Linux is affected (if you use its package manager to install screen).

Debian 12.10 (but this is not quite right!!!1!11!!!oneoneeleven. The same packages are available on e.g. Debian 13, 11, etc) is affected (if you use its package manager to install screen).

Ubuntu 24.04.10 (but this is not quite right!!!1!11!!!oneoneeleven. The same packages are available on e.g. Ubuntu 22.04, 24.10, 25.04, 25.10) is affected (if you use its package manager to install screen).

Gentoo (but this is not quite right!!!1!11!!!oneoneeleven. The same packages are available on e.g. macOS Prefix) is affected (if you use its package manager to install screen). (a) the same pkgsrc packages are available on, e.g., NetBSD 9.x (which is not EOL); and

(b) pkgsrc is used on platforms other than NetBSD, including macOS, SmartOS, and various Linux distributions (e.g., for unprivileged use on HPC clusters where it is more flexible and up-to-date than the Linux distribution's package manager).

That is why it would be more accurate for the report to say pkgsrc-2025Q1', not NetBSD 10.1'. I strongly dispute this. It should instead list both, as both are affected. (Again, b is the same distinction as "Gentoo, but also portage-20250508, are both affected".)

But the list of affected distributions wasn't complete, and likely wasn't intended to be. Nor was its list of distribution versions. It didn't list affected versions for Adelie, Alpine, CRUX, Exherbo, Guix, Homebrew, Mageia, Mandriva, Solus, Void Linux...

I'll reiterate that claiming NetBSD is "not affected" because "the base installation doesn't preinstall it" is nonsensical, and highly reminiscent of, erm, a different BSD that uses similar logic to conclude that "the base installation" does not need useless bloat such as TrustedBSD.

I encourage you to relax and stop feeling like the honor of NetBSD is at stake if you fail to prove that "NetBSD 10.1" was exempt from the same issue all other distributors had.

It's no embarrassment for an operating system to have the builtin capability to install software, you can just not treat it like an unwanted and uninvited guest tracking mud all over the kitchen that needs to be disavowed.

-- Eli Schwartz

Date: Fri, 16 May 2025 11:34:29 -0400 From: Eli Schwartz <eschwartz () gentoo org>

On 5/16/25 11:01 AM, Jan Schaumann wrote: I think it's useful to clarify here that NetBSD does not ship with GNU screen(1) at all. NetBSD's third-party package manager pkgsrc[1] includes screen(1), allowing users to install additional software on top of the base OS.

That package as included in pkgsrc was installed setuid[2], but a NetBSD base installation does not include that package. (NetBSD happens to include tmux(1) in the base OS, but not screen(1).)

This distinction between a base OS and add-on software that is optionally available for users to choose tends to cause confusion for some people, so I figured it's worth noting. This is a nonsensical claim, but if I accept it as stated then I will counter-assert that zero (0) Linux distros are vulnerable as they don't preinstall screen in the base OS.

The definition of "the NetBSD base installation" is "nobody uses it". People use computing devices in order to run software on it. You cannot consider your OS in a bubble and go "well ackshually it's perfectly secure unless you use the builtin software to install official software, but we don't support that as a secure option". It is not nonsensical, and it is not the inconsequential pedantry you are suggesting. Please consider avoiding sarcastic disparagement when publicly discussing the factual matters of security reports.

The report says that NetBSD 10.1' is affected. This is not quite right, and it matters even if you set aside the fact that NetBSD 10.1 itself (which does ship tmux!) does not ship screen, because:

(a) the same pkgsrc packages are available on, e.g., NetBSD 9.x (which is not EOL); and

(b) pkgsrc is used on platforms other than NetBSD, including macOS, SmartOS, and various Linux distributions (e.g., for unprivileged use on HPC clusters where it is more flexible and up-to-date than the Linux distribution's package manager).

That is why it would be more accurate for the report to say pkgsrc-2025Q1', not NetBSD 10.1'.

All that said, I think any further discussion of this point -- and any other distributor-specific matters -- can reasonably be taken off-list to keep the thread focussed on the details of the screen vulnerabilities themselves.

Matthias Gerstner <mgerstner () suse de> wrote: we were surprised to find a local root exploit in the Screen 5.0.0 major version update affecting distributions that ship it as setuid-root (Arch Linux and NetBSD). I think it's useful to clarify here that NetBSD does not ship with GNU screen(1) at all. NetBSD's third-party package manager pkgsrc[1] includes screen(1), allowing users to install additional software on top of the base OS.

That package as included in pkgsrc was installed setuid[2], but a NetBSD base installation does not include that package. (NetBSD happens to include tmux(1) in the base OS, but not screen(1).)

This distinction between a base OS and add-on software that is optionally available for users to choose tends to cause confusion for some people, so I figured it's worth noting.

-Jan

[1] https://www.pkgsrc.org/ [2] now no more since https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59417

End of support: 7/30/2026, Latest version: 10.1

End of support: 7/30/2026, Latest version: 10.1

A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

ftpd before "NetBSD-ftpd 20230930" can leak information about the host filesystem before authentication via an MLSD or MLST command. tnftpd (the portable version of NetBSD ftpd) before 20231001 is also vulnerable.

In NetBSD through 9.2, the IPv6 fragment ID generation algorithm employs a weak cryptographic PRNG.

In NetBSD through 9.2, the IPv4 ID generation algorithm does not use appropriate cryptographic measures.

In NetBSD through 9.2, there is an information leak in the TCP ISN (ISS) generation algorithm.

In NetBSD through 9.2, the IPv6 Flow Label generation algorithm employs a weak cryptographic PRNG.

A flaw was found in the Linux kernels wifi implementation. An attacker connected to the wireless network can send 'authentication and key management' frames to any participant on the network. These frames are only intended to be sent from the controlling access point however the kernel did not prevent retransmission of these packets from non-controlling nodes.

Upstream fix: https://lore.kernel.org/linux-wireless/20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid/

The IPv6 implementation in FreeBSD and NetBSD (unknown versions, year 2012 and earlier) allows remote attackers to cause a denial of service via a flood of ICMPv6 Neighbor Solicitation messages, a different vulnerability than CVE-2011-2393.

The IPv6 implementation in FreeBSD and NetBSD (unknown versions, year 2012 and earlier) allows remote attackers to cause a denial of service via a flood of ICMPv6 Router Advertisement packets containing multiple Routing entries.

End of life: 8/30/2026, End of support: 3/28/2024, Latest version: 9.4

End of life: 8/30/2026, End of support: 3/28/2024, Latest version: 9.4

End of life: 5/4/2024, End of support: 2/14/2022, Latest version: 8.3

End of life: 5/4/2024, End of support: 2/14/2022, Latest version: 8.3

NetBSD maps the run-time link-editor ld.so directly below the stack region, even if ASLR is enabled, this allows attackers to more easily manipulate memory leading to arbitrary code execution. This affects NetBSD 7.1 and possibly earlier versions.

A flaw exists in NetBSD's implementation of the stack guard page that allows attackers to bypass it resulting in arbitrary code execution using certain setuid binaries. This affects NetBSD 7.1 and possibly earlier versions.

The NetBSD qsort() function is recursive, and not randomized, an attacker can construct a pathological input array of N elements that causes qsort() to deterministically recurse N/4 times. This allows attackers to consume arbitrary amounts of stack memory and manipulate stack memory to assist in arbitrary code execution attacks. This affects NetBSD 7.1 and possibly earlier versions.