From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 609D93F2109 for ; Thu, 23 Jul 2026 09:05:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784797521; cv=none; b=i9sw/zWaWalQ1CjeV32iFAZIZuWpdg3bhbkqcF4hMlN5rXCYrMjUWm3yR/vf2dq88hMmI46cp1iT6eX1YBD0t33JoUahbjxWBmGv6Zy0RpOuKjGpulOvz6Aspn6Tbz/p5wpagKNz1Kcq7L0DcY4xsvCv7aj7RK1YwEn8IWWUSoc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784797521; c=relaxed/simple; bh=LuCbOJEq9s4gUkoOzNekTbMB6Teey7IN57xuRmPy9vY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=D/qH7R5y0W+2ZhNbDgo6pcR9NhbPZ8k2lUsOF7pw4u8f0dZmVFdRxPFDBJdluB3/RpcdaSo48j5KzsN60jXVtgmGqXRo3F29xHOJfgK/svRpqrEfLm+JgCEla/H55P3BfdGlgXSIxyauq6AnwXHobVcX34ybbCjGcqjUG8cwPAQ= 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=fmAuAM6W; arc=none smtp.client-ip=209.85.214.174 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="fmAuAM6W" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2ced3386430so4539955ad.1 for ; Thu, 23 Jul 2026 02:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784797520; x=1785402320; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=LuCbOJEq9s4gUkoOzNekTbMB6Teey7IN57xuRmPy9vY=; b=fmAuAM6WWBK5QASBQlc8a0v8P+QHB9x96gr4giWSCMWnqKmt2vCTq1Nkv6oUcQ3HVd BTfpLyJaaFScP4VEFWvq48hkAcwUygMWTSr+OSToAy6DCN6zZNOq+J13Jwesc4eN5WwK AtmAL2BG6Y1jR+r8sYeZf6Ar/gHT7Yy7xvUJEoGDd8n+wXThvkhlQ78IgdVZ5GpVhoiF MFs/aeQwzKeHtUCfPxCV3zSbINtBBk8UryfmbdqJdkW0pXjtAyH7tHrn9w/W6fBPlox4 rY5axhEs7bV7SxRGXhh3QbIgQ9nLG/l4uCcTjHIgiyzs8Wbg0q2UgMYW7svR6YskKxDn +RAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784797520; x=1785402320; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LuCbOJEq9s4gUkoOzNekTbMB6Teey7IN57xuRmPy9vY=; b=YWiesXXj9iMnJ56manqfNHpPopIFWjZAcu45QIbHHiiULF1DrjiegdMHwWcIflCQD/ DWAdMyXFi56E9P1c7TjXvw/MBJ1/a48SWfQlqI8i9ppTKiLLd3Ab+Knel6DwhsKRXFoq n3trSbPF57mXzkoqTA7obLZKiqAU1fEf+JpejTq5oTFUCLhBRhQcigm+cB4ff/Hc/Fhg 1165nCN37bufobOslI2GLwONV7aSMYg3R6zRtyeiZx0pfUvQrE2vNL2qFQPCHoDk0/9s sq5EYW/H6rD3binwJ2VDCESC67pL6v3BZJ/o+vre8Vuh90QmaVP95o6EL6YNtk45aCu5 58dw== X-Forwarded-Encrypted: i=1; AHgh+RoNS71FUf1Cj8ti06/KoYf8CmV5+slo+VxKf1WTd6OOMA+heze/XjbOB/XWI0/xkeCCafi6UoqN6hBbbxo=@vger.kernel.org X-Gm-Message-State: AOJu0YzLwdzSiQ65vn2oOcukhsAc0ZCNZccoS48zgIvKcMq6orMNtiRJ mRJjqzwDYWLQF4Fug1Ikmo9jt3Mz8qM3QWK5v5ZQO3jhVb4o5nl0yeR7 X-Gm-Gg: AR+sD13XV9+eXtq0FtZvPAtmgsWNn2TsFN4AxJJgRWBq0FXSqhPJvsr6CqrFiCkOo4e Wy9dpOdogdfz2SV/q3KFgIMIHjJ1MjbBqZTGSzzpm6wWnuv0Wj1h1P1YTJbp0L0l1UqriIRfncf lIPrjWXg4InpdcuPs1sL1rqAURRAv/kuKYhjNZa2cRF9/Ia/t3m36A1vRk1uuO/NHE3FuwMLMvN E6vLOB9JuKSbiKtJOmnGxpS/VN7icRWE7WIuSCZQ7gmaBRW+1vZZth9maxxU2gkKB3U9jykLMAz 16ePV7hwLxoXLsUd6v+E/JTmeLNjd72bdj1lgA22NGLmKEWk7t3y8bJVj0mawbYH8X7a8krpFGs nv6YEZFLShT1c8R+BIzFFK+YFAsYVJANV3I+3DAKhKEk+dXgVUyOYWkiWb5ep8D98BC5MugmHFy lC7nJyPncmMObzdw7LUYZz+ncrjeQ0FTKQvClD8Kps X-Received: by 2002:a17:902:d54f:b0:2c1:98b7:ecf3 with SMTP id d9443c01a7336-2cfa74886a6mr25002765ad.23.1784797519561; Thu, 23 Jul 2026 02:05:19 -0700 (PDT) Received: from [192.168.0.13] ([38.34.87.7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf8efd7fedsm29671005ad.24.2026.07.23.02.05.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 02:05:19 -0700 (PDT) Message-ID: <71f6059ecc89d0b16f8542d73ad8b183a2a4db92.camel@gmail.com> Subject: Re: [RESEND][REGRESSION][SECURITY] bpf, s390: verifier/JIT mismatch allows unprivileged kernel memory access From: Eduard Zingerman To: Min-gyu Kim , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Ilya Leoshkevich , Heiko Carstens , Vasily Gorbik Cc: bpf@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, security@kernel.org Date: Thu, 23 Jul 2026 02:05:16 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-10 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-07-23 at 17:16 +0900, Min-gyu Kim wrote: ... > Root cause >=20 > The verifier records an ALU32 definition in subreg_def. A later 64-bit re= ad > causes mark_insn_zext() to mark that instruction for explicit zero extens= ion. > Before 107e16979905, a cache hit in is_state_visited() propagated the 64-= bit > read to the alternate path's ALU32 definition. Hi Min-gyu, Thank you for the report. > Commit 107e16979905 removed that propagation when register-chain liveness= was > replaced with static liveness. The static live-register mask does not tra= ck > read width or path-specific subreg_def information. In current states.c, > regs_exact() compares only fields before id, while subreg_def follows id = in > struct bpf_reg_state. Hm, the stack is tracked with 32-bit granularity and it should be easy to adjust compute_live_registers() to track the width. I'll give it a try. > The SCALAR_VALUE case in regsafe() also does not compare > subreg_def. States with equal tracked scalar values but different ALU32 > definitions can therefore compare as equal, leaving the pruned path's ALU= 32 > instruction without a zero-extension mark. This is orthogonal to liveness mechanism, this is also much older. I think this is the true root cause and it should be possible to construct a test case triggering false-pruning on <6.18. Thanks, Eduard ...