linux-hardening - Re: [netfilter-nf-next:testing 2/9] ./usr/include/linux/netfilter_bridge/ebtables.h:163:26: warning: field 'target' with variable sized type 'struct ebt_entry_target' not at the end of a struct or class is a GNU extension

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]

Date:   Fri, 18 Aug 2023 13:23:30 +0800
From:   "GONG, Ruiqi" <gongruiqi@...weicloud.com>
To:     Kees Cook <keescook@...omium.org>, Florian Westphal <fw@...len.de>
Cc:     kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
        oe-kbuild-all@...ts.linux.dev, linux-hardening@...r.kernel.org
Subject: Re: [netfilter-nf-next:testing 2/9]
 ./usr/include/linux/netfilter_bridge/ebtables.h:163:26: warning: field
 'target' with variable sized type 'struct ebt_entry_target' not at the end of
 a struct or class is a GNU extension



On 2023/08/18 11:24, GONG, Ruiqi wrote:
> 
> 
> On 2023/08/18 1:02, Kees Cook wrote:
>> On Thu, Aug 17, 2023 at 10:26:18AM +0200, Florian Westphal wrote:
>>> Kees Cook <keescook@...omium.org> wrote:
>>>> On Thu, Aug 17, 2023 at 01:03:20PM +0800, kernel test robot wrote:
>>>>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git testing
>>>>> head:   015e2d9101d3713c7bee16dccad171df04a3bbd5
>>>>> commit: 61b9e6bd48a6317c0a44ee4f3fecdec9de5baa9e [2/9] netfilter: ebtables: replace zero-length array members
>>>>> config: i386-buildonly-randconfig-r004-20230817 (https://download.01.org/0day-ci/archive/20230817/202308171249.g1ywxhII-lkp@intel.com/config)
>>>>> compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
>>>>> reproduce: (https://download.01.org/0day-ci/archive/20230817/202308171249.g1ywxhII-lkp@intel.com/reproduce)
>>>>>
>>>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>>>> the same patch/commit), kindly add following tags
>>>>> | Reported-by: kernel test robot <lkp@...el.com>
>>>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202308171249.g1ywxhII-lkp@intel.com/
>>>>>
>>>>> All warnings (new ones prefixed by >>):
>>>>>
>>>>>    In file included from <built-in>:1:
>>>>>>> ./usr/include/linux/netfilter_bridge/ebtables.h:163:26: warning: field 'target' with variable sized type 'struct ebt_entry_target' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
>>>>>            struct ebt_entry_target target;
>>>>>                                    ^
>>>>>    1 warning generated.
>>>>
>>>> Eww, it looks like "struct ebt_entry_target" is used _within_ another
>>>> struct:
>>>>
>>>> struct ebt_standard_target {
>>>>         struct ebt_entry_target target;
>>>>         int verdict;
>>>> };
>>>
>>> Yes, same as xt_standard_target.
>>>
>>>> These have been fixed in the past in a variety of ways -- it all depends
>>>> on how userspace is using them. In looking at Debian Code Search:
>>>> https://codesearch.debian.net/search?q=struct+ebt_standard_target&literal=1
>>>>
>>>> It is exclusively doing casts and looking at the "verdict" member. So
>>>> the easiest conversion might be this:
>>>>
>>>>  struct ebt_standard_target {
>>>> -       struct ebt_entry_target target;
>>>> +       unsigned char hdr[sizeof(struct ebt_entry_target)];
>>>>         int verdict;
>>>
>>> I don't think its worth doing all of this.
>>>
>>> Can't we just keep it as-is and drop the relevant hunk from the patch?
>>
>> For now, yeah. But we'll need to find a solution as flex-array
>> structures overlapping variables is considered deprecated (it can lead
>> to ambiguous sizing results). But as long as the kernel itself doesn't
>> use struct ebt_standard_target, we can kick the can down the road a bit
>> more. :)
>>
> 
> I agree that we can complete the whole transformation step-by-step. I
> will make another patch without the problematic replacement.

I didn't notice that the patch had been modified and merged into
nf-next's testing branch. Let's use that and I won't send another one.
Thanks Florian! XD