NetBSD Problem Report #59997

From www@netbsd.org  Thu Feb 12 01:16:55 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 041F61A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 12 Feb 2026 01:16:55 +0000 (UTC)
Message-Id: <20260212011653.C6B071A923C@mollari.NetBSD.org>
Date: Thu, 12 Feb 2026 01:16:53 +0000 (UTC)
From: david@gutteridge.ca
Reply-To: david@gutteridge.ca
To: gnats-bugs@NetBSD.org
Subject: if_ure.c has a check to avoid setting hardware capabilities that's impossible to satisfy
X-Send-Pr-Version: www-1.0
X-From4GNATS: "david@gutteridge.ca via gnats" <gnats-admin@NetBSD.org>

>Number:         59997
>Category:       kern
>Synopsis:       if_ure.c has a check to avoid setting hardware capabilities that's impossible to satisfy
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 12 01:20:00 +0000 2026
>Last-Modified:  Wed Feb 25 01:35:01 +0000 2026
>Originator:     David H. Gutteridge
>Release:        HEAD as of 2026-02-11
>Organization:
TNF
>Environment:
NetBSD arcusxx.nonus-porta.net 11.99.5 NetBSD 11.99.5 (GENERIC) #0: Sun Feb  8 14:58:19 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
if_ure.c has a check to avoid setting hardware capabilities that's
impossible to satisfy, given the state of the code.

(Line numbers as of if_ure.c r. 1.62.)

At line 939 we have:

