lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Feb 2014 13:00:48 +0100
From:	Emil Goode <>
To:	Oliver Neukum <>
Cc:	"David S. Miller" <>,
	Ming Lei <>,
	Mark Brown <>,
	Jeff Kirsher <>,
	Glen Turner <>,,,
Subject: Re: [PATCH 1/2 v2] usbnet: fix bad header length bug

On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
> On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> > The AX88772B occasionally send rx packets that cross urb boundaries
> > and the remaining partial packet is sent with no hardware header.
> > When the buffer with a partial packet is of less number of octets
> > than the value of hard_header_len the buffer is discarded by the
> > usbnet module. This is causing dropped packages and error messages
> > in dmesg.
> > 
> > This can be reproduced by using ping with a packet size
> > between 1965-1976.
> Well, then how about simply removing the check?
> It seems to have outlived its usefulness.
> 	Regards
> 		Oliver

I did consider that and I think it is probably the best thing to do.
However, I think the removal of the check could have negative effects
on the other minidrivers, at least the qmi_wwan minidriver explicitly
states that it is depending on this check to be made in rx_complete().

For safety the check could be added at the top of the rx_fixup callback
of the affected minidrivers.

There are devices that depend on the usbnet module that do not have
a rx_fixup callback assigned to it's driver_info struct, the check
could be added for these in the rx_process function.

This led me to think it would be a lot of noise about a small check :)

My conclusion is that 12 rx_fixup callbacks might need the check
to be added. There are 18 driver_info structs with no rx_fixup
callback assigned, these devices might need the check to be added
to the rx_process function.

Patches could be sent out to notify the affected minidrivers of the
change and hopefully someone has the hardware to test if it's 
necessary to add the check to the minidriver?

I'm happy to do this if it seem like a good idea.

Best regards,

Emil Goode
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists