Zero-initialize the dump struct before selective assignment to avoid
leaking stack padding in netlink replies. This matches other actions
(e.g. act_connmark) that zero-init their dump structs.
Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moses <p@1g4.org>
---
net/sched/act_gate.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
index c1f75f2727576..aacd57e5f4374 100644
--- a/net/sched/act_gate.c
+++ b/net/sched/act_gate.c
@@ -499,16 +499,16 @@ static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
{
unsigned char *b = skb_tail_pointer(skb);
struct tcf_gate *gact = to_gate(a);
- struct tc_gate opt = {
- .index = gact->tcf_index,
- .refcnt = refcount_read(&gact->tcf_refcnt) - ref,
- .bindcnt = atomic_read(&gact->tcf_bindcnt) - bind,
- };
+ struct tc_gate opt = { };
struct tcfg_gate_entry *entry;
struct tcf_gate_params *p;
struct nlattr *entry_list;
struct tcf_t t;
+ opt.index = gact->tcf_index;
+ opt.refcnt = refcount_read(&gact->tcf_refcnt) - ref;
+ opt.bindcnt = atomic_read(&gact->tcf_bindcnt) - bind;
+
spin_lock_bh(&gact->tcf_lock);
opt.action = gact->tcf_action;
--
2.52.GITOn Wed, Jan 21, 2026 at 2:20 PM Paul Moses <p@1g4.org> wrote:
>
> Zero-initialize the dump struct before selective assignment to avoid
> leaking stack padding in netlink replies. This matches other actions
> (e.g. act_connmark) that zero-init their dump structs.
>
> Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> Cc: stable@vger.kernel.org
> Signed-off-by: Paul Moses <p@1g4.org>
> ---
I do not see a bug to fix, current code is fine.
act_connmark problem was that "struct tc_connmark" had a 16bit hole.
No such issue for struct tc_gate.
Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
>
> > Zero-initialize the dump struct before selective assignment to avoid
> > leaking stack padding in netlink replies. This matches other actions
> > (e.g. act_connmark) that zero-init their dump structs.
> >
> > Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Paul Moses p@1g4.org
> > ---
>
>
> I do not see a bug to fix, current code is fine.
>
> act_connmark problem was that "struct tc_connmark" had a 16bit hole.
>
> No such issue for struct tc_gate.
On Wed, Jan 21, 2026 at 2:39 PM Paul Moses <p@1g4.org> wrote:
>
> Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
>
These bytes are cleared by C compilers.
https://en.cppreference.com/w/c/language/struct_initialization.html
Only holes might be left uninitialized.
> On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> >
> >
> > On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
> >
> > > Zero-initialize the dump struct before selective assignment to avoid
> > > leaking stack padding in netlink replies. This matches other actions
> > > (e.g. act_connmark) that zero-init their dump structs.
> > >
> > > Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Paul Moses p@1g4.org
> > > ---
> >
> >
> > I do not see a bug to fix, current code is fine.
> >
> > act_connmark problem was that "struct tc_connmark" had a 16bit hole.
> >
> > No such issue for struct tc_gate.
padding? why does fzero-init-padding-bits exist?
On Wednesday, January 21st, 2026 at 7:48 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> On Wed, Jan 21, 2026 at 2:39 PM Paul Moses p@1g4.org wrote:
>
> > Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
>
>
> These bytes are cleared by C compilers.
>
> https://en.cppreference.com/w/c/language/struct_initialization.html
>
> Only holes might be left uninitialized.
>
> > On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet edumazet@google.com wrote:
> >
> > > On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
> > >
> > > > Zero-initialize the dump struct before selective assignment to avoid
> > > > leaking stack padding in netlink replies. This matches other actions
> > > > (e.g. act_connmark) that zero-init their dump structs.
> > > >
> > > > Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Paul Moses p@1g4.org
> > > > ---
> > >
> > > I do not see a bug to fix, current code is fine.
> > >
> > > act_connmark problem was that "struct tc_connmark" had a 16bit hole.
> > >
> > > No such issue for struct tc_gate.
On Wed, Jan 21, 2026 at 3:01 PM Paul Moses <p@1g4.org> wrote:
>
> padding? why does fzero-init-padding-bits exist?
>
Which padding are you referring to?
$ pahole -C tc_gate --hex net/sched/act_gate.o
struct tc_gate {
__u32 index; /* 0 0x4 */
__u32 capab; /* 0x4 0x4 */
int action; /* 0x8 0x4 */
int refcnt; /* 0xc 0x4 */
int bindcnt; /* 0x10 0x4 */
/* size: 20, cachelines: 1, members: 5 */
/* last cacheline: 20 bytes */
};
I see no padding.
>
>
>
> On Wednesday, January 21st, 2026 at 7:48 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> >
> >
> > On Wed, Jan 21, 2026 at 2:39 PM Paul Moses p@1g4.org wrote:
> >
> > > Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
> >
> >
> > These bytes are cleared by C compilers.
> >
> > https://en.cppreference.com/w/c/language/struct_initialization.html
> >
> > Only holes might be left uninitialized.
> >
> > > On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet edumazet@google.com wrote:
> > >
> > > > On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
> > > >
> > > > > Zero-initialize the dump struct before selective assignment to avoid
> > > > > leaking stack padding in netlink replies. This matches other actions
> > > > > (e.g. act_connmark) that zero-init their dump structs.
> > > > >
> > > > > Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Paul Moses p@1g4.org
> > > > > ---
> > > >
> > > > I do not see a bug to fix, current code is fine.
> > > >
> > > > act_connmark problem was that "struct tc_connmark" had a 16bit hole.
> > > >
> > > > No such issue for struct tc_gate.
Was looking at tcfg_gate_entry and tcf_gate along with this instance of nla_put, but I can't find my notes and I don't see the path currently. Like I said, remove it, I don't care.
if (nla_put(skb, TCA_GATE_PARMS, sizeof(opt), &opt))
goto nla_put_failure;
I have months invested into the UAF though and only just in the past 24 hours was able to stabilize into user space, so no effort whatsoever has been put into defeating kaslr or anything requiring infoleak.
Look forward to more input on the much larger issue at hand.
Thanks
Paul
On Wednesday, January 21st, 2026 at 8:03 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> On Wed, Jan 21, 2026 at 3:01 PM Paul Moses p@1g4.org wrote:
>
> > padding? why does fzero-init-padding-bits exist?
>
>
> Which padding are you referring to?
>
> $ pahole -C tc_gate --hex net/sched/act_gate.o
> struct tc_gate {
> __u32 index; /* 0 0x4 /
> __u32 capab; / 0x4 0x4 /
> int action; / 0x8 0x4 /
> int refcnt; / 0xc 0x4 /
> int bindcnt; / 0x10 0x4 /
>
> / size: 20, cachelines: 1, members: 5 /
> / last cacheline: 20 bytes */
> };
>
> I see no padding.
>
> > On Wednesday, January 21st, 2026 at 7:48 AM, Eric Dumazet edumazet@google.com wrote:
> >
> > > On Wed, Jan 21, 2026 at 2:39 PM Paul Moses p@1g4.org wrote:
> > >
> > > > Yes, it's not proven so you might be right, I knew it was 4 bytes at best. We can do next or toss it, I don't feel strongly either way.
> > >
> > > These bytes are cleared by C compilers.
> > >
> > > https://en.cppreference.com/w/c/language/struct_initialization.html
> > >
> > > Only holes might be left uninitialized.
> > >
> > > > On Wednesday, January 21st, 2026 at 7:25 AM, Eric Dumazet edumazet@google.com wrote:
> > > >
> > > > > On Wed, Jan 21, 2026 at 2:20 PM Paul Moses p@1g4.org wrote:
> > > > >
> > > > > > Zero-initialize the dump struct before selective assignment to avoid
> > > > > > leaking stack padding in netlink replies. This matches other actions
> > > > > > (e.g. act_connmark) that zero-init their dump structs.
> > > > > >
> > > > > > Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
> > > > > > Cc: stable@vger.kernel.org
> > > > > > Signed-off-by: Paul Moses p@1g4.org
> > > > > > ---
> > > > >
> > > > > I do not see a bug to fix, current code is fine.
> > > > >
> > > > > act_connmark problem was that "struct tc_connmark" had a 16bit hole.
> > > > >
> > > > > No such issue for struct tc_gate.
On Wed, Jan 21, 2026 at 4:26 PM Paul Moses <p@1g4.org> wrote: > > Was looking at tcfg_gate_entry and tcf_gate along with this instance of nla_put, but I can't find my notes and I don't see the path currently. Like I said, remove it, I don't care. > > if (nla_put(skb, TCA_GATE_PARMS, sizeof(opt), &opt)) > goto nla_put_failure; To be clear : we have the same pattern in a dozen of net/sched/act_*c files. syzbot already found the problematic ones : - net/sched/act_ife.c - net/sched/act_connmark.c - net/sched/act_ct.c - net/sched/act_skbmod.c We already checked all other files. Unless another maintainer proves me wrong, let's remove this patch from your series. > > > I have months invested into the UAF though and only just in the past 24 hours was able to stabilize into user space, so no effort whatsoever has been put into defeating kaslr or anything requiring infoleak. > > Look forward to more input on the much larger issue at hand. Sure, thanks for working on this.
© 2016 - 2026 Red Hat, Inc.