netdev - Re: [PATCH 1/6] can: j1939: fix kernel-infoleak in j1939_sk_sock2sockaddr

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>] [day] [month] [year] [list]

Message-ID: <CANn89iLX_w0Bz211qPk_npCqq1NbBQsGMNZkkZQgC_qa7k+KaQ@mail.gmail.com>
Date:   Fri, 14 Aug 2020 08:08:11 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>,
        Networking <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, linux-can@...r.kernel.org,
        kernel@...gutronix.de, syzbot <syzkaller@...glegroups.com>,
        Robin van der Gracht <robin@...tonic.nl>,
        Oleksij Rempel <o.rempel@...gutronix.de>
Subject: Re: [PATCH 1/6] can: j1939: fix kernel-infoleak in j1939_sk_sock2sockaddr_can()

On Fri, Aug 14, 2020 at 6:20 AM Alexander Potapenko <glider@...gle.com> wrote:
>
>
>
> On Fri, Aug 14, 2020, 13:04 Marc Kleine-Budde <mkl@...gutronix.de> wrote:
>>
>> From: Eric Dumazet <edumazet@...gle.com>

>>  net/can/j1939/socket.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/net/can/j1939/socket.c b/net/can/j1939/socket.c
>> index 78ff9b3f1d40..b634b680177f 100644
>> --- a/net/can/j1939/socket.c
>> +++ b/net/can/j1939/socket.c
>> @@ -553,6 +553,11 @@ static int j1939_sk_connect(struct socket *sock, struct sockaddr *uaddr,
>>  static void j1939_sk_sock2sockaddr_can(struct sockaddr_can *addr,
>>                                        const struct j1939_sock *jsk, int peer)
>>  {
>> +       /* There are two holes (2 bytes and 3 bytes) to clear to avoid
>> +        * leaking kernel information to user space.
>> +        */
>
>
> Do we want to keep these "2 bytes and 3 bytes' in sync with the struct layout in the future? Maybe it's not worth it to mention the exact sizes?

struct is uapi, you will have a hard time trying to use these holes,
since old kernels were sending crap/garbage/passwords ;)