Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Jakub Kicinski]

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.

Re: [PATCH v5 RESEND 0/2] posix-clock: Fix missing timespec64 check for PTP clock

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 9 Oct 2024 15:23:00 +0800 you wrote:
> Check timespec64 in pc_clock_settime() for PTP clock as
> the man manual of clock_settime() said.
> 
> Changes in v5 resend:
> - Add Acked-by.
> - Also Cc John Stultz.
> 
> [...]

Here is the summary with links:
  - [v5,RESEND,1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()
    https://git.kernel.org/netdev/net/c/d8794ac20a29
  - [v5,RESEND,2/2] net: lan743x: Remove duplicate check
    https://git.kernel.org/netdev/net/c/ea531dc66e27

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Thomas Gleixner]

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

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Jakub Kicinski]

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.

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Thomas Gleixner]

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

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH v5 RESEND 1/2] posix-clock: Fix missing timespec64 check in pc_clock_settime()

[Anna-Maria Behnsen]

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