netdev - Re: [PATCH] netfilter: fix buffer null termination

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, 14 Jun 2016 21:52:49 +0530
From:	Kishan Sandeep <sandeepkishan108@...il.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>
Cc:	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] netfilter: fix buffer null termination

Hi Pablo,

On Tue, Jun 14, 2016 at 8:38 PM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> Cc'ing netfilter-devel.
>
> On Tue, Jun 14, 2016 at 07:39:27PM +0530, Kishan Sandeep wrote:
>> + netdev
>>
>> On Sat, Jun 11, 2016 at 10:18 AM, Kishan Sandeep
>> <sandeepkishan108@...il.com> wrote:
>> > strncpy generally perferable fo non-terminated
>> > fixed-width strings. For NULL termination strlcpy
>> > is preferrable.
>> >
>> > Signed-off-by: Kishan Sandeep <sandeepkishan108@...il.com>
>> > ---
>> >  net/netfilter/xt_repldata.h |    2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/net/netfilter/xt_repldata.h b/net/netfilter/xt_repldata.h
>> > index 8fd3241..a460211 100644
>> > --- a/net/netfilter/xt_repldata.h
>> > +++ b/net/netfilter/xt_repldata.h
>> > @@ -28,7 +28,7 @@
>> >         if (tbl == NULL) \
>> >                 return NULL; \
>> >         term = (struct type##_error *)&(((char *)tbl)[term_offset]); \
>> > -       strncpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
>> > +       strlcpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
>
> I don't think this is actually fixing anything. Tables in x_tables
> have a known and fixed name that is defined from the kernel side, that
> is always smaller that the buffer we have there. So are you observing
> any real problem from there?
>
> Thanks.

Not observed any real problem. Here the string is not NULL terminated with
the use of strncpy - that is the problem. With the use of strlcpy we can make
the string to terminated properly.

Thanks!