Message-ID: <60f44b58-fad9-4d73-a355-70f87662ea7c@mojatatu.com>
Date: Mon, 30 Jun 2025 15:50:13 -0300
From: Victor Nogueira <victor@...atatu.com>
To: Jamal Hadi Salim <jhs@...atatu.com>, Mingi Cho <mgcho.minic@...il.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>, security@...nel.org,
 Jiri Pirko <jiri@...nulli.us>,
 Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Use-after-free in Linux tc subsystem (v6.15)

> On Thu, Jun 26, 2025 at 1:11 AM Mingi Cho <mgcho.minic@...il.com> wrote:
>>
>> On Fri, Jun 20, 2025 at 8:24 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>>>
>>> On Wed, Jun 18, 2025 at 4:17 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>>>>
>>>> On Mon, Jun 16, 2025 at 9:03 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>>>>>
>>>>> On Sun, Jun 15, 2025 at 10:02 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>>>>>>
>>>>>> On Thu, Jun 12, 2025 at 2:18 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>>>>>>>
>>>>>>> Hi Mingi,
>>>>>>>
>>>>>>> Thanks for your report!
>>>>>>>
>>>>>>> I won't have time to look into this until this Sunday, if you or
>>>>>>> anyone else have
>>>>>>> time before that, please feel free to work on a patch. Otherwise, I will take a
>>>>>>> look this Sunday.
>>>>>>
>>>>>> I am testing the attached patch, I will take a deeper look tomorrow.
>>>>>
>>>>> It is more complicated than I thought. I think we need to rollback all
>>>>> the previous enqueue operations, but it does not look pretty either.
>>>>>
>>>>> Jamal, do you like the attached fix? I don't have any better ideas
>>>>> so far. :-/
>>>>>
>>>>
>>>> I just got back - let me look at it tomorrow. Immediate reaction is i
>>>> would suspect netem
>>>
>>> Spent time yesterday and there are two potential approaches
>>> (attached), both of which fix the issue but i am not satisfied with
>>> either.
>>>
>>> The root cause being exploited here is there are some qdisc's whose
>>> peek() drops packets - but given peek() doesnt return a code, the
>>> parent is unaware of what happened.
>>>
>>> drr_fix.diff
>>> avoids making a class active  by detecting whether drr_qlen_notify was
>>> called between after enqueue (even though that enqueue succeeded), in
>>> that case, returns a NET_XMIT_SUCCESS | __NET_XMIT_BYPASS which ensure
>>> we don't add the class to drr.
>>>
>>> This fixes the UAF but it would require an analogous fix for other
>>> qdiscs with similar behavior (ets, hfsc, ...)
>>>
>>> qfq_netem_child_fix.diff
>>> piggy backs on your tbf patch and detects whether
>>> qdisc_tree_reduce_backlog was called after qfq's peeked its child
>>> (netem in this repro) in enqueue.
>>> This would also require fixing other qdiscs.
>>>
>>> TBH, while both approaches fix the UAF, IMO they are short term hacks
>>> and i am sure Mingi and co will find yet another way to send netlink
>>> messages to config a _nonsensical hierarchy of qdiscs_ (as was this
>>> one!) to create yet another UAF.
>>>
>>> My suggestion is we go back to a proposal i made a few moons back:
>>> create a mechanism to disallow certain hierarchies of qdiscs, ex in
>>> this case disallow qfq from being the ancestor of "qdiscs that may
>>> drop during peek" (such as netem). Then we can just keep adding more
>>> "disallowed configs" that will be rejected via netlink.
>>> And TBH, i feel like obsoleting qfq altogether - the author doesnt
>>> even respond to emails.
>>>
>>> cheers,
>>> jamal
>>
>> Hello,
>>
>> I think the testcase I reported earlier actually contains two
>> different bugs. The first is returning SUCCESS with an empty TBF qdisc
>> in tbf_segment, and the second is returning SUCCESS with an empty QFQ
>> qdisc in qfq_enqueue.

Mingi, can you create a selftest for the drr UAF case with a qfq child
that you reproduced? Since you required setsockopt for creating GSO
packets, I don't believe you'll be able to use tdc for this.

Powered by blists - more mailing lists