Message ID | 20241009072302.1754567-2-ruanjinjie@huawei.com (mailing list archive) |
---|---|
State | Accepted |
Commit | d8794ac20a299b647ba9958f6d657051fc51a540 |
Headers | show |
Series | posix-clock: Fix missing timespec64 check for PTP clock | expand |
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.
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
On Wed, 16 Oct 2024 00:33:02 +0200 Thomas Gleixner wrote: > > 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 ? You are literally quoting the text where I say I will wait 3 more days. Unfortunately "until the maintainers respond" leads to waiting forever 50% of the time, and even when we cap at 3 working days we have 300 patches in the queue (292 right now, and I already spent 2 hours reviewing today). Hope you understand. Sorry if we applied too early, please review, I'll revert if it's no good.
On Tue, Oct 15 2024 at 16:22, Jakub Kicinski wrote: > On Wed, 16 Oct 2024 00:33:02 +0200 Thomas Gleixner wrote: >> > 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 ? > > You are literally quoting the text where I say I will wait 3 more days. > Unfortunately "until the maintainers respond" leads to waiting forever > 50% of the time, and even when we cap at 3 working days we have 300 > patches in the queue (292 right now, and I already spent 2 hours > reviewing today). Hope you understand. I understand very well, but _I_ spent the time to review the earlier variants of these patches and to debate with the submitter up to rev 5. Now you go and apply a patch to a subsystem you do not even maintain just because I did not have the bandwidth to look at it within the time limit you defined? Seriously? This problem is there for years, so a few days +/- are absolutely not relevant. > Sorry if we applied too early, please review, I'll revert if it's no > good. I assume you route it to Linus before 6.12 final. So let it applied. Thanks, tglx
diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c index c2f3d0c490d5..316a4e8c97d3 100644 --- a/kernel/time/posix-clock.c +++ b/kernel/time/posix-clock.c @@ -318,6 +318,9 @@ static int pc_clock_settime(clockid_t id, const struct timespec64 *ts) goto out; } + if (!timespec64_valid_strict(ts)) + return -EINVAL; + if (cd.clk->ops.clock_settime) err = cd.clk->ops.clock_settime(cd.clk, ts); else