Re: [PATCH v2] pps: Don't try to wait for negative timeouts in PPS_FETCH

[Rodolfo Giometti <giometti@enneenne.com>]

On 12/06/2026 20:52, Calvin Owens wrote:
> If userspace passes a negative timeout to PPS_FETCH, it triggers a
> kernel splat from schedule_timeout():
> 
>      schedule_timeout: wrong timeout value fffffffffff0bfb4
>      CPU: 17 UID: 0 PID: 4720 Comm: a.out Not tainted 7.1.0-rc5-x86-kvm-00150-g331d97e36b37 #1 PREEMPT_RT
>      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-20240910_120124-localhost 04/01/2014
>      Call Trace:
>       <TASK>
>       dump_stack_lvl+0x4b/0x70
>       schedule_timeout+0xb7/0xe0
>       pps_cdev_pps_fetch.isra.0+0x93/0x150
>       pps_cdev_ioctl+0x70/0x310
>       __x64_sys_ioctl+0x7b/0xc0
>       do_syscall_64+0xb6/0xfc0
>       entry_SYSCALL_64_after_hwframe+0x4b/0x53
> 
> Here is a trivial reproducer that works with the PPS_CLIENT_KTIMER test
> device enabled in the kernel:
> 
>      #include <stdlib.h>
>      #include <fcntl.h>
>      #include <unistd.h>
>      #include <sys/ioctl.h>
>      #include <linux/pps.h>
>      #include <err.h>
> 
>      int main() {
>          struct pps_fdata fdata;
>          int fd;
> 
>          fd = open("/dev/pps0", O_RDWR);
>          if (fd == -1)
>              err(1, "Failed to open /dev/pps0");
> 
>          fdata.timeout.sec = -1;
>          fdata.timeout.nsec = 0;
> 
>          if (ioctl(fd, PPS_FETCH, &fdata))
>              err(2, "PPS_FETCH failed");
> 
>          close(fd);
>          return 0;
>      }
> 
> Sashiko imagines this to be some sort of security problem, which is
> obviously really silly. But I think it is still worth fixing, so buggy
> userspace code can't trigger the splat.
> 
> Silence the splat by using timespec64_to_jiffies(), which hard limits
> the timeout to LONG_MAX jiffies. To be safe, explicitly preserve the
> -ETIMEDOUT return value userspace sees today if it passes a negative
> timeout.
> 
> If you really squint, this is still a slight behavior change in that
> there are "denormalized" combinations of tv_sec and tv_nsec which used
> to work but will now return -ETIMEDOUT. I can't imagine anybody will
> care about that...
> 
> Fixes: eae9d2ba0cfc ("LinuxPPS: core support")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=3
> Signed-off-by: Calvin Owens <calvin@wbinvd.org>

Acked-by: Rodolfo Giometti <giometti@enneenne.com>

> ---
> Changes in v2:
> * Explicitly check that tv_sec is non-negative [Rodolfo]
> * Use timespec64_to_jiffies() instead of open coding tick math [Rodolfo]
> 
> (I dropped the RT people/lists in v2 because I realized get_maintainer
> was only including them due to "PREEMPT_RT" in the pasted trace.)
> 
> v1: https://lore.kernel.org/lkml/b5241c09ac0dfb82ee076d06367ac6319471c773.1780071212.git.calvin@wbinvd.org/
> 
>   drivers/pps/pps.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
> index de1122bb69ea..7ecdd774a44b 100644
> --- a/drivers/pps/pps.c
> +++ b/drivers/pps/pps.c
> @@ -66,13 +66,19 @@ static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
>   		err = wait_event_interruptible(pps->queue,
>   				ev != pps->last_ev);
>   	else {
> +		struct timespec64 ts;
>   		unsigned long ticks;
>   
>   		dev_dbg(&pps->dev, "timeout %lld.%09d\n",
>   				(long long) fdata->timeout.sec,
>   				fdata->timeout.nsec);
> -		ticks = fdata->timeout.sec * HZ;
> -		ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
> +
> +		if (fdata->timeout.sec < 0)
> +			return -ETIMEDOUT;
> +
> +		ts.tv_sec = fdata->timeout.sec;
> +		ts.tv_nsec = fdata->timeout.nsec;
> +		ticks = timespec64_to_jiffies(&ts);
>   
>   		if (ticks != 0) {
>   			err = wait_event_interruptible_timeout(


-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming