From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f46.google.com (mail-dl1-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FF242F7F19 for ; Sat, 30 May 2026 14:54:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780152870; cv=none; b=bBTdq1C8931P2+692WLIJtK0MMvt28vCNps+lCGHCNd+ZiHJ2cBT5VEqKPUmZtHnGfn74s8qYo2HgQANiJqH+DKzMvO1iXn7TaXJZfq++1bxSZKggQhrtQJ0GQ9zC+7jX9dB6WkRKBlTJo5nrG2MESNemX4cVTPpVP7AUKOP+ZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780152870; c=relaxed/simple; bh=e9OgB3cKziRcIeud3sL5uUcp7JEnRHS6LgQScHdXw18=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wuz7rSQUGmkpDUgWYDuEGWqozAJxMe5LBfTY0pwH26DTocRWdcJwwYSZ8HEw9rnESkyS2Cbyg7tuwFDyiYYQ2L0K2L9sFItO5nU5BhuWmstHenYlXR6o4zlQWqxvAYx9ZcuCF9kYCVFJjnxfveyH4YtPph/XkGVYcJcYheV0wWY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org; spf=pass smtp.mailfrom=wbinvd.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b=fACsvlYe; arc=none smtp.client-ip=74.125.82.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b="fACsvlYe" Received: by mail-dl1-f46.google.com with SMTP id a92af1059eb24-137d457acd4so535290c88.0 for ; Sat, 30 May 2026 07:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1780152867; x=1780757667; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GVelvg46s+KIhtR06bw6XwejyY6UiQ+q2yd6BbeS7vE=; b=fACsvlYeUlUdF8mWi3mWMHJuWgas6sJ4fQ5XF7otN+0IL0qBKhWZjJL8n6x7CFW8Np 5kqn0CrdzZZ+XheGg2lDXW5iprM3R8vSjey3tEuciVRzj4aJtNRLjYcKbLr6pmrzSjvg yabxhO3FBLbAbdUPMr2bkTCAM+F75Gmg75yDVHvZa/LPayC0IFWCT888uEoObRMNRaIJ 6PcULQ1cMDnX6rrq7NUi43OgwqgURS5GytOUz2z7+iy9ARMguQa01EWSscrNKG4DBtTV 1+J7LX0CH7SDNJvmsb2gmYunQE76Q4rJpT8ScEW7h8Ox4J02g6qJnYenvEZXaazM3Rqs Q8tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780152867; x=1780757667; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GVelvg46s+KIhtR06bw6XwejyY6UiQ+q2yd6BbeS7vE=; b=rQoWZrBw58NVs0ERoSZnZ9s4ZhNv+BDSFGRv48Jw1HhrNBgLA3Y+0jkdfG0jXdryrA tei7KVeN1FzdEoGsuNVFI5TQ6K+rp+2yWPgSWnwqrkAWHmvcF6bj0otYuZq/BK24QKGo BswYmJjvdpZj5IDBEnwKV1njTTDY2Dn5SzLEXS42yT79R6/opMkZYnLq9Jqd5axxIlwr pETdAhjy+cg1pmmmX+BjW7DZbNuWJ309YYUQkBgr0f6dCCWOMsVbc6MA8vCK539c2OhR gKRsQrO8WyyP1F1Nb6pf8xYKB8RfycTEeil369p6hHI9wzg+JdLVXeLp65UJnfcmuhwp 9Y3A== X-Gm-Message-State: AOJu0YzD9UpCqTfDl5wYNAdLdb5qdeJMpwo110gYVU/+OTPxcyqmzgnk 4CVLMACqEEcr3wLyPzPJchyi2exPNOOTJ1GPFERXF+JPfSwseszdql7PtRcsA0CVKhA= X-Gm-Gg: Acq92OG0lCv3liVJ4JGH0IuRy3W2XZoHCnbFRNX+0yjW5Ypcxv7WG4nNVxmtWjRck5C fuHGSSyTHLl8NoEHlXXSPpLMauDzP62svPX7cl78JzwUw8a8J8gjPpevX1gIA/pyMU9eCnK/tEF xD8qeeiIQGpYzcblmBapAZSgQdVAr/h923Ez2wINycTV22GwjcSMjER5hkzfJ4epi3aXp5u7wAl dPDe/iak10mWUhXJxmjy9x6HeoqmZhW1DUl3RQfpu16C2OjtB2Yt9r/x8dgYn9PW+SkSnEWd1IG 1q2b2I3R5sgeqS9sKu6Ub7SVCZEN7gAbmejQBnU1vd7x59kXzl1AfKJLlnaGzb9TP0t+eFYayAV JShPqY2GU2IivX2C0Jo+Zjlx0ixKSxhi4YTdHTzBDxe/TsMiTv2pUDSEX8CCJyRDV3OahWNKQxn ikAzlk1K9sVSgAG+8sGJtPJonkAg7Lra7Az1U= X-Received: by 2002:a05:7300:324a:b0:302:8cb5:af0b with SMTP id 5a478bee46e88-304eb1bc29amr3239498eec.13.1780152867209; Sat, 30 May 2026 07:54:27 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:5c5f:3906:b87:59dc]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304ed53d14fsm4113677eec.17.2026.05.30.07.54.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 May 2026 07:54:26 -0700 (PDT) Date: Sat, 30 May 2026 07:54:24 -0700 From: Calvin Owens To: Rodolfo Giometti Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Andrew Morton Subject: Re: [PATCH] pps: Don't try to wait for negative timeouts in PPS_FETCH Message-ID: References: <20ed84f3-14d9-4936-b6d1-915ab605b7fa@enneenne.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20ed84f3-14d9-4936-b6d1-915ab605b7fa@enneenne.com> On Saturday 05/30 at 11:50 +0200, Rodolfo Giometti wrote: > On 29/05/2026 18:21, 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: > > > > 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 > > > > 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 skipping the wait if the ticks count is negative. > > The current behavior is to return -ETIMEDOUT in that case, so keep that > > return value in case any userspace code might rely on it. > > > > Fixes: eae9d2ba0cfc ("LinuxPPS: core support") > > Reported-by: Sashiko > > Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=3 > > Signed-off-by: Calvin Owens Hi Rodolfo, Thanks for taking a look at this and the others. > > --- > > drivers/pps/pps.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c > > index de1122bb69ea..6755901fbdae 100644 > > --- a/drivers/pps/pps.c > > +++ b/drivers/pps/pps.c > > @@ -65,17 +65,19 @@ static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata) > > if (fdata->timeout.flags & PPS_TIME_INVALID) > > err = wait_event_interruptible(pps->queue, > > ev != pps->last_ev); > > else { > > - unsigned long ticks; > > + 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 (ticks != 0) { > > + if (ticks < 0) { > > + return -ETIMEDOUT; > > + } else if (ticks > 0) { > > err = wait_event_interruptible_timeout( > > pps->queue, > > ev != pps->last_ev, > > ticks); > > Should the problem originate from user-space data, I deem it more > appropriate to verify them directly, rather than relying on computed data. > > unsigned long ticks; > > if (fdata->timeout.sec < 0 || fdata->timeout.nsec < 0) > return -ETIMEDOUT; I agree your way is nicer to read. Pedantically, it's a user visable behavior change: today, the user can pass absurd values for sec and nsec, and everything works so long as the math works out to positive ticks (e.g. sec=ULONG_MAX/HZ, nsec=2*HZ*NSEC_PER_SEC). If it was just that, it wouldn't really matter IMO, but... > dev_dbg(&pps->dev, "timeout %lld.%09d\n", > (long long) fdata->timeout.sec, > fdata->timeout.nsec); > > ticks = fdata->timeout.sec * HZ; ...the multiplication by HZ could also overflow even if sec is positive, so I think userspace would still be able to trigger the splat this way. > ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ); > > if (ticks > 0) { > > Ciao, > > Rodolfo > > -- > GNU/Linux Solutions e-mail: giometti@enneenne.com > Linux Device Driver giometti@linux.it > Embedded Systems phone: +39 349 2432127 > UNIX programming