[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141106071109.GX7996@ZenIV.linux.org.uk>
Date: Thu, 6 Nov 2014 07:11:09 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, bcrl@...ck.org,
Masahide Nakamura <nakam@...ux-ipv6.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: ipv4: Use standard iovec primitive in raw_probe_proto_opt
On Thu, Nov 06, 2014 at 02:46:29PM +0800, Herbert Xu wrote:
> On Thu, Nov 06, 2014 at 06:43:18AM +0000, Al Viro wrote:
> > On Thu, Nov 06, 2014 at 01:50:23PM +0800, Herbert Xu wrote:
> > > + /* We only need the first two bytes. */
> > > + err = memcpy_fromiovecend((void *)&icmph, msg->msg_iov, 0, 2);
> > > + if (err)
> > > + return err;
> > > +
> > > + fl4->fl4_icmp_type = icmph.type;
> > > + fl4->fl4_icmp_code = icmph.code;
> >
> > That's more readable, but that exposes another problem in there - we read
> > the same piece of userland data twice, with no promise whatsoever that we'll
> > get the same value both times...
>
> Sure, but you have to be root anyway to write to raw sockets.
Point, but that might very well be a pattern to watch for - there's at least
one more instance in TIPC (also not exploitable, according to TIPC folks)
and such bugs are easily repeated...
BTW, I've picked the tun and macvtap related bits from another part of old
queue; see vfs.git#untested-macvtap - it's on top of #iov_iter-net and it's
really completely untested. Back then I was mostly interested in killing
as many ->aio_write() instances as I could, so it's only the "send" side of
things.
--
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