From nobody Mon Jun 8 14:52:35 2026 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 B190D3C1985 for ; Fri, 29 May 2026 16:21:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780071713; cv=none; b=EaSTABBl9XRjDwx3kwLuF6Hu/0c2pr1/ASMVI9a2e8T1bxj3p3encQ+zcu19w/l6JB0ysCuG2k3UEsPDbyBoNArS93dSiJnZTFLtEReBW0bCY553HVot8LiLc5zS1MB+nwz4IiJg8UUm++gb18VG6zNZ9cnopq2ITQcpwOgi4fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780071713; c=relaxed/simple; bh=G+zh2PeW4L5nDuAFsU//uPDTdR81r0tDlQPCUy9QAbU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=t5aV4cigV6CGx1XXzVRQZyJOOv9jtpumVt+s3dxMp5R5gSPpsJbRnDnWyJgQPPU1hRKBn0AG2/Tf3yghTx61fF+XesK9E9EEEolAu7L+0ETGsJ7Afdly3enbcvbRYb4FYJ+FjbgnL40aYmsL923bCtjp0oebgY7l0EG9nHAPFCM= 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=ZLMYLnBB; arc=none smtp.client-ip=74.125.82.177 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="ZLMYLnBB" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-304d8e3bb72so904711eec.1 for ; Fri, 29 May 2026 09:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1780071710; x=1780676510; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=JsOIMq9FwgDH9PGuBTd8VWOVeGL7jgAx6IFRF0AXCuQ=; b=ZLMYLnBB2y+cUK1te8hvpLqpwS5ffBi1aDudoa4OgQyjvlf5BtYS3tRVl0BSEpucS1 +kahSX4qau5hPiQLDAnp2DpExQDUhyh+e2ka3c0pyU3NeIe7Ryap5cxFnGlohj2nFPvl YNE05/LLllnSJtsg9c64C2xmG0BGOh9gsZwqP2egjKR1+zngiUX0WwKXPXeH/NDKJLRL aSCA2NMgjzAhIoZ0jwKDEjIXqLtrXtm2SdiyA1CfupwVc9id3qBED8K3BA4EJp+L+7YP ApvthZtd9oElt6uqKs91KUmCt97e7du06CuAPZV2/2wCPgpYz78V0s3V/gJG+zaOT3C9 +nBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780071710; x=1780676510; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JsOIMq9FwgDH9PGuBTd8VWOVeGL7jgAx6IFRF0AXCuQ=; b=nG6LIxVEvrOruVCxx9w9OcgFG1c7nEo1EG6iMjaS4lc7sIOIropLPOTvCMQpZxTMfc 0zZEf1+3e1kGoHfl3CD1Jk8wZZ/iUHdYXFLHAZj5Q1YJyNuHNIxvLtpZIVhF423ORksp ekMiRnRG0hh7HLIPugbJEkHvS7Bz+7Unhjb0XWeZt8+fSHZSwAamoe+VMinaXpZ6bAEL YLaA8BGwrn9lZX6+iWoLSXvYY4IhCL7kNvqg1FBNya0/asuj7cyJX1qvxhCgV4Q/lKO0 1Dmku8mfgzkaEhMuq3sqpeWSnpwb1ol/ymKZMqyYY7U5EBudJvl7xoOjOjNSSXa5k5cW jWmg== X-Gm-Message-State: AOJu0YwH0jxjq/uqMMhBrIEyCh69G0fI1LeBcDfHmvDdkOgj9e/+vUGd sIGllJN62GCQMJKVgttA0i5ZIRdSnwknz+R9If0sMIxvenOpA9uh0HapgO3Gor0AuP/90kbkZ8i LRi/h X-Gm-Gg: Acq92OGi0VyDNo3COKk0nx3nuWbGuvmiorszfB+R1lYKEINK+wTro/V2KiKuaLsIj/0 Mszh0tWooSdSb/r8YUU9QL+7gJnEzjSrWXuXpztrIl5rQCpvraC2kX6LEEgWD+/jDMGQm1CD9JX sa0/ovIWIXVHu0GK0zv2UCi2ljvDKiblrU24wgFGBshX04n9yyeMcjnz4/SJt39l3qa1XAsB8WM 0GwL73UlMeAT2aflFx25RDxqdLLQ9iaS4MDw+oPkdwL8kVWCVZ1lckWxhQfzA24b4FKlBYbB6oU B0K1EbvjdVV5wTl8OmyDYM2vNaijTwIXgm9Uv94gebRwBWqi6ljXTVuSLJWZjgwvtTBgI7ljN8S VA+x42Mda2eqgd4cfD5m2YoKtJyVAP+Ir4Y8bEvBmfvvhku1gKuq7YnIHRzTi7m/9h/h5OSymnN TM031GSqN0Wo3HjdYFcJzgIY2QdMMNvE4S0v8h X-Received: by 2002:a05:7301:2926:b0:304:630d:e4c4 with SMTP id 5a478bee46e88-304fa573c64mr248605eec.10.1780071709273; Fri, 29 May 2026 09:21:49 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:2bb2:ae86:9dbf:b82e]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304ed53f316sm1718902eec.19.2026.05.29.09.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 09:21:48 -0700 (PDT) From: Calvin Owens To: linux-kernel@vger.kernel.org Cc: linux-rt-devel@lists.linux.dev, Rodolfo Giometti , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Andrew Morton Subject: [PATCH] pps: Don't try to wait for negative timeouts in PPS_FETCH Date: Fri, 29 May 2026 09:21:43 -0700 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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-0015= 0-g331d97e36b37 #1 PREEMPT_RT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2024091= 0_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=3D3 Signed-off-by: Calvin Owens --- 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, s= truct pps_fdata *fdata) if (fdata->timeout.flags & PPS_TIME_INVALID) err =3D wait_event_interruptible(pps->queue, ev !=3D pps->last_ev); else { - unsigned long ticks; + long ticks; =20 dev_dbg(&pps->dev, "timeout %lld.%09d\n", (long long) fdata->timeout.sec, fdata->timeout.nsec); ticks =3D fdata->timeout.sec * HZ; ticks +=3D fdata->timeout.nsec / (NSEC_PER_SEC / HZ); =20 - if (ticks !=3D 0) { + if (ticks < 0) { + return -ETIMEDOUT; + } else if (ticks > 0) { err =3D wait_event_interruptible_timeout( pps->queue, ev !=3D pps->last_ev, ticks); --=20 2.47.3