Public bug reported:

Package: net-tools
Version: 2.10-0.1ubuntu4.4
Distribution: Ubuntu 24.04.5 LTS (noble)
Architecture: amd64
Kernel: 6.8.0-147-generic
libc6: 2.39-0ubuntu8.9
Suggested severity: normal (incorrect statistics display)

SUMMARY

ifconfig displays zero RX/TX packet and byte counters for a valid interface
name of exactly IFNAMSIZ-1 (15) characters. The kernel and driver do account
for traffic: ip -s link, /proc/net/dev, sysfs statistics and ethtool -S all
report non-zero, increasing values for the same interface.

The installed version already includes the earlier statistics regression
fix, so this appears to be an uncovered boundary case rather than simply
an installation missing that fix.

OBSERVED BEHAVIOR

On an active USB Wi-Fi interface whose name has 15 characters, ifconfig
prints:

    RX packets 0  bytes 0 (0.0 B)
    TX packets 0  bytes 0 (0.0 B)

At the same time, the kernel reported non-zero values (approximately
12.2 MB received and 12.7 MB transmitted in one diagnostic sample), and
those counters continued to increase.

The interface name, MAC address, IP addresses and network names from the
machine are omitted here. The synthetic name wlx001122334455 has exactly
the same relevant property: it is a valid 15-character interface name.

EXPECTED BEHAVIOR

ifconfig should parse and display the actual kernel counters for valid
15-character interface names, as it does for shorter interface names.

ROOT-CAUSE ANALYSIS

In lib/interface.c, get_name() limits copying to IFNAMSIZ-1 characters via
the dst < end loop condition. For an ordinary 15-character name, the loop
exits immediately after copying the last character, while the input
pointer still points to the ':' separator from /proc/net/dev.

The separator-consuming branch is inside that loop and is therefore not
reached in this case. if_readlist_proc() passes the returned pointer to
get_dev_fields(), which calls sscanf() expecting numeric fields. With a
leading ':', conversion fails and the initially zero counters remain zero.

This is a delimiter-consumption issue, not evidence of missing accounting
in the Wi-Fi driver. No malformed or overlong interface name is needed.

PACKAGE SOURCE CHECK

The Ubuntu source package archive was inspected:

https://archive.ubuntu.com/ubuntu/pool/main/n/net-tools/net-
tools_2.10-0.1ubuntu4.4.debian.tar.xz

The relevant patches are:

  debian/patches/CVE-2025-46836.patch
  debian/patches/CVE-2025-46836-fix-regression.patch

The latter moves consumption of the trailing ':' within the colon-handling
branch. It fixes ordinary shorter names, but does not handle exiting the
outer loop because the 15-character copy limit has been reached.

The same relevant control flow was present in the upstream source inspected:
https://github.com/ecki/net-tools/blob/master/lib/interface.c

MINIMAL, UNPRIVILEGED REPRODUCER

Attached: reproduce-ifconfig-parser.c and reproducer-output.txt

Compile and run:

    cc -Wall -Wextra -Werror -O2 reproduce-ifconfig-parser.c -o reproduce
    ./reproduce

The attached program is an independently written minimal model of the
ordinary, non-alias name parsing path. It is NOT a compiled copy of all
of net-tools and does not create a real interface. Its purpose is to
isolate the boundary condition without requiring root or network access.

Output:

    name=abcdefghijklmn length=14 next=' ' parsed_fields=1 rx_bytes=123456
    name=wlx001122334455 length=15 next=':' parsed_fields=0 rx_bytes=0
    after consuming delimiter: parsed_fields=1 rx_bytes=123456

The actual installed ifconfig binary was also tested using a temporary,
process-local fopen/fopen64 interposer. Only in that process's read-only
view of /proc/net/dev, the separator immediately following the real
15-character interface name was replaced with whitespace. ifconfig then
reported the real counters, consistent with the kernel's values. No
interface, kernel, driver, installed binary or persistent environment
setting was changed by that diagnostic.

POSSIBLE FIX DIRECTION

Ensure that a valid trailing separator is consumed even when name copying
finishes because the destination has reached IFNAMSIZ-1, while retaining
the bounds check and NUL termination introduced by the security fix.

Please also test interface aliases and malformed input before accepting
a production patch. The attached model intentionally tests only ordinary
14- and 15-character names; it is not a full alias/parser regression suite.
Do not revert the security fix.

RELATED REPORTS

Ubuntu LP #2111912 (earlier general counter regression):
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/2111912

Debian #1106147 (earlier general counter regression, marked fixed):
https://bugs.debian.org/1106147

Upstream #51 (earlier general counter regression, marked fixed):
https://sourceforge.net/p/net-tools/bugs/51/

This report concerns a remaining 15-character boundary case on a package
that already includes the previous regression fix. Please link or mark
as duplicate if this exact boundary case is tracked elsewhere.

** Affects: net-tools (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172712

Title:
  ifconfig reports zero RX/TX statistics for valid 15-character
  interface names after the CVE-2025-46836 regression fix

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/2172712/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to