if (un->un_flags & ~URE_FLAG_VER_4C00) {
(Which then sets various presumably hardware-specific capabilities.)

However, above this at line 815 we have:

if (uaa->uaa_product == USB_PRODUCT_REALTEK_RTL8152)
    un->un_flags |= URE_FLAG_8152;

The Realtek 4C00 device is an 8152 chipset, thus URE_FLAG_8152 is set,
and the bitwise complement of URE_FLAG_VER_4C00 isn't sufficient to
test what's intended there.

(As a demonstration of that ID combination:
[     4.439971] ure0: Realtek (0x0bda) USB 10/100 LAN (0x8152), rev 2.10/20.00, addr 3
[     4.453798] ure0: RTL8152 ver 4c00
Courtesy of: https://dmesgd.nycbug.org/dmesgd?do=view&id=7514 )

Presumably this test should really be:

if (un->un_flags & ~(URE_FLAG_8152 | URE_FLAG_VER_4C00)) {

This has existed in this state since r. 1.1 of the file. I don't see
the equivalent context in OpenBSD's version, though their code diverges
in all sorts of ways for various reasons, anyway. I haven't looked at
Linux to see contextually what it does -- I assume this oldest device
version "4C00" lacks these capabilities, but don't know the reference.

The reasons I haven't just gone in and changed this:
  * I don't have any "4C00" hardware to test with (I only have much
    newer).
  * I haven't looked at all the equivalent code so far, only OpenBSD.
  * Maybe I'm having a bad day and hallucinating like some code
    inspection tools do.

(I'm happy to commit the change, of course.)
>How-To-Repeat:
Human-powered code inspection.
>Fix:
As above.

>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59997: if_ure.c has a check to avoid setting hardware capabilities that's impossible to satisfy
Date: Fri, 13 Feb 2026 01:18:52 +0700

     Date:        Thu, 12 Feb 2026 01:20:01 +0000 (UTC)
     From:        "david@gutteridge.ca via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20260212012001.340281A923D@mollari.NetBSD.org>


   | Presumably this test should really be:
   |
   | if (un->un_flags & ~(URE_FLAG_8152 | URE_FLAG_VER_4C00)) {

 I have none of those, and know nothing about them at all, but
 it looks to me as if the what the test probably really intended
 was

 	if (!(un->un_flags & URE_FLAG_VER_4C00)) {

 That is, if it is not a 4C00 (using the original to test for that
 state is simply bizarre, but is also the kind of thing easy to do).

 But there is more odd code around there ... the transmit offload
 capabilities for v6 are only set if INET6 is defined (which is
 reasonable) but the similar receive capabilities are set unconditionally
 (except for the above test) which makes little sense to me.

 kre


From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: kre@netbsd.org
Subject: Re: kern/59997: if_ure.c has a check to avoid setting hardware
 capabilities that's impossible to satisfy
Date: Tue, 24 Feb 2026 19:32:05 -0500

 On Thu, 2026-02-12 at 18:20 +0000, Robert Elz via gnats wrote:
 > The following reply was made to PR kern/59997; it has been noted by
 > GNATS.
 >=20
 > From: Robert Elz <kre@munnari.OZ.AU>
 > To: gnats-bugs@netbsd.org
 > Cc:=20
 > Subject: Re: kern/59997: if_ure.c has a check to avoid setting
 > hardware capabilities that's impossible to satisfy
 > Date: Fri, 13 Feb 2026 01:18:52 +0700
 >=20
 > =C2=A0=C2=A0=C2=A0=C2=A0 Date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
 Thu, 12 Feb 2026 01:20:01 +0000 (UTC)
 > =C2=A0=C2=A0=C2=A0=C2=A0 From:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
 "david@gutteridge.ca=C2=A0via gnats"
 > <gnats-admin@NetBSD.org>
 > =C2=A0=C2=A0=C2=A0=C2=A0 Message-ID:=C2=A0 <20260212012001.340281A923D@mo=
 llari.NetBSD.org>
 > =C2=A0
 > =C2=A0
 > =C2=A0=C2=A0 | Presumably this test should really be:
 > =C2=A0=C2=A0 |
 > =C2=A0=C2=A0 | if (un->un_flags & ~(URE_FLAG_8152 | URE_FLAG_VER_4C00)) {
 > =C2=A0
 > =C2=A0I have none of those, and know nothing about them at all, but
 > =C2=A0it looks to me as if the what the test probably really intended
 > =C2=A0was
 > =C2=A0
 > =C2=A0	if (!(un->un_flags & URE_FLAG_VER_4C00)) {
 > =C2=A0
 > =C2=A0That is, if it is not a 4C00 (using the original to test for that
 > =C2=A0state is simply bizarre, but is also the kind of thing easy to do).

 Thanks, yes, your way of expressing that is simpler; I got lost in the
 existing style there.

 I also looked at the Linux driver provided by Realtek itself, and, yes
 the intent is indeed that 4C00 *only* is supposed to not advertise/
 enable those particular capabilities. (Much like with our code, there's
 no comment explaining why, and the change history is useless, as it
 simply syncs with a vendor-internal source. Evidently 4C00's buggy.
 I see similar things elsewhere, e.g., our ic/gem.c disables some
 offloading capabilities, but it has a nice comment explaining what's
 going on.) The way the Linux driver expresses that is different enough
 from our code (turns on all capabilities universally, then selectively
 disables 4C00, and the coding specifics vary considerably).

 (I tried to find relevant hardware, and came across a sub-$10 dongle
 that advertised as an 8152B, but unfortunately it's the 4C10 variant.
 Oh well.)
 =C2=A0
 > =C2=A0But there is more odd code around there ... the transmit offload
 > =C2=A0capabilities for v6 are only set if INET6 is defined (which is
 > =C2=A0reasonable) but the similar receive capabilities are set
 > unconditionally
 > =C2=A0(except for the above test) which makes little sense to me.=C2=A0

 I looked at pretty much every other driver I could find in our tree
 that offers any IPv6 checksum offloading, and none of them wrap those
 capabilities in an INET6 ifdef, so it seems simpler to follow suit
 here and avoid the potential confusion/inconsistency.

 Thanks,

 Dave

From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59997 CVS commit: src/sys/dev/usb
Date: Wed, 25 Feb 2026 01:34:14 +0000

 Module Name:	src
 Committed By:	gutteridge
 Date:		Wed Feb 25 01:34:14 UTC 2026

 Modified Files:
 	src/sys/dev/usb: if_ure.c

 Log Message:
 if_ure.c: make hardware capabilities test work as intended

 As originally coded, the test intended to not set certain checksum
 offload capabilities for the oldest RTL8152 chip revision couldn't
 actually take effect. (The Realtek 4C00 device is an 8152 chipset,
 thus URE_FLAG_8152 is also set, and the bitwise complement of
 URE_FLAG_VER_4C00 isn't sufficient to test what's intended there.)

 While here, also remove an inconsistently-applied INET6 check. Half the
 relevant capabilities weren't guarded, and no other driver in our tree
 guards IPv6 hardware checksumming this way, so follow suit here and
 avoid the potential confusion/inconsistency.

 Addresses PR kern/59997. Thanks to kre@ for significant input here.


 To generate a diff of this commit:
 cvs rdiff -u -r1.62 -r1.63 src/sys/dev/usb/if_ure.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Home	PR Database Search