CVE-2025-11964: Windows libpcap UTF-16 to UTF-8 bug fixed

A small but concrete libpcap memory-safety bug—assigned CVE‑2025‑11964—was disclosed at the end of December 2025: on Windows systems, the library’s UTF-16LE → UTF-8 conversion helper can undercount the space consumed by four‑byte UTF‑8 sequences and write past the end of a provided buffer. The upstream project accepted a one‑line fix that corrects the bookkeeping (decrementing the remaining buffer length by 4 instead of 3), and multiple vulnerability trackers and distribution security pages have cataloged the issue and its low-severity rating.

---

Background​

libpcap is the canonical packet capture library used by tcpdump, Wireshark, and countless network monitoring and security tools. It also exposes system-specific helpers—on Windows, for example—that translate system messages and error strings between platform encodings (UTF‑16LE) and UTF‑8 for logging and API consumers.
CVE‑2025‑11964 is not a remote network‑facing parser bug in packet decoding; it sits in a utility function that converts Windows error-message text to UTF‑8 and truncates output to the caller’s buffer size. Because UTF‑8 encodes some Unicode code points in four bytes, the converter must both emit the correct octets and track how many bytes remain in the destination buffer. A copy‑and‑paste bookkeeping mistake caused the function to subtract 3 instead of 4 when emitting four‑octet sequences, allowing a single 4‑byte sequence to advance the pointer but leave the remaining-length counter overstated—permitting a final write beyond the buffer end. The maintainers committed a corrective change to decrement by 4. This vulnerability is platform‑scoped to Windows builds of libpcap and was recorded publicly on December 30–31, 2025 by the tcpdump/libpcap maintainers and cataloged in public CVE trackers and national databases. The NVD entry and distributor advisories reflect the short, focused nature of the defect.

---

Technical analysis​

What the code did wrong​

The vulnerable routine, utf_16le_to_utf_8_truncated, walks a UTF‑16LE input (wchar_t sequence) and writes a truncated UTF‑8 representation into a caller‑supplied buffer while maintaining a remaining-length counter (utf_8_len). For code points that encode to four UTF‑8 bytes (supplementary characters outside the Basic Multilingual Plane), the function emitted four octets into the buffer but mistakenly reduced the remaining-length counter by only three. That off‑by‑one in the bookkeeping leaves the counter artificially high and lets subsequent logic believe there’s still room to write, causing a final store to target memory past the buffer end. The commit message on the libpcap repository is explicit: “For the four octets of UTF‑8 case, it was decrementing the remaining buffer length by 3, not 4.” The upstream fix changes utf_8_len -= 3 to utf_8_len -= 4.

Why this is an out‑of‑bounds write (OOBW)​

Unlike over‑reads or sign‑extension errors, this defect is a classic write‑past‑end bug (CWE‑787). The allocation and pointer arithmetic are correct in the normal case; a specific encoded input pattern (presence of a four‑byte UTF‑8 character at a truncation boundary) is required to reach the failing path. When that combination occurs, the function may perform a write one (or potentially more) byte(s) past the intended end of the buffer. That produces memory corruption that, in general, can cause application crashes or data corruption and—in worst cases when combined with particular allocator behavior—could be leveraged for more powerful primitives; however, simple write‑past‑end bugs are most commonly a local integrity risk or DoS vector rather than reliable RCE by themselves.

The fix and its simplicity​

Upstream applied a minimal, surgical change: correct the decrement to account for four bytes consumed when emitting a 4‑octet UTF‑8 sequence. The commit author also acknowledges the issue was reported by a University of Waterloo team and that the change was cherry‑picked into the project’s maintenance line. Because the fix is constrained to a single bookkeeping line in fmtutils.c, it is trivially reviewable and unlikely to introduce regressions.

---

Severity, exposure and exploitability​

Official scoring and initial assessments​

Multiple trackers list CVSS v3.1 base scoring in the low range (1.9) with a typical vector of AV:L/AC:H/PR:H/UI:N — i.e., local attack vector, high complexity, and high required privileges. NVD lists the CVE and awaits enrichment, while distribution pages (Ubuntu, SUSE) and independent CVE aggregators show a low base severity. The public scoring and vendor notes emphasize three points:

• The issue applies only to Windows builds of libpcap (the conversion helper is Windows‑specific).
• Exploitation requires local access to the vulnerable process and, in many likely deployments, elevated privileges or at least the ability to influence a privileged process’ error‑message handling.
• The bug is a write‑past‑end in a utility function used for error‑message conversion; it is not a network parser that processes untrusted packets directly.

Practical exploitability​

In practical terms, turning this OOBW into an effective remote compromise looks unlikely for most environments:

• Many libpcap consumers that run on Windows are user‑mode tools (packet capture utilities, diagnosis tools), and the conversion helper is invoked only when formatting Windows error messages. An attacker must arrange for a vulnerable process to call the conversion routine with a contrived Windows error text that includes a 4‑byte Unicode character at the right position relative to the provided buffer length.
• The attack vector is therefore local: an adversary needs either to run code as the same user or must be able to interact with a privileged process in a way that leads it to call the conversion function on attacker‑controlled input. Trackers reflect this with a local/privileged attack vector and high privilege requirement in the CVSS vector used by the CNA.

These constraints produce a relatively low real‑world risk for remote, unauthenticated attackers; however, the integrity impact (data corruption or local process compromise) is not zero in targeted, privileged environments where libpcap is embedded inside system services or security appliances. Independent vulnerability summaries note there are no known public exploits at the time of disclosure.

---

Who should care​

• Windows systems running libpcap‑linked services: Any system service, capture appliance, or endpoint tool on Windows that links libpcap and writes Windows system messages using libpcap’s formatting helpers should be evaluated.
• Security and monitoring appliances: Network capture or device management appliances that run on Windows and include libpcap as a library are more exposed, particularly if they accept local inputs or administrative tasks that can lead to crafted error messages being fed into libpcap’s formatting code.
• Developers bundling libpcap statically: Applications that statically link libpcap into privileged or long‑running processes should plan rebuilds with the patched source to avoid lingering vulnerable binaries.
• Packagers and distributors: OS vendors and appliance vendors should ensure patched libpcap packages are built and distributed, and downstream integration tests verify no regressions in UTF‑encoding behavior. SUSE has evaluated the issue and marked relevant enterprise packages as not affected in some builds; Ubuntu lists the CVE and has evaluated severity and package status. Administrators should consult vendor advisories for exact package versions and status.

---

Mitigation and patching guidance​

Immediate steps​

• Upgrade libpcap to the commit/release that contains the fix. The upstream change is already committed to the tcpdump/libpcap tree; packagers will publish patched packages or releases that include the corrected line in fmtutils.c. The commit SHA and message provide a simple verification artifact.
• For systems that do not have immediate vendor updates available, consider limiting the attack surface in the short term:
  • Avoid running libpcap‑linked tools with excessive privileges where possible.
  • Restrict local access to machines and services that include libpcap, especially build servers and appliance management consoles.
  • Where feasible, replace Windows builds with builds that include the upstream fix (rebuild from source with the corrected commit applied).

Vendor and distribution actions​

1. Packagers should produce patched binary packages and clearly label the release containing the fix.
2. Vendors that ship embedded appliances should prepare firmware and application updates; test the update path in staging before broad deployment.
3. Security teams should update inventory and asset lists to locate Windows systems using libpcap and set prioritized remediation windows for those with elevated privileges or public exposure.

Ubuntu and SUSE have already recorded the CVE in their trackers; administrators using vendor distributions should track their normal update channels for an official patched package rather than rebasing ad‑hoc, unless the vendor directs otherwise.

---

Detection and validation​

How to detect vulnerable installations​

• Vendor package checks: Consult your distribution’s security tracker (e.g., Ubuntu CVE notices, SUSE CVE pages) for package versions and fixed package numbers. These pages are tracking the CVE and package status.
• Binary version checks: If you have control over the environment, query the libpcap version installed on Windows hosts. Cross‑check the binary build against upstream commit dates or rebuild with the patched source and compare checksums.
• Source audits: For statically linked software or custom builds, inspect fmtutils.c lines around the utf_16le_to_utf_8_truncated function to confirm the decrement line reads utf_8_len -= 4.

Testable assertions​

• Rebuild test: Recompiling libpcap with and without the commit produces binaries with different behavior on crafted inputs. Upstream commit messages and test artifacts (if provided) let maintainers validate the fix.
• Fuzz verification: A targeted fuzzer or test harness that supplies Windows error strings containing surrogate pairs or supplementary Unicode characters near truncation boundaries can exercise the path and confirm whether the corrected bookkeeping prevents buffer overflow.

---

Risk analysis — strengths and remaining risks​

Notable strengths​

• The fix is small, narrowly scoped, and easy to audit. The single-line correction demonstrates low risk of functional regression.
• Multiple independent trackers and the upstream project have converged on a common public record (commit, CVE entry, vendor acknowledgements), which aids rapid patch distribution and verification.
• The attack model is constrained (Windows only, local), lowering the immediate priority for many server‑side Linux deployments and remote attack paths.

Potential risks and caveats​

• The vulnerable code is in a widely used library; even low‑severity bugs can be consequential in appliances, vendor products, and security stacks that bundle and run libpcap with elevated privileges.
• Static linking and custom builds may leave long‑tail vulnerable installations that are not updated via normal OS package channels. Administrators should hunt for such artifacts in images, installers, and appliance builds.
• While exploitation seems difficult in the wild, memory corruption bugs are inherently risky: allocator nuances, nonstandard builds, or chained vulnerabilities could magnify impact in targeted scenarios. Treat claims of “no remote RCE” as accurate in normal conditions but remain cautious in high‑value environments. Independent advisories echo the lack of known public exploits but still document the CWE‑787 classification and the need for prompt patching in high‑privilege contexts.

---

Operational checklist (what to do now)​

1. Inventory: Identify Windows hosts and appliances with libpcap installed or vendor software that bundles libpcap.
2. Patch: Apply vendor or upstream patches as soon as they are available. If a vendor patch is not available, rebuild libpcap from source including the upstream commit that fixes utf_16le_to_utf_8_truncated.
3. Reduce privileges: Where practical, run libpcap consumers with least privilege to reduce the local attack surface.
4. Test updates: Validate patched binaries in staging, paying attention to logging and error‑message encoding functionality.
5. Monitor: Watch vendor security advisories and the NVD/CVE records for follow-on notes (package numbers, backports, or changes in scoring). SUSE and Ubuntu trackers already reflect the CVE and its low severity; check those pages for distribution‑specific guidance.

---

Conclusion​

CVE‑2025‑11964 is a textbook example of how a tiny copy‑and‑paste error in edge‑case encoding logic can produce a measurable memory‑safety bug. The practical risk is limited by platform scope (Windows builds), the local nature of the attack vector, and the requirement for crafted inputs in a context where libpcap will perform the conversion. Still, the problem is real: an out‑of‑bounds write was possible, and upstream maintainers fixed the arithmetic mistake in a straightforward commit. Operators running libpcap on Windows, vendors bundling libpcap into appliances, and maintainers of statically linked Windows applications should prioritize patching or rebuilding to incorporate the upstream fix and verify packages through their usual secure‑update channels.

---

Appendix — quick facts

• CVE: CVE‑2025‑11964.
• Vulnerability type: Out‑of‑bounds write (CWE‑787) in utf_16le_to_utf_8_truncated.
• Platform scope: Windows builds of libpcap only.
• Fix: upstream commit changed utf_8_len -= 3 to utf_8_len -= 4 in fmtutils.c.
• Severity: CVSS v3.1 base score ≈ 1.9 (Low) in initial CNA scoring; vendors list local attack vector with high privileges required.

The corrective action is simple, but the operational discipline—find every Windows binary that includes libpcap, apply the patched build, and validate—is the real work.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center