linux-kernel - Re: [PATCH][next] net/ipv4: Replace one-element array with flexible-array member

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: <4a9987c1-1f7a-35af-af6a-01b96292d2ee@embeddedor.com>
Date:   Mon, 2 Aug 2021 14:15:40 -0500
From:   "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To:     patchwork-bot+netdevbpf@...nel.org,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc:     davem@...emloft.net, kuba@...nel.org, yoshfuji@...ux-ipv6.org,
        dsahern@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH][next] net/ipv4: Replace one-element array with
 flexible-array member



On 8/2/21 13:46, Gustavo A. R. Silva wrote:
> 
> 
> On 8/2/21 09:20, patchwork-bot+netdevbpf@...nel.org wrote:
>> Hello:
>>
>> This patch was applied to netdev/net-next.git (refs/heads/master):
>>
>> On Sat, 31 Jul 2021 12:08:30 -0500 you wrote:
>>> There is a regular need in the kernel to provide a way to declare having
>>> a dynamically sized set of trailing elements in a structure. Kernel code
>>> should always use “flexible array members”[1] for these cases. The older
>>> style of one-element or zero-length arrays should no longer be used[2].
>>>
>>> Use an anonymous union with a couple of anonymous structs in order to
>>> keep userspace unchanged:
>>>
>>> [...]
>>
>> Here is the summary with links:
>>   - [next] net/ipv4: Replace one-element array with flexible-array member
>>     https://git.kernel.org/netdev/net-next/c/2d3e5caf96b9
> 
> arghh... this has a bug. Sorry, Dave. I will send a fix for this, shortly.
> 

BTW... can we expect msf->imsf_numsrc to be zero at some point in the following
pieces of code?

net/ipv4/igmp.c:
2553         copycount = count < msf->imsf_numsrc ? count : msf->imsf_numsrc;
2554         len = copycount * sizeof(psl->sl_addr[0]);
2555         msf->imsf_numsrc = count;
2556         if (put_user(IP_MSFILTER_SIZE(copycount), optlen) ||
2557             copy_to_user(optval, msf, IP_MSFILTER_SIZE(0))) {
2558                 return -EFAULT;
2559         }

net/ipv4/ip_sockglue.c:
1228         case IP_MSFILTER:
1229         {
1230                 struct ip_msfilter *msf;
1231
1232                 if (optlen < IP_MSFILTER_SIZE(0))
1233                         goto e_inval;
1234                 if (optlen > sysctl_optmem_max) {
1235                         err = -ENOBUFS;
1236                         break;
1237                 }
1238                 msf = memdup_sockptr(optval, optlen);
1239                 if (IS_ERR(msf)) {

			...

1250                 if (IP_MSFILTER_SIZE(msf->imsf_numsrc) > optlen) {
1251                         kfree(msf);
1252                         err = -EINVAL;
1253                         break;
1254                 }
1255                 err = ip_mc_msfilter(sk, msf, 0);
1256                 kfree(msf);
1257                 break;
1258         }

Thanks
--
Gustavo