linux-kernel - Re: [External] : Re: [REPORT] Null pointer deref in net/core/dev.c on PowerPC

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5da37621-279f-46ea-94e7-b766a6e601f3@oracle.com>
Date: Wed, 17 Dec 2025 21:08:24 +0530
From: ALOK TIWARI <alok.a.tiwari@...cle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Aditya Gupta <adityag@...ux.ibm.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [External] : Re: [REPORT] Null pointer deref in net/core/dev.c on
 PowerPC



On 12/17/2025 8:52 PM, Eric Dumazet wrote:
>>> I will send the following fix, thanks.
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 9094c0fb8c68..36dc5199037e 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -4241,9 +4241,11 @@ static inline int __dev_xmit_skb(struct sk_buff
>>> *skb, struct Qdisc *q,
>>>                   int count = 0;
>>>
>>>                   llist_for_each_entry_safe(skb, next, ll_list, ll_node) {
>>> -                       prefetch(next);
>>> -                       prefetch(&next->priority);
>>> -                       skb_mark_not_on_list(skb);
>>> +                       if (next) {
>>> +                               prefetch(next);
>>> +                               prefetch(&next->priority);
>>> +                               skb_mark_not_on_list(skb);
>>> +                       }
>>>                           rc = dev_qdisc_enqueue(skb, q, &to_free, txq);
>>>                           count++;
>>>                   }
>>>
>> why not only ?
>> if (likely(next)) {
>>       prefetch(next);
>>       prefetch(&next->priority);
>> }
> Because we also can avoid clearing skb->next, we know it is already NULL.
> 
> Since we pay the price of a conditional, let's amortize its cost :/

Thanks a lot for the explanation, I understand the goal of amortizing 
the cost and avoiding unnecessary writes to skb->next.
Would it make sense to add if (likely(next)) around the prefetch?

Thanks,
Alok