From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 DA78E25A2DD for ; Tue, 28 Jul 2026 13:51:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246700; cv=none; b=kkHM48H3B9RR5hRpg8Saxr1Ws24zTm4Iviyg6eYu5v/GmE/IBka5hon2HZzl8Npm31UX3KFIJRlGZAC22wGprbm9sxY+qnRkx0fzOk6HtWom4mAPUegznW2My0bHcWVOtAFjYKCscahamcoHsG2KbHoWPjPvvhnJtwAe0iN/gLM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246700; c=relaxed/simple; bh=r96kwzBIc8Jied5GwHDPHGc6xnmckXwOtOi28k4xvZA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=fUSoMpyMZQJCJN7u9Ll1edbPcXJEnLegSKUAOkFrvYbpQSVWxZsZp7kHV8Q364vs984O5ZfYfsFC3oxGZZFz2UBS5K99JGZuLeIhohuZA15/wjTSs+UWJEjEbo/Xm1NIJUDxVkBcT4FCkMtoWSYCboFbSnt+tylvKqEnNGqKSs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Ax3A5mLe; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ax3A5mLe" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-47de0093c42so3042256f8f.3 for ; Tue, 28 Jul 2026 06:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785246697; x=1785851497; 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:content-type; bh=cY1+qecTjpPQDXB5WlxHN8z+3cpmFqILEHWinOpbPx4=; b=Ax3A5mLeAEyA7q5K/8vfR8LVAp3bY42wrpuDezFir6OEKSRhCtHQj0KpJNTbIBQsoi LnX3RE2zyUUCLYgcLx+DkQ/x6n+v0RayBP71xwYraS3wXzZuufASj+xGL7gGe4qpgaVo 9cPM3VlAfjJvBmg6OdS2Ch7Tk5TFdUejElHXvtRHPbzhLVYxjDtgBWlFFFjkbN50rIHk 38Nnuw57aVqrmfpYJgUgC502fFEyQGhiaDTRbwMSvgFpM9rLZjcwzx0bmGMzBIXEgiFm wPwEKtFTLZWfvqaWqNWjBSMBoa9W+w49eB4z04PaGBeQFEN8BwRrERnj3kHwwZCa0dMy nvTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785246697; x=1785851497; 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:content-type; bh=cY1+qecTjpPQDXB5WlxHN8z+3cpmFqILEHWinOpbPx4=; b=OkQbudYPZkud89HwPaaZSIZd0q9NQLh0v7l1xXEJL8NamLWxLX9MMuedv1fISopBoH brgMD7wZ+BQ3nirtdYucqb0D266gN227ftXAsZTnZIGF80Va/AiWEp6YLIXgbF4EQWkG PoENBHFOFzl9LpUn22/odk8AfUqvi3ZXvS8MJKoW+SCqLNCBkKAJK4nyaDmxSPugFIpC 4vGI2mGF919g9zsQ1piWFJtJpjtSuvVPR0TwQidtigIiE8Qr6NqQ8M448iqIkcn49DPR EGYx695KFRszWti2oupXEb13VzE+2+zaFh+uwq0u1yLzYmXy4r4GUUCTdSLQmaEeA2UY ++8g== X-Forwarded-Encrypted: i=1; AHgh+RqqR0MF9m+TmkgMUiVn8yfrCNfn/4j9ocY+yhuNNVytyLeb8LLANWkEwqRTRbbtsc63wSeXjzHFFTnPYZs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxa6VxcfRS6237qmf2fJ2ZAZnS4vJVWaOtZ7Fz/YqpfKuzgJV5R Xy3Vk1t8KzfnRrZCL93D/fyr9D5bHKAaAZtYQuwj3qr9w3Vx+9t+1iP/ X-Gm-Gg: AR+sD13/HOVOU4hTdxfyONQ4ScT9G6dMeZgq9ieLr7vQErS7nTTkEEd0Ow80hUFSg86 souxXUD/7LDpPoSvZ0LdP2H0ph3nKLtSgHcKW7zfLvLLhSC1kXHWwzXZ18U/t7rUdchUDPrLnzM uUuUH1OVJhzl1HaWEbb/Lgxg0lnch9rDWcthjfmA8j+0pKdqyQvPAZCLluFBZ2cXvMGEGWoKkhT U8Kz/lbauC40hKR4jze4IPWjM2TQbaJ+en9jw2GaGPfKgL50TzswZZUKZNwxHDT7bqOjSOXwPQW lFm5vOXJbc0xYWoPNAknsP3qbujpCT1xYJr6iI13sZKP4udN6TUwdL2uxkUhUZTwNHOCoTEF6H7 8oyBdenvmCjAdxI9+9En2qXkoDSYkNeojhhU5C2zdEyvQdauSd7sfgBRI3TtkuwYt8GsPhrvZKJ mr28vrkqBf+HPqjDwVcBe3XWgWwPe/1zfcjS1JPAKQngHroj6F7Hu4wMkLx1V6HdsLPQ== X-Received: by 2002:a05:600c:1391:b0:495:4a34:16d9 with SMTP id 5b1f17b1804b1-496c65ab4f0mr26696655e9.31.1785246696724; Tue, 28 Jul 2026 06:51:36 -0700 (PDT) Received: from fedora ([202.47.63.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85c6dc25sm57125898f8f.33.2026.07.28.06.51.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 06:51:36 -0700 (PDT) From: Muhammad Bilal To: dmitry.torokhov@gmail.com Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Muhammad Bilal , Herlangga Maulani Subject: [PATCH] Input: raydium_i2c_ts - propagate device info query errors from raydium_i2c_initialize() Date: Tue, 28 Jul 2026 18:51:27 +0500 Message-ID: <20260728135127.48971-1-meatuni001@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit raydium_i2c_initialize() calls raydium_i2c_query_ts_info() (or raydium_i2c_query_ts_bootloader_info() in bootloader mode) but never checks or returns its result. raydium_i2c_probe() treats a zero return from raydium_i2c_initialize() as full success, then unconditionally allocates ts->report_data with size ts->pkg_size and registers the IRQ handler. If raydium_i2c_query_ts_info() fails on every one of its own retries (e.g. because the device is still completing power-up when probe runs), ts->pkg_size and ts->report_size are left at their devm_kzalloc()'d default of 0, and ts->report_data is never meaningfully allocated: devm_kmalloc(dev, 0, GFP_KERNEL) returns ZERO_SIZE_PTR, a non-NULL sentinel (include/linux/slab.h) that must never be dereferenced, which passes the existing 'if (!ts->report_data)' check. RAYDIUM_TS_MAIN is also 0, the same value ts->boot_mode has from devm_kzalloc() before raydium_i2c_check_fw_status() ever confirms a mode, so a spurious/garbage first read that raydium_i2c_check_fw_status() does not recognize as either ack byte leaves boot_mode looking like an already-confirmed RAYDIUM_TS_MAIN without it ever being set. With both conditions met, probe() completes 'successfully' with a live IRQ, ts->boot_mode == RAYDIUM_TS_MAIN, and ts->report_data pointing at a zero-size allocation. The next touch fires raydium_i2c_irq(), which passes the boot_mode check and dereferences ts->report_data at offset ts->report_size, both derived from that never-actually-confirmed state, producing a NULL/invalid pointer dereference in interrupt context: BUG: kernel NULL pointer dereference RIP: raydium_i2c_irq+0x5b/0x1d0 [raydium_i2c_ts] On kernels with CONFIG_PANIC_ON_OOPS=y (e.g. linux-hardened) this is a full system panic on the first touch; on a default kernel it only kills the IRQ thread, but the touchscreen stops working and a subsequent reboot can hang cleaning up the recursive fault. Have raydium_i2c_initialize() return the result of the info query in both the bootloader and main-firmware branches, so a failure there aborts raydium_i2c_probe() before report_data or the IRQ are ever set up, instead of leaving them in this half-initialized state. Reported-by: Herlangga Maulani Link: https://bugzilla.kernel.org/show_bug.cgi?id=221777 Fixes: 48a2b783483b ("Input: add Raydium I2C touchscreen driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal --- drivers/input/touchscreen/raydium_i2c_ts.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c b/drivers/input/touchscreen/raydium_i2c_ts.c index 0256055abcef..a0b23772f4c0 100644 --- a/drivers/input/touchscreen/raydium_i2c_ts.c +++ b/drivers/input/touchscreen/raydium_i2c_ts.c @@ -426,9 +426,9 @@ static int raydium_i2c_initialize(struct raydium_data *ts) ts->boot_mode = RAYDIUM_TS_BLDR; if (ts->boot_mode == RAYDIUM_TS_BLDR) - raydium_i2c_query_ts_bootloader_info(ts); + error = raydium_i2c_query_ts_bootloader_info(ts); else - raydium_i2c_query_ts_info(ts); + error = raydium_i2c_query_ts_info(ts); return error; } -- 2.55.0