Re: [PATCH net v1] net/sched: cls_api: complement tcf_tfilter_dump_policy

["Lin Ma" <linma@zju.edu.cn>]

Hello Jamal,

> 
> 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.
> 

Sure, thanks for your reply, (and merry Christmas :D).
I didn't mention the detail as I consider the commit message in
`5e2424708da7` could make a point. In short, the code

```
if (tca[TCA_CHAIN] && nla_get_u32(tca[TCA_CHAIN])
```

only checks if the attribute TCA_CHAIN exists but never checks about
the attribute length because that attribute is parsed by the function
nlmsg_parse_deprecated which will parse an attribute even not described
in the given policy (here, the tcf_tfilter_dump_policy).

Moreover, the netlink message is allocated via netlink_alloc_large_skb
(see net/netlink/af_netlink.c) that does not clear out the heap buffer.
Hence a malicious user could send a malicious TCA_CHAIN attribute here
without putting any payload and the above `nla_get_u32` could dereference
a dirty data that is sprayed by the user.

Other place gets TCA_CHAIN with provide policy rtm_tca_policy that has a
description.

```
[TCA_CHAIN]		= { .type = NLA_U32 },
```

and this patch aims to do so.

Unfortunately, I have not opened the exploit for CVE-2023-3773
(https://access.redhat.com/security/cve/cve-2023-3773) yet but the idea
is similar and you can take it as an example.

> cheers,
> jamal
> 

Regards
Lin