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