From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (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 78EAA2D3A93 for ; Fri, 24 Jul 2026 01:03:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784855018; cv=none; b=ZFjIxHXVZUwdyvNoPpx7sKySSb7ZeAdKRcenj5yN/PA4U6lE6qrPFWqdfy957f1FiQ6lAlzcv12V/8/jZekqKAoImI/SMNcVMbkDNKxAW+Cqv8v1MH6CzQItm3qU4cpjY87eSga4j0IEG25D9Lo40jJsCYHAnqkdQzJMAL5VpyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784855018; c=relaxed/simple; bh=EYtGon2mOKRyQA+SWDxFLaacgRtfy4ZbfR/vRYaeE9U=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=rSj6srnsNPCalZnNSJUTJHgvI16JhG7f3W/4LTKiKgA4IvqJEeOv8HnTs3bydA6v+lH+DWJjPwqmpJ6KzfP3iuJ1b5kwGYTataZkvCMnKUpW8ShJFErF/FOgG9G57iLwp8EqitWNJj3MOCzaO1TvePRYNfncZ5+g+J7e38qiBfs= 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=GSwFR4KA; arc=none smtp.client-ip=209.85.210.175 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="GSwFR4KA" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-8487b7b3fc8so1286650b3a.3 for ; Thu, 23 Jul 2026 18:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784855017; x=1785459817; 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=EYtGon2mOKRyQA+SWDxFLaacgRtfy4ZbfR/vRYaeE9U=; b=GSwFR4KAaBa9gTSClEOTmu0NIxCLZpKhRIvCfN+n/o4jym0LpATzNEuSIe/uoMnooP WABaIfpkEVyvquUsfr2XYPgY3dAIUTgW1bp7n6l1dfbDL96GZTwy9hO9SZcqKbg/hf1a EJbnUgBvlk0bECdeBuXAW2TtvGmB2U6LR0Fag/c2h+mPb9AKWxaAZh5T/xugTOKqhytk yBdfGX9Qa2hKt6lukHafK8hZRWBwxFENUYKDnsabz9Ari+m+Y3BBA4tECtK2EcG4mcye AvEtpzo4IdP4KFfphJm3HVYIdOePjIPC3wfWuh5n0azuo2y81tBLjVRm9M0eVuG/wrof Gy0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784855017; x=1785459817; 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=EYtGon2mOKRyQA+SWDxFLaacgRtfy4ZbfR/vRYaeE9U=; b=dJATT9pNS5eL7I3dLHcj42fbKIHzTIahQkvE3jtQdxp6uITimG9lKW5ccJrWHCL8zt /SORlqPCQqEUmeOY22XKUfrYj7f/LE4wj6lwjqeLj2zAoyeq0hGNbt9XhgYyZQc8agBo pDS6Z5XDfhVZi/bb+nmtYwbAe4D2kJBFBttEzSRu62XEBVbBekw71j1D9dVU0g0qH+Tv AZL9Po9IlWZAm5KpUFaEtkqVYjfJb4+j5/gdB6bj/c6kJ8R8XDz5L4pS2E5Zb/XSqPZi h05SQmv1dVeSo13YSPXcVMnXmHqSBfREcvmHZsAJD4+vFHlFNtTUQZxtvXdJ+gEzJlJv x0Kg== X-Forwarded-Encrypted: i=1; AHgh+RoGydGML6BGOMyi/elZ0sumT7p/ImotpkaqSsKQB6LTzXrLinrLV4pqbyBZo81EpGivSMfmZriczfT91zk=@vger.kernel.org X-Gm-Message-State: AOJu0YyLOfcVad852yWk6b2FiN0dlc9uGYIy/dVuqFyxPQIGlLmiuAVK 5MD4T4UZgp5YVpA4V8e17sLxyrL+nhAm2P545nDFf2y2NAZ40hE40Hc0 X-Gm-Gg: AR+sD13QsBkPohgxX8Y8QMcXH/cBsugJG688Saw8dLgQXFBdgDJHfr34i1mN2zpHKMb MNbNxUCLk2t9/j0qJ32grcKB16iKW33jwKaSU+oiBWlxTEnBJq2YHfRWG6V4dcrWlSH50U4KCPh IUvr5/jSqVY6tm27GDX3jSaYfm7BOA6tdEEukEMs802SbfQEANUT3/lxZjgva6rUwQU16I/5gPA gU3b7Bce4z5Ayt4ja7OxNnWMY8YK3zPQcztqy0SoW7IUe71aSI21qzjpnuHvBw1C5peUQ+bSXZn X/joS89IAHl1e3b0WYb3EPJ7p5/y+x7Mr+Cclxl2gVkx1a8hKfBkHNM134Q1iR8iRK/njohiBPA JMHaMTvaicaGQWcQ65ISbcOE2ZPG2yR0zzyAGf58lbnyjD5rvqsrb67lS/pcYwd2ny/Pv0kV008 cfp5zXH/+TVTy2paXvnL6bswNYhemzUhLBStiWaLQDYuZHivsotSOJHgmrXco= X-Received: by 2002:a05:6a21:2d46:b0:3c3:83e8:c211 with SMTP id adf61e73a8af0-3c44b25397fmr6112121637.63.1784855016691; Thu, 23 Jul 2026 18:03:36 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:c221:d012:6e37:77f9? ([2620:10d:c090:500::2:8dac]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3147dc9f2f0sm25307955eec.13.2026.07.23.18.03.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 18:03:36 -0700 (PDT) Message-ID: <4fc7fef5d38839b5f01e80b05de908d95af8f3c8.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 18:03:34 -0700 In-Reply-To: <71f6059ecc89d0b16f8542d73ad8b183a2a4db92.camel@gmail.com> References: <71f6059ecc89d0b16f8542d73ad8b183a2a4db92.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) 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 02:05 -0700, Eduard Zingerman wrote: > On Thu, 2026-07-23 at 17:16 +0900, Min-gyu Kim wrote: >=20 > ... >=20 > > Root cause > >=20 > > The verifier records an ALU32 definition in subreg_def. A later 64-bit = read > > causes mark_insn_zext() to mark that instruction for explicit zero exte= nsion. > > Before 107e16979905, a cache hit in is_state_visited() propagated the 6= 4-bit > > read to the alternate path's ALU32 definition. >=20 > Hi Min-gyu, >=20 > Thank you for the report. >=20 > > Commit 107e16979905 removed that propagation when register-chain livene= ss was > > replaced with static liveness. The static live-register mask does not t= rack > > read width or path-specific subreg_def information. In current states.c= , > > regs_exact() compares only fields before id, while subreg_def follows i= d in > > struct bpf_reg_state. >=20 > 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= . I figured out the repro and am working on the fix. The plan is to extend compute_live_registers() to statically infer which upper 32-bit subregisters are alive and use this information to fixup zero extensions, and drop the reg->subreg_def altogether. ...