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

On Sat, Sep 14 2024 at 18:06, 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 mannul of clock_settime() said, if tp.tv_sec is negative or
> tp.tv_nsec is outside the range [0..999,999,999], it shuld return EINVAL,
> which include Dynamic clocks which handles PTP clock, and the condition is
> consistent with timespec64_valid(). So check it ahead using
> timespec64_valid() 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.
  
> +	if (!timespec64_valid(ts))
> +		return -EINVAL;

This just makes sure, that the timespec is valid. But it does not ensure
that the time is in a valid range.

This should at least use timespec64_valid_strict() if not
timespec64_valid_gettod().

Thanks,

        tglx