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
| ||
|
Message-ID: <CAM0EoMm8F3UE3N-PBZmJHQpYYjiV23JKf6jGsvzzWs0PBd+AWQ@mail.gmail.com> Date: Mon, 25 Dec 2023 18:04:14 -0500 From: Jamal Hadi Salim <jhs@...atatu.com> To: Lin Ma <linma@....edu.cn> Cc: xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH net v1] net/sched: cls_api: complement tcf_tfilter_dump_policy Hi, On Sun, Dec 24, 2023 at 11:54 AM Lin Ma <linma@....edu.cn> wrote: > > In function `tc_dump_tfilter`, the attributes array is parsed via > tcf_tfilter_dump_policy which only describes TCA_DUMP_FLAGS. However, > the NLA TCA_CHAIN is also accessed with `nla_get_u32`. According to the > commit 5e2424708da7 ("xfrm: add forgotten nla_policy for > XFRMA_MTIMER_THRESH"), such a missing piece could lead to a potential > heap data leak. > Can you clarify what "heap data leak" you are referring to? As much as i can see any reference to NLA_TCA_CHAIN is checked for presence before being put to use. So far that reason I dont see how this patch qualifies as "net". It looks like an enhancement to me which should target net-next, unless i am missing something obvious. cheers, jamal > The access to TCA_CHAIN is introduced in commit 5bc1701881e3 ("net: > sched: introduce multichain support for filters") and no nla_policy is > provided for parsing at that point. Later on, tcf_tfilter_dump_policy is > introduced in commit f8ab1807a9c9 ("net: sched: introduce terse dump > flag") while still ignoring the fact that TCA_CHAIN needs a check. This > patch does that by complementing the policy. > > Note that other functions that access TCA_CHAIN, like tc_new_tfilter, > are not vulnerable as they choose rtm_tca_policy as the parsing policy > which describes the TCA_CHAIN already. > > Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters") > Signed-off-by: Lin Ma <linma@....edu.cn> > --- > net/sched/cls_api.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c > index 1976bd163986..2b5b8eca2ee3 100644 > --- a/net/sched/cls_api.c > +++ b/net/sched/cls_api.c > @@ -2732,6 +2732,7 @@ static bool tcf_chain_dump(struct tcf_chain *chain, struct Qdisc *q, u32 parent, > } > > static const struct nla_policy tcf_tfilter_dump_policy[TCA_MAX + 1] = { > + [TCA_CHAIN] = { .type = NLA_U32 }, > [TCA_DUMP_FLAGS] = NLA_POLICY_BITFIELD32(TCA_DUMP_FLAGS_TERSE), > }; > > -- > 2.17.1 >
Powered by blists - more mailing lists