[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241011125726.62c5dde7@kernel.org>
Date: Fri, 11 Oct 2024 12:57:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: 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>, <tglx@...utronix.de>, <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 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.
Powered by blists - more mailing lists