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: <CAM0EoMm5ruiBfJC1C+Jvz=vuKz03e_KOS_jgbS7ETkSfV-SKDA@mail.gmail.com> Date: Wed, 27 Dec 2023 12:33:57 -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 On Wed, Dec 27, 2023 at 12:02 PM Jamal Hadi Salim <jhs@...atatu.com> wrote: > > On Mon, Dec 25, 2023 at 8:39 PM Lin Ma <linma@....edu.cn> wrote: > > > > 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. > > > > Sorry, still trying to follow your reasoning that this is a "net issue": > As you point out, the skb will have enough space to carry the 32 bit > value. Worst case is we read garbage. And the dump, using this garbage > chain index, will not find the chain or will find some unintended > chain. Am i missing something? > > Can you send me a repro (privately) that actually causes the "heap > data leak" if you have one? > To clarify what triggered me is your tie of this as an exploit and quoting CVEs. Maybe not so much net vs net-next. cheers, jamal > cheers, > jamal > > > > > cheers, > > > jamal > > > > > > > Regards > > Lin
Powered by blists - more mailing lists