[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1b805e3-af05-45a7-8094-136b0247db9c@t-8ch.de>
Date: Wed, 22 Jan 2025 22:40:54 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Andrew Lunn <andrew@...n.ch>
Cc: Richard Cochran <richardcochran@...il.com>,
Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, John Stultz <john.stultz@...aro.org>,
Arnd Bergmann <arnd@...db.de>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH net] ptp: Ensure info->enable callback is always set
On 2025-01-22 21:15:50+0100, Andrew Lunn wrote:
> On Wed, Jan 22, 2025 at 07:39:31PM +0100, Thomas Weißschuh wrote:
> > The ioctl and sysfs handlers unconditionally call the ->enable callback.
> > Not all drivers implement that callback, leading to NULL dereferences.
> > Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.
>
> > + if (!ptp->info->enable)
> > + ptp->info->enable = ptp_enable;
>
> Is it possible that a driver has defined info as a const, and placed
> it into read only memory? It is generally good practice to make
> structures of ops read only to prevent some forms of attack.
The modified info struct is a subsystem-private copy and not the struct
passed by the driver. Also ptp_clock_register() requires a mutable
ops struct parameter anyways.
Powered by blists - more mailing lists