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]
Date:	Sat, 17 Nov 2007 16:09:26 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	andi@...stfloor.org
Cc:	wangchen@...fujitsu.com, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] [IPV4] UDP: Always checksum even if without socket
 filter

From: Andi Kleen <andi@...stfloor.org>
Date: Sat, 17 Nov 2007 14:18:46 +0100

> Wang Chen <wangchen@...fujitsu.com> writes:
> 
> > Herbert Xu said the following on 2007-11-16 12:11:
> >> Wang Chen <wangchen@...fujitsu.com> wrote:
> >>> So, I think the checksum in udp_queue_rcv_skb() actually does
> >>> the work, not that in udp_recvmsg() and udp_poll().
> >>>
> >>> If I am wrong, please point out.
> >> 
> >> We may have a bug in the accounting area.  Check the recent
> >> patch made to UDP/IPv6 which is probably needed here as well.
> >> 
> >
> > Like dave said, decrementing the InDataGrams in this case is an
> > option.
> > I will check the same place of UDP/IPv6.
> 
> And like Benny pointed out it's probably a bad idea because
> decrementing counters will be an unexpected ABI change for monitoring 
> programs who have no other way to detect overflow.

We could defer the increment until we check the checksum,
but that is likely to break even more things because people
(as Wang Chen did initially) will send a packet to some
port with an app that doesn't eat the packets, and expect the
InDatagrams counter to increase once the stack eats the packet.
But it won't until the application does the read.

All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP application overflow detection issue.

-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