netdev - Re: BUG: NIU driver: strange issues with multicast "UDP: short packet"

lists.openwall.net		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]

Message-Id: <1233739926.20497.78.camel@localhost.localdomain>
Date:	Wed, 04 Feb 2009 10:32:06 +0100
From:	Jesper Dangaard Brouer <jdb@...x.dk>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: BUG: NIU driver: strange issues with multicast "UDP: short
	packet"

On Wed, 2009-02-04 at 01:00 -0800, David Miller wrote:
> From: Jesper Dangaard Brouer <jdb@...x.dk>
> Date: Wed, 04 Feb 2009 09:55:04 +0100
> 
> > On Tue, 2009-02-03 at 15:38 -0800, David Miller wrote:
> > > From: Jesper Dangaard Brouer <jdb@...x.dk>
> > > Date: Tue, 03 Feb 2009 14:38:20 +0100
> > > 
> > > >   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
> > > >   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > 
> > > The UDP header length field is garbage in all of these packets.
> > 
> > Yes, but this only happens on the NIU/netpune NIC.  I works with the igb
> > driver, I have both a 82575 and a 82576 NIC.
> 
> Right, and what's unique about NIU is that NIU won't prepull
> the protocol headers into the linear area on receive.

So thats the difference...

> At the point when IPMR is dealing with potentially forwarding
> the frame, the UDP headers aren't yet pulled into the linear
> area.  UDP input will do that with it's pskb_may_pull() call.

Can I get a little code hint, where IPMR is dealing with potentially
forwarding the frame?

> I think this is the critical bit, and some part of the IPMR
> code makes assumptions about all of the protocol headers being
> pulled into the linear SKB area when it executes.
> 
> I really don't have time to track this down, so what I suggest
> you do is add logging to UDP multicast packets at various
> locations looking for the UDP header length in the paged SKB
> area to go illegal.  Move your probe points around to narrow
> down the culprit.

Is there an easy way to test if the packet is corrupted?
Can you recomment a way to test it?


> Good luck.

Thanks I'm going to need it ;-)

Thanks for you quick answer.
-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html