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

Message-ID: <247c158b-f1d3-1bba-b2fa-1d741a566837@huaweicloud.com>
Date:   Fri, 18 Aug 2023 11:24:55 +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 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.