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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 31 Dec 2010 23:16:29 +0200
From:	"Winkler, Tomas" <tomas.winkler@...el.com>
To:	David Miller <davem@...emloft.net>,
	"stephen.hemminger@...tta.com" <stephen.hemminger@...tta.com>
CC:	"shemminger@...tta.com" <shemminger@...tta.com>,
	"johannes@...solutions.net" <johannes@...solutions.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs



> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Friday, December 31, 2010 10:46 PM
> To: stephen.hemminger@...tta.com
> Cc: Winkler, Tomas; shemminger@...tta.com; johannes@...solutions.net;
> netdev@...r.kernel.org; linux-wireless@...r.kernel.org
> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> skbs
> 
> From: Stephen Hemminger <stephen.hemminger@...tta.com>
> Date: Thu, 30 Dec 2010 15:06:16 -0800
> 
> > Although copy is slower for large packets, this is a non performance
> > path. The code in question is for bridged multicast Ipv6 ICMP
> > packets. This case is so uncritical it could be done in BASIC and no
> > one could possibly care!
> 
> I still think we should be judicious and keep using skb_clone() here.
> 
> Simply combine the two pskb_may_pull() calls into one on "skb2" after
> the clone and before the blind __skb_pull() call.  Then add a error
> path "out:" called "out_nopush:" for the error path to goto.
> 
> Also, I think the "+ 1" in the ipv6 stack code comes from the fact that
> the parsing loop can "peek" into the next header's byte to see the type.
> And I really don't think it's relevant here.
> 
> Also, all of these "x_header + ... + 1 - skb->data" factors are
> irrelevent and shouldn't be used.  Just pass "offset + sizeof(*icmp6h)"
> to pskb_may_pull().

Sounds reasonable but maybe we shall pass offset + sizeof(struct mld_msg) as *icmp6h is casted to this struct mld_mca is accessed.

struct mld_msg {
        struct icmp6hdr         mld_hdr;
        struct in6_addr         mld_mca;
};

Thanks
Tomas


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
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