netdev - Re: [PATCH] net: mctp: fix infinite data from mctp_dump

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 for Android: free password hash cracker in your pocket

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

Message-ID: <575fa12e699f6f65b47f5b776ec91ef9c350644a.camel@codeconstruct.com.au>
Date: Sat, 07 Jun 2025 15:47:09 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Patrick Williams <patrick@...cx.xyz>, Matt Johnston
 <matt@...econstruct.com.au>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>,  Simon Horman <horms@...nel.org>, Kuniyuki
 Iwashima <kuniyu@...zon.com>, Peter Yin <peteryin.openbmc@...il.com>, 
 Andrew Jeffery <andrew@...econstruct.com.au>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: mctp: fix infinite data from mctp_dump_addrinfo

Hi Patrick,

[+CC Andrew, for openbmc kernel reasons]

> So, it seems like there's something more subtle happening here - or I
> have misunderstood something about the fix (I'm unsure of the
> reference to xa_for_each_start; for_each_netdev_dump only calls xa_start?).

Ah! Are you on the openbmc 6.6 backport perhaps?

It look the xa_for_each_start()-implementation of netdev_for_each_dump()
would not be compatible with a direct backport of 2d20773aec14 ("mctp: no
longer rely on net->dev_index_head[]").

This was the update for the for_each_netdev_dump() macro:

commit f22b4b55edb507a2b30981e133b66b642be4d13f
Author: Jakub Kicinski <kuba@...nel.org>
Date:   Thu Jun 13 14:33:16 2024 -0700

    net: make for_each_netdev_dump() a little more bug-proof

    I find the behavior of xa_for_each_start() slightly counter-intuitive.
    It doesn't end the iteration by making the index point after the last
    element. IOW calling xa_for_each_start() again after it "finished"
    will run the body of the loop for the last valid element, instead
    of doing nothing.

... which sounds like what's happening here.

Cheers,

Jeremy