A remote attacker can crash NetBSD systems using ipfilter by triggering a null pointer dereference in kernel code, affecting edge network devices. A 4-byte TCP timestamp leak exposes kernel stack memory including addresses needed to bypass memory randomization protections in exploit chains.
NetBSD 10.2 patches critical remote kernel bug in ipfilter
A leaked address is a foothold for exploits past memory randomization
Mark
Why does a null pointer dereference in ipfilter matter more than the other fixes in this release?
Mimi
Because ipfilter runs in kernel space on machines at the network edge, and a remote attacker can trigger it without authentication. A crash takes down your filtering layer.
Luke
Can we confirm it's been exploited in the wild, or is this a theoretical risk?
Mimi
The source doesn't say. We know it's remotely triggerable and that NetBSD patched it, but there's no disclosure of active exploitation.
Mark
And the TCP timestamp leak—how does that actually get used in an attack?
Mimi
An attacker leaks four bytes of kernel memory through normal TCP traffic, gets an address, then uses that address to aim a more complex exploit past the randomization defenses.
Luke
Four bytes is a small leak. How reliable is that information for bypassing ASLR?
Mimi
Depends on the architecture and what those four bytes contain. The source doesn't detail the reliability, just that it's a leak of kernel addresses.
Mark
What about the NFS and telnet fixes with no CVE numbers?
Mimi
That's the real gap. We know they're patched, but the changelog tells us nothing about severity or what was actually broken.
Luke
So an admin reading this has to choose between patching everything immediately or waiting for more information that may never come?
Mimi
Essentially, yes. The safe choice is to patch, but the lack of detail makes risk assessment impossible.
The Pulse
- NetBSD 10.2 released September 15, 2026
- Remote null pointer dereference in ipfilter kernel code can crash systems
- 4-byte TCP timestamp leak exposes kernel stack addresses
- NFS and telnet fixes lack CVE identifiers and detailed descriptions
- OpenSSL updated to 3.0.21, Xorg to 21.1.24
A remote attacker can crash NetBSD systems using ipfilter by triggering a null pointer dereference in kernel code, affecting edge network devices. A 4-byte TCP timestamp leak exposes kernel stack memory including addresses needed to bypass memory randomization protections in exploit chains.
NetBSD 10.2 released September 15 fixes a remotely triggerable kernel null pointer dereference in ipfilter, a kernel stack data leak, and vulnerabilities in NFS, telnet, OpenSSL and Xorg.
NetBSD 10.2 arrived on September 15 carrying fixes for a kernel flaw that could let someone outside your network crash a machine running ipfilter at the edge. The vulnerability is a null pointer dereference in ipfilter's kernel code—the kind of bug that sends a system down when triggered remotely. For organizations running NetBSD boxes as network filters, this was the sort of patch that demanded immediate attention.
The second point release of the NetBSD 10 stable branch also closed a quieter but equally useful vulnerability: a 4-byte leak of kernel stack memory through TCP timestamps. Timestamps are the counters hosts attach to packets to measure round-trip time, ordinary network traffic. Four bytes is small, but kernel stack memory holds addresses—the kind of information an attacker needs to navigate past address space layout randomization, the defense that makes exploits harder to aim. A leaked address is a foothold.
Beyond the kernel, the release bundled security updates to third-party software bundled with NetBSD. OpenSSL moved to version 3.0.21, Xorg to 21.1.24, and xkbcomp to 1.5.0, all for security reasons. The graphics library libXpm picked up upstream fixes for CVE-2026-4367. The unbound DNS resolver received a patch for CVE-2025-11411. The kernel also began enforcing access checks on the /dev/hdaudio device, closing a permissions gap.
What stands out in the changelog is what is missing. Both NFS, the network file-sharing service, and telnet received fixes described only as addressing "various security issues." Neither entry lists a CVE identifier. For admins trying to decide how urgently to patch, that absence of detail is frustrating. If you run NFS on NetBSD 10, the vagueness is reason enough to move the update up the priority list.
The upgrade path requires care. Using the installation image and selecting Upgrade handles most of the work automatically. Admins using other methods face a specific sequence: update the kernel and modules first, reboot the machine, then update userspace. Package repository URLs need reconfiguration. All third-party packages require updating. A new gpufw set may need a separate installation through sysinst. The distribution files come with hashes signed by the NetBSD Security Officer's PGP key—verification before deploying to production is not optional. The steps are straightforward but demand attention; skipping the order or skipping verification creates its own risks.
Notable Quotes
Neither NFS nor telnet fix lists a CVE, leaving admins unable to judge severity— NetBSD 10.2 changelog
Want the full story?
Read the original at helpnetsecurity.com ↗
General News