[PATCH] fix cid 1350009

[Michael Adam]

On 2016-02-03 at 13:41 +0100, Volker Lendecke wrote:
> On Wed, Feb 03, 2016 at 11:43:07AM +0100, Michael Adam wrote:
> > Review/push appreciated.
> > 
> > Thanks - Michael
> 
> > From 267367964c957af33c8dded90bb61c009ed29039 Mon Sep 17 00:00:00 2001
> > From: Michael Adam <obnox at samba.org>
> > Date: Wed, 3 Feb 2016 11:41:23 +0100
> > Subject: [PATCH] lib:socket: fix CID 1350009 - illegal memory accesses 
> >  (BUFFER_SIZE_WARNING)
> > 
> > Signed-off-by: Michael Adam <obnox at samba.org>
> > ---
> >  lib/socket/interfaces.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/socket/interfaces.c b/lib/socket/interfaces.c
> > index f0386c0..c1229f2 100644
> > --- a/lib/socket/interfaces.c
> > +++ b/lib/socket/interfaces.c
> > @@ -140,7 +140,8 @@ static void query_iface_speed_from_name(const char *name, uint64_t *speed)
> >  		return;
> >  	}
> >  
> > -	strncpy(ifr.ifr_name, name, IF_NAMESIZE);
> > +	strncpy(ifr.ifr_name, name, IF_NAMESIZE - 1);
> > +	ifr.ifr_name[IF_NAMESIZE] = '\0';
> 
> I saw this one, but I was not sure about the expectation of
> ioctl(SIOCETHTOOL). Don't we unnecessarily cut the interface name
> here?

Right. I am not 100% certain either.
There are a couple of other occurrences, e.g. in
ctdb/common/system_linux.c , in that case for use
with SIOCGIFINDEX:

	strlcpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name));

which effectively has the same effect.

but also

	strncpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name)-1);

and

	strncpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name));

So that is at least inconsistent.

The ethtool code hast this:

	if (strlen(ctx.devname) >= IFNAMSIZ)
		exit_bad_args();

So it expects interface name to be < IF_NAMESIZE.
Should we rather throw an error in the case the IF
name is longer?

Thanks for your input,

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160203/f34005b3/signature.sig>