netdev - Re: [PATCH -next v3 1/2] posix-timers: Check timespec64 before call clock

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: <87r09ra4st.ffs@tglx>
Date: Tue, 10 Sep 2024 17:48:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Jinjie Ruan <ruanjinjie@...wei.com>, Richard Cochran
 <richardcochran@...il.com>
Cc: bryan.whitehead@...rochip.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, anna-maria@...utronix.de,
 frederic@...nel.org, UNGLinuxDriver@...rochip.com, mbenes@...e.cz,
 jstultz@...gle.com, andrew@...n.ch, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next v3 1/2] posix-timers: Check timespec64 before call
 clock_set()

On Tue, Sep 10 2024 at 20:30, Jinjie Ruan wrote:
> On 2024/9/10 20:05, Thomas Gleixner wrote:
>> Can you please stop this handwaving and provide proper technical
>> arguments?
>> 
>> Why would PTP have less strict requirements than settimeofday()?
>
> I checked all the PTP driver, most of them use timespec64_to_ns()
> convert them to ns which already have a check, but the others not check
> them, and lan743x_ptp check them differently and more, so i think this
> is a minimum check.

It does not matter at all what the PTP drivers do. What matters is what
is correct and what not.

What they do is actually wrong as they simply cut off an overly large
value instead of rejecting it in the first place. That's not a check at
all.

The cutoff in timespec64_to_ns() is there to saturate the result instead
of running into a multiplication overflow. That's correct for some use
cases, but not a replacement for an actual useful range check.

This is about correctness and correctness is not defined by what a bunch
of drivers implement which are all a big copy & pasta orgy.

Thanks,

        tglx