netdev - Re: [PATCH] net/rds: using strlcpy instead of strncpy

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:	Tue, 05 Mar 2013 10:32:22 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Ben Hutchings <bhutchings@...arflare.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

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

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.


 :-)

-- 
Chen Gang

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