From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1318F3438A6 for ; Thu, 16 Jul 2026 06:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784183686; cv=none; b=tW8SqiRA0NA0VvJMN7jR5++cPAEf4UcqDGngDP1w3Sk+R02haKg9sN7Rq0Y5/bHT4hXivmoKC/ji2BYKp/ji9rYL93228dXQrahbUel8nzIMARCDFvl0pNY2LlqAd4reGGniQ49+klVnRT2jI/piGWIh6HugtsYNFXU/uAZKKbs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784183686; c=relaxed/simple; bh=PnnQJmM+Vb9Rv/s1iaiiEijkAvAgGASoZMqyk0G+BP4=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=bQ6rzLEdI59VFUMirVmnzZe+J3Z7chydgfXakVJ+oSpB0iJt+jFghf1CSE1mzU00i3FGL/L9djjJJo7ZFzSyUw6YjccCRGDCsjOh0ZianPZzEj0qUsiJYOMiFINplp+TV49NbHq7BazQ7a50sqUhacXpHmiFLqoFoIF1rrvk9eY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=nK9ihTcv; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=j5N2mwTo; arc=none smtp.client-ip=202.12.124.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="nK9ihTcv"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="j5N2mwTo" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 027E57A016C; Thu, 16 Jul 2026 02:34:43 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Thu, 16 Jul 2026 02:34:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1784183683; x=1784270083; bh=oXPwzeGBZ3nEOUCC/DPZCDDM8HXlv42a279t7vUnp70=; b= nK9ihTcvzIwXyRoug8cdw+OLFfvg9W7ho5Epu/nnF3V10bEhRb0U4GXrS+li7Ye1 A+ubJVOtkadE5DR64kwRhCVQGENAcNtIV3wwnzijOqrtn0tOEg8brJRuEghMSp6d AF74f92ThaJYs3QWJ8IrVsok1YXgp5UZkvwA2jR2eKVEckji0vTvozrDRsvf/PUt Rs3cZVY6RtYqOHUywN/DlkmAJOsIE0lKwSOt66S/TNRbAHBYOlxB/Iaoqb3fOoud ofbeJo4LlK//va+SzU7zqPMITRpG9Nj0uxBsH1JZSppTCCGl4zopC0xOLMirLSPB bT5aNO9xLU1H8sEi+t6PVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1784183683; x= 1784270083; bh=oXPwzeGBZ3nEOUCC/DPZCDDM8HXlv42a279t7vUnp70=; b=j 5N2mwTou/v0xEJjO6n0z5y435nTchDCbWaSq3wWsHg1lNm//iBNePVzZwMYXxcHx jb46ydBit1vDBk29bskcT4+4/LJlfW8wFsHM0VqAGTnlWtlXge8l6Ht6iefDfnbb 24w/q1q9nYjhYoDIshNKuog10C8ezOG0kCvtd+uTBOFipQk190KkAalbNNPFPezE TZ+Q7gCzEkmP9Q+kcdG0IlWv4nt0Okf0gk37hMTKODj1ufVb3CoxS5wXgDOLc4Vf T+qUp+qN18EnlBY/PYWJzOeTRG3lZUPE3jzeF87zQKMelK/HK+cruXRuHvFMXk4m GQlijckt6ojQXyHAohDKA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTEpy7lrUMhd0fDWS4Q28emtSOA95DIDf0FLxxd55kMnIgcg2OM/mVJ4hXfrXkgtfY H87HjGmVZbiQmVPvvVjTiPaqSGui7epnXyxGfuKvjQRVbbgIjTciFF+Ub0/HMwOCsgsGOk tCJUM8PpThgyAnjg8A9o/Eb5UNjJDy1I1AEX3gV1R/EuWOzu1BShigFpinRYYD7+J25quu HJsnw8ffRuy07k0wxD9ctxVK3LuDmtEGSR/CYPuxqzvrgn0l2HUQr7XqIGlqAzTR+MlpJd P3Npdbb1ORrLCnuXRbcW/YMXK+xyysK5W0Kp4eixdr4fwCI4nDr2G5a3L1ProyJnPto0EF qRLXALLJ6kh4S6ZgYBAba/49azSAAx0kBImF0VfpIZEYCVzgUi4PvBFnT62MLB5PULrrQk +3mpTxdzFV0WOMMMFGtWTg01ds2sVsu2LzcBlTJlu/WO0ozlCzVjM+upKAxv9zsaRTqDwx MOKLhETHVKFritDzgE+T/UTlFItavtaApcqo8K8RIU2YLv/sOlZ3o/gnfFQ1gdY14gDCL/ ZRL4654srOS36WHARKeRkCZz0mImFxhf2eu9irFsj+mN9XCJgv6K/DfYLFnCPcfLLlPROa I2Uluuyt2aK2cirEIbXARsFYXSyd+ErKB8isuC77bXje93KZyjlpgZZRB3Yw X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 4B9C6182007E; Thu, 16 Jul 2026 02:34:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AM4Lhj84Qi5w Date: Thu, 16 Jul 2026 08:33:47 +0200 From: "Arnd Bergmann" To: "Linmao Li" , "Sudip Mukherjee" , "Greg Kroah-Hartman" Cc: linux-kernel@vger.kernel.org Message-Id: <3da6045d-de5e-4d8c-8a78-c22d89f7c8d1@app.fastmail.com> In-Reply-To: <20260716013923.19494-1-lilinmao@kylinos.cn> References: <20260716013923.19494-1-lilinmao@kylinos.cn> Subject: Re: [PATCH] ppdev: prevent overflow when setting port timeout Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Jul 16, 2026, at 03:39, Linmao Li wrote: > PPSETTIME64 supplies the timeval fields as s64 values, but > pp_set_timeout() narrows tv_usec to int and calculates tv_sec * HZ in a > signed long. Large positive values can therefore be truncated or overflow > and install an unintended timeout. > > Keep both fields as s64, reject a non-canonical microsecond value, and > use timespec64_to_jiffies() to cap excessively large timeouts at > MAX_JIFFY_OFFSET. This is a behavior change because both PPSETTIME > ioctls could previously accept values with tv_usec >= USEC_PER_SEC. > The validation follows the precedent set by sock_set_timeout(). > > Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe") > Signed-off-by: Linmao Li Good catch! > - to_jiffies = usecs_to_jiffies(tv_usec); > - to_jiffies += tv_sec * HZ; > + ts.tv_sec = tv_sec; > + ts.tv_nsec = tv_usec * NSEC_PER_USEC; > + to_jiffies = timespec64_to_jiffies(&ts); > if (to_jiffies <= 0) > return -EINVAL; This is a bit more expensive, but it's clearly not performance critical and I agree that the added range checking is a nice improvement here. I also checked codesearch.debian.net to see if any callers might rely on passing out-of-range arguments, but the only caller I found (pyparallel) is guaranteed to pass a normalized timeval. Reviewed-by: Arnd Bergmann