linux-kernel - Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_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: <87v7xtc7z5.ffs@tglx>
Date: Wed, 16 Oct 2024 00:33:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Jakub Kicinski <kuba@...nel.org>, Jinjie Ruan <ruanjinjie@...wei.com>
Cc: bryan.whitehead@...rochip.com, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, anna-maria@...utronix.de, frederic@...nel.org,
 richardcochran@...il.com, johnstul@...ibm.com,
 UNGLinuxDriver@...rochip.com, jstultz@...gle.com, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check
 in pc_clock_settime()

On Fri, Oct 11 2024 at 12:57, Jakub Kicinski wrote:
> On Wed, 9 Oct 2024 15:23:01 +0800 Jinjie Ruan wrote:
>> As Andrew pointed out, it will make sense that the PTP core
>> checked timespec64 struct's tv_sec and tv_nsec range before calling
>> ptp->info->settime64().
>> 
>> As the man manual of clock_settime() said, if tp.tv_sec is negative or
>> tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
>> which include dynamic clocks which handles PTP clock, and the condition is
>> consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
>> only check the timespec is valid, but not ensure that the time is
>> in a valid range, so check it ahead using timespec64_valid_strict()
>> in pc_clock_settime() and return -EINVAL if not valid.
>> 
>> There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
>> write registers without validity checks and assume that the higher layer
>> has checked it, which is dangerous and will benefit from this, such as
>> hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
>> and some drivers can remove the checks of itself.
>
> I'm guessing we can push this into 6.12-rc and the other patch into
> net-next. I'll toss it into net on Monday unless someone objects.

Can you folks please at least wait until the maintainers of the code in
question had a look ?

Thanks,

        tglx