[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1362453419.3768.380.camel@deadeye.wl.decadent.org.uk>
Date: Tue, 5 Mar 2013 03:16:59 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Chen Gang <gang.chen@...anux.com>
CC: David Laight <David.Laight@...LAB.COM>,
<venkat.x.venkatsubra@...cle.com>,
David Miller <davem@...emloft.net>, <rds-devel@....oracle.com>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net/rds: using strlcpy instead of strncpy
On Tue, 2013-03-05 at 10:32 +0800, Chen Gang wrote:
> 于 2013年03月05日 02:34, Ben Hutchings 写道:
> > On Mon, 2013-03-04 at 18:32 +0000, Ben Hutchings wrote:
> >> > On Thu, 2013-02-28 at 09:36 +0000, David Laight wrote:
> >>> > >
> >>> > > If the target buffer ends up being copied to userspace that
> >>> > > might lead to random kernel memory being leaked.
> >> >
> >> > Seems it is. The last byte of 'name' is not currently initialised and
> >> > therefore is already leaked to userland.
> >> >
> >> > But it's OK because rds_info_copy() uses memcpy() not __copy_to_user(),
> >> > so SMAP will block this leak. :-)
> > Or not, as kmap() presumably evades that.
>
> is this patch ok, or need improving ?
I think it is wrong, and the code should be changed to do either:
1. Zero-initialise the whole of the name, then use strlcpy().
2. Keep using strncpy(), and also set the last byte of name to 0.
> BTW:
> excuse me, maybe my reply will be late during this week.
> the reason:
> my father had a serious heart disease, and is in hospital.
> during these days, most of my time has to be in hospital.
> (God Bless, and thank Jesus Christ, my father is safe, now).
> within my company (Asianux), I also have something to do.
Best wishes to you both.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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