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.
Cc: stable@vger.kernel.org
Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks")
Acked-by: Richard Cochran <richardcochran@gmail.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v5 -> resend
- Add Acked-by.
- Also Cc John Stultz.
v5:
- Update the commit message.
- Use timespec64_valid_strict() instead of timespec64_valid()
as Thomas suggested.
- Add fix tag.
v4:
- Check it in pc_clock_settime().
- Update the commit message.
v3:
- Adjust to check in more higher layer clock_settime().
- Remove the NULL check.
- Update the commit message and subject.
v2:
- Adjust to check in ptp_clock_settime().
---
kernel/time/posix-clock.c | 3 +++
1 file changed, 3 insertions(+)
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
--
2.34.1
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
Hi! > >> > 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. It is no good :-( and it is now in stable. It needs to goto out in the error case, to permit cleanups. Best regards, Pavel +++ b/kernel/time/posix-clock.c @@ -312,6 +312,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 -- People of Russia, stop Putin before his war on Ukraine escalates.
Pavel Machek <pavel@ucw.cz> writes: > Hi! > >> >> > 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. > > It is no good :-( and it is now in stable. > > It needs to goto out in the error case, to permit cleanups. The check needs to be done before taking the lock. There is already a patch around which solves it: https://lore.kernel.org/r/20241018100748.706462-1-ruanjinjie@huawei.com/ Thanks, Anna-Maria
© 2016 - 2024 Red Hat, Inc.