netdev - Re: [PATCH] decnet: fix DN_IFREQ

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

Message-Id: <20190127.231311.1851509323400218212.davem@redhat.com>
Date:   Sun, 27 Jan 2019 23:13:11 -0800 (PST)
From:   David Miller <davem@...hat.com>
To:     johannes@...solutions.net
Cc:     netdev@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-decnet-user@...ts.sourceforge.net, johannes.berg@...el.com
Subject: Re: [PATCH] decnet: fix DN_IFREQ_SIZE

From: Johannes Berg <johannes@...solutions.net>
Date: Sat, 26 Jan 2019 21:12:19 +0100

> From: Johannes Berg <johannes.berg@...el.com>
> 
> Digging through the ioctls with Al because of the previous
> patches, we found that on 64-bit decnet's dn_dev_ioctl()
> is wrong, because struct ifreq::ifr_ifru is actually 24
> bytes (not 16 as expected from struct sockaddr) due to the
> ifru_map and ifru_settings members.
> 
> Clearly, decnet expects the ioctl to be called with a struct
> like
>   struct ifreq_dn {
>     char ifr_name[IFNAMSIZ];
>     struct sockaddr_dn ifr_addr;
>   };
> 
> since it does
>   struct ifreq *ifr = ...;
>   struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr;
> 
> This means that DN_IFREQ_SIZE is too big for what it wants on
> 64-bit, as it is
>   sizeof(struct ifreq) - sizeof(struct sockaddr) +
>   sizeof(struct sockaddr_dn)
> 
> This assumes that sizeof(struct sockaddr) is the size of ifr_ifru
> but that isn't true.
> 
> Fix this to use offsetof(struct ifreq, ifr_ifru).
> 
> This indeed doesn't really matter much - the result is that we
> copy in/out 8 bytes more than we should on 64-bit platforms. In
> case the "struct ifreq_dn" lands just on the end of a page though
> it might lead to faults.
> 
> As far as I can tell, it has been like this forever, so it seems
> very likely that nobody cares.
> 
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>

Applied.