From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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 5BE852D29CF for ; Fri, 10 Jul 2026 02:31:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783650687; cv=none; b=OG4aIc+284JVjNZSXilmG7JmiPTb1tYoDKqIWSGVndDQsKUyIZMV60J8ed/vgERIyw7S+Kt6dJi17grAp+mrLfX0WDn9yDo13SR446RIEOtaR/SBH7AUKkWIuzd5j+7GL+pl1RFqL2TK8E1NJJIdE1GYRPEEXWRR7V2c6qf97Yw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783650687; c=relaxed/simple; bh=HiyZ/mRGbDtTQ4KM/8YUsOii48kY/vlJSMg+C6ZlMpU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Rag+jmygTB4NbJOGGkK/DFnmq4N32Iq800pY7pcSieDIj+rkrOBdVIAATjW7vulkfAkgXRNxab4js/y7T2SbUpi0YNMgZPnq3jg8/FTE4fX7Kf9CCzBr/vz0Kin4jzqeWABnc/18XIxfIE3M3CBuCBzSChdS+bsrnYW3XWm/qPA= 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=XMI+3FPd; arc=none smtp.client-ip=209.85.219.54 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="XMI+3FPd" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-8f18d92172aso6612006d6.2 for ; Thu, 09 Jul 2026 19:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783650685; x=1784255485; 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=jkeC7bWqSkFNiKhrvAzXsbJK3S43VOw0XA5kqChV70M=; b=XMI+3FPdhSfIqINUPkr0pZN+lPKeL42DfwPpKFt6fixKZOy1ziY2t2KLbyhkQLEBEC +UVaPKuYcCAwdlD9uXcu6LEE5GMH9S334+ZojQITGxuc9uaJ6kuaMAuCXwThRK630HRk i3mheq6bVvEqb244eNQZr7+el2VagCGH6gu7r1Ifm03k/nDmibb3T5cLt2a+AxJMfhUg Rfp/kB6eygjhHdmTHOKZZ0a2RBtMgDL1J6J7OFDFeFxeMN60/Ok+e0u3/QYkGUhRyJRO pgKns9DGwzxMm6ay8F7nqqL4Ma8fsSILrTCE5YW6oizu+KjQ9BU+1swwnPDZthuCwZE7 WGCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783650685; x=1784255485; 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=jkeC7bWqSkFNiKhrvAzXsbJK3S43VOw0XA5kqChV70M=; b=K8uGpGCF+lOtZFx72q9an4WHukQRcw6tQw2OWBU+v5f90TAbYN0PTpXEr3J6BdQhVO ZwyAYhOP3y+YxQgBBAoczhfwXEdeR3fRkbnE/WsNyZmB06hzLbu9+4HwEKTXwlqhFq+U zMVn3Bgyos6vZl1xaEj6z+VfdS8kXxhzxqjkLEJicJGGNXy6M2Y9zRKjfYMMhrhvzcJm Q0Rz8kRd719Q/WVvKdnuIDPRQUdxLso9v2YOhtwEB3DRadVHhaMaVDcpij4ha2c9IYB+ 9vSY0h8AFVi0DR+w/5ouc8f2ixi9MA1a3ed0qzhM/w4meJxDtxu1YMAwzK619tStyS7c GVRQ== X-Gm-Message-State: AOJu0YwdSsAx4FREh0eRDvDwi4dpnnYRlhCnDGqAo37eD1IsCk7NGEjk CDWE14UoUwkASPs93/ptJq4Rb737xDJym8T2SQEHcIUez6PhZUAmsVHn1GWe+EqsYV0= X-Gm-Gg: AfdE7clrs2F+RRzXr30Xu4E1+wWkSQpfNM84oSQXD90D3KRuCfXXRXEbnvWGwOGxC/1 q/rygN6KanLaPqaRF1spMXANL9ewxc5qE81v1izMt+e217EfNKF0m9XUhNEI+y56icGgiaU8A0i 8JWohgSVtudSmoJfHbYe9c1dGW/kaqADoO5XyobcwuHIQkEYRBGyJlIASJ58ds8obe8xtFemToL BzpUFnaj5IBj+AnZmIRWWvaajtVTvUcCrFC1IAZblo1J9KqksZPJ8RMB5wE2mX9dyoAJ2C0+MeO sQJsY9vW2oaIR0JdOnuTkmQ0AuRZJR+7I3BVz5w++vi180QRwjSWNx1TCew/16WPFMqWj2cJAfO PTkBx2xdxVBJCMvLaritDglEJHJtrSQoYHrQRhYj388Drxjcja98kAiyDcONM8f2ZUOswPkF6nA vnvWbZjeR1lxn2PL4ExExh0k07WB1f3SEpuKK4gERoaiQQLLne2SmTXRp1cOEnL55x8byIXHGjU rrKGV28B4K56p5B7PltUWyNfp74ucg9 X-Received: by 2002:a05:6214:3d8a:b0:8f3:7d39:90f1 with SMTP id 6a1803df08f44-8fec2275179mr115256856d6.37.1783650685212; Thu, 09 Jul 2026 19:31:25 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ffd7c1ec84sm31121066d6.29.2026.07.09.19.31.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 19:31:24 -0700 (PDT) From: Michael Bommarito To: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Subject: Please consider fb3bbcfe344e ("exit: change the release_task() paths to call flush_sigqueue() lockless") for 5.10.y, 5.15.y, 6.1.y, 6.6.y, and 6.12.y Date: Thu, 9 Jul 2026 22:31:20 -0400 Message-ID: <20260710023120.3747693-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Please consider the following already-mainlined fix for the stable series listed below. Upstream commit: fb3bbcfe344e64a46574a638b051ffd78762c12d Subject: exit: change the release_task() paths to call flush_sigqueue() lockless This is a stable option-2 request for an already-mainlined fix. The patch fixes a security-relevant bug pattern that remains present in the listed stable branches in my current review. Why this belongs in stable: __exit_signal() calls flush_sigqueue(&tsk->pending) (and shared_pending) under siglock with irqs disabled. A local unprivileged task can block an RT signal, queue signal instances to itself up to its inherited hard RLIMIT_SIGPENDING, and then exit, making the kernel drain the queue with interrupts disabled. Raising the hard limit requires CAP_SYS_RESOURCE, so the highest-impact case depends on a high inherited/system-managed limit rather than arbitrary unprivileged limit raising. Requested stable series: - 5.10.y - 5.15.y - 6.1.y - 6.6.y - 6.12.y Fresh stable check (2026-07-08): - 5.10.y: 738ac465e4e9 fix shape: absent; upstream diff: applies-cleanly - 5.15.y: c86c4726e7f0 fix shape: absent; upstream diff: applies-cleanly - 6.1.y: 090666d3cc90 fix shape: absent; upstream diff: applies-cleanly - 6.6.y: da47cbc25466 fix shape: absent; upstream diff: applies-cleanly - 6.12.y: 296aabce4594 fix shape: absent; upstream diff: applies-cleanly - 6.15.y and newer checked branches already have the fixed shape Backport note: The mechanical check above reports whether the upstream diff applies to each listed branch as-is. In this refresh, the upstream diff applies cleanly to the file snapshots for all requested series. Impact context: - current CVSS estimate: 4.7 - vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H - direct-tracking exposure: Debian 11/12/13 and Android 13/14/15/16 GKI - primary touched file: kernel/exit.c Impact: local availability only. My saved v6.1.173 test at this host's normal pending-signal hard limit (450505) produced a 1.035s clocksource long-readout gap. With a high inherited hard limit, a v6.1.173/QEMU run that queued 6M RT signals hit a softlockup watchdog panic in release_task() at _raw_write_unlock_irq(); the same 6M target on v6.1.173 plus fb3bbcfe completed with no lockup signal. The fatal case therefore remains AC:H because it depends on a high inherited or system-managed hard limit rather than arbitrary unprivileged limit raising. I do not have evidence for privilege escalation, code execution, confidentiality impact, integrity impact, NMI-hardlockup proof, or a default-limit fatal panic. No reproducer is included in this public stable request. I can provide additional details privately if needed.