netdev - Re: [PATCH] don't assume the existence of skb->dev when trying to reset ip_options in ipv4_send_dest

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: <ecde5e34c6f3a8182f588b3c1352bf78b69ff206.camel@redhat.com>
Date: Thu, 07 Sep 2023 13:03:52 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Kyle Zeng <zengyhkyle@...il.com>, davem@...emloft.net,
 dsahern@...nel.org,  netdev@...r.kernel.org
Cc: ssuryaextr@...il.com
Subject: Re: [PATCH] don't assume the existence of skb->dev when trying to
 reset ip_options in ipv4_send_dest_unreach

On Wed, 2023-09-06 at 19:43 -0700, Kyle Zeng wrote:
> Currently, we assume the skb is associated with a device before calling __ip_options_compile, which is not always the case if it is re-routed by ipvs.
> When skb->dev is NULL, dev_net(skb->dev) will become null-dereference.
> Since we know that all the options will be set to IPOPT_END, which does
> not depend on struct net, we pass NULL to it.

It's not clear to me why we can infer the above. Possibly would be more
safe to skip entirely the __ip_options_compile() call?!?

Please at least clarify the changelog and trim it to 72 chars. 

Additionally trim the subj to the same len and include the target tree
(net) into the subj prefix.

Thanks!

Paolo