| 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
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
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
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
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(+)