From: walter harms <wharms@bfs.de>
To: Vasiliy Kulikov <segooon@gmail.com>
Cc: David Miller <davem@davemloft.net>,
kernel-janitors@vger.kernel.org, jon.maloy@ericsson.com,
allan.stephens@windriver.com,
tipc-discussion@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] net: tipc: fix information leak to userland
Date: Wed, 10 Nov 2010 11:58:54 +0000 [thread overview]
Message-ID: <4CDA88FE.8040801@bfs.de> (raw)
In-Reply-To: <20101109203317.GA24933@albatros>
Am 09.11.2010 21:33, schrieb Vasiliy Kulikov:
> On Tue, Nov 09, 2010 at 09:26 -0800, David Miller wrote:
>> From: Vasiliy Kulikov <segooon@gmail.com>
>> Date: Sun, 31 Oct 2010 20:10:32 +0300
>>
>>> Structure sockaddr_tipc is copied to userland with padding bytes after
>>> "id" field in union field "name" unitialized. It leads to leaking of
>>> contents of kernel stack memory. We have to initialize them to zero.
>>>
>>> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
>>
>> Applied.
>>
>> Patches #1 and #2 were given feedback which I need you to integrate
>> and submit new patches based upon, thanks.
>
> About #2:
>
> I still think that this:
>
> if (dev)
> strncpy(uaddr->sa_data, dev->name, 14);
> else
> memset(uaddr->sa_data, 0, 14);
>
> is better than this:
>
> memset(uaddr->sa_data, 0, 14);
> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> if (dev)
> strlcpy(uaddr->sa_data, dev->name, 15);
>
> Doesn't it? Explicitly filling with zero on the same "if" level is
> slightly easier to read and understand.
>
no problem with me, since i came up with the idea a simple explanation:
IMHO the pattern clear/if/copy is more robust
NTL the core problem was that sizeof sa_data is 14 while dev->name is IFNAMESZ\x15.
re,
wh
WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: Vasiliy Kulikov <segooon@gmail.com>
Cc: David Miller <davem@davemloft.net>,
kernel-janitors@vger.kernel.org, jon.maloy@ericsson.com,
allan.stephens@windriver.com,
tipc-discussion@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] net: tipc: fix information leak to userland
Date: Wed, 10 Nov 2010 12:58:54 +0100 [thread overview]
Message-ID: <4CDA88FE.8040801@bfs.de> (raw)
In-Reply-To: <20101109203317.GA24933@albatros>
Am 09.11.2010 21:33, schrieb Vasiliy Kulikov:
> On Tue, Nov 09, 2010 at 09:26 -0800, David Miller wrote:
>> From: Vasiliy Kulikov <segooon@gmail.com>
>> Date: Sun, 31 Oct 2010 20:10:32 +0300
>>
>>> Structure sockaddr_tipc is copied to userland with padding bytes after
>>> "id" field in union field "name" unitialized. It leads to leaking of
>>> contents of kernel stack memory. We have to initialize them to zero.
>>>
>>> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
>>
>> Applied.
>>
>> Patches #1 and #2 were given feedback which I need you to integrate
>> and submit new patches based upon, thanks.
>
> About #2:
>
> I still think that this:
>
> if (dev)
> strncpy(uaddr->sa_data, dev->name, 14);
> else
> memset(uaddr->sa_data, 0, 14);
>
> is better than this:
>
> memset(uaddr->sa_data, 0, 14);
> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> if (dev)
> strlcpy(uaddr->sa_data, dev->name, 15);
>
> Doesn't it? Explicitly filling with zero on the same "if" level is
> slightly easier to read and understand.
>
no problem with me, since i came up with the idea a simple explanation:
IMHO the pattern clear/if/copy is more robust
NTL the core problem was that sizeof sa_data is 14 while dev->name is IFNAMESZ=15.
re,
wh
next prev parent reply other threads:[~2010-11-10 11:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-31 17:10 [PATCH 3/3] net: tipc: fix information leak to userland Vasiliy Kulikov
2010-10-31 17:10 ` Vasiliy Kulikov
2010-11-09 17:26 ` David Miller
2010-11-09 17:26 ` David Miller
2010-11-09 17:26 ` David Miller
2010-11-09 20:33 ` Vasiliy Kulikov
2010-11-09 20:33 ` Vasiliy Kulikov
2010-11-10 11:58 ` walter harms [this message]
2010-11-10 11:58 ` walter harms
2010-11-10 15:54 ` Vasiliy Kulikov
2010-11-10 15:54 ` Vasiliy Kulikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CDA88FE.8040801@bfs.de \
--to=wharms@bfs.de \
--cc=allan.stephens@windriver.com \
--cc=davem@davemloft.net \
--cc=jon.maloy@ericsson.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=segooon@gmail.com \
--cc=tipc-discussion@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.