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

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

[Jinjie Ruan]

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.

Changes in v5:
- Use timespec64_valid_strict() instead of timespec64_valid()
  as Thomas suggested.
- Add fix tag.
- Update the commit message.

Changes in v4:
- Check it in pc_clock_settime() for PTP clock.
- Update the commit message.

Changes in v3:
- Check it before call clock_set().
- Update the commit message.

Jinjie Ruan (2):
  posix-clock: Fix missing timespec64 check in pc_clock_settime()
  net: lan743x: Remove duplicate check

 drivers/net/ethernet/microchip/lan743x_ptp.c | 35 ++++++++------------
 kernel/time/posix-clock.c                    |  3 ++
 2 files changed, 17 insertions(+), 21 deletions(-)

-- 
2.34.1

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

[Jinjie Ruan]

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

[PATCH v5 RESEND 2/2] net: lan743x: Remove duplicate check

[Jinjie Ruan]

Since timespec64_valid() has been checked in higher layer
pc_clock_settime(), the duplicate check in lan743x_ptpci_settime64()
can be removed.

Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v5-> resend
- Add Acked-by.
- Also Cc John Stultz.
v4:
- Update the commit message.
v2:
- Check it in ptp core instead of using NSEC_PER_SEC macro.
- Remove the NULL check.
---
 drivers/net/ethernet/microchip/lan743x_ptp.c | 35 ++++++++------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan743x_ptp.c b/drivers/net/ethernet/microchip/lan743x_ptp.c
index dcea6652d56d..4a777b449ecd 100644
--- a/drivers/net/ethernet/microchip/lan743x_ptp.c
+++ b/drivers/net/ethernet/microchip/lan743x_ptp.c
@@ -401,28 +401,21 @@ static int lan743x_ptpci_settime64(struct ptp_clock_info *ptpci,
 	u32 nano_seconds = 0;
 	u32 seconds = 0;
 
-	if (ts) {
-		if (ts->tv_sec > 0xFFFFFFFFLL ||
-		    ts->tv_sec < 0) {
-			netif_warn(adapter, drv, adapter->netdev,
-				   "ts->tv_sec out of range, %lld\n",
-				   ts->tv_sec);
-			return -ERANGE;
-		}
-		if (ts->tv_nsec >= 1000000000L ||
-		    ts->tv_nsec < 0) {
-			netif_warn(adapter, drv, adapter->netdev,
-				   "ts->tv_nsec out of range, %ld\n",
-				   ts->tv_nsec);
-			return -ERANGE;
-		}
-		seconds = ts->tv_sec;
-		nano_seconds = ts->tv_nsec;
-		lan743x_ptp_clock_set(adapter, seconds, nano_seconds, 0);
-	} else {
-		netif_warn(adapter, drv, adapter->netdev, "ts == NULL\n");
-		return -EINVAL;
+	if (ts->tv_sec > 0xFFFFFFFFLL) {
+		netif_warn(adapter, drv, adapter->netdev,
+			   "ts->tv_sec out of range, %lld\n",
+			   ts->tv_sec);
+		return -ERANGE;
+	}
+	if (ts->tv_nsec < 0) {
+		netif_warn(adapter, drv, adapter->netdev,
+			   "ts->tv_nsec out of range, %ld\n",
+			   ts->tv_nsec);
+		return -ERANGE;
 	}
+	seconds = ts->tv_sec;
+	nano_seconds = ts->tv_nsec;
+	lan743x_ptp_clock_set(adapter, seconds, nano_seconds, 0);
 
 	return 0;
 }
-- 
2.34.1

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