From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 69B7323BCF7 for ; Wed, 27 May 2026 05:26:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779859588; cv=none; b=hphR7pCfjrY8W/YwqVqLXjMHw/uybKANP6ZxGzkZJdOqFgVKSA8Dl14dFrafL/V2/54fGwYOKuD/pvr1Xn2KflaLdk+bJzXnzK8Rzb2cJyeNvCpttdVDPvYvbzUIo978xvx53nArD6lp8PozRcoPaNiMjHKOAebMFP8UAXC1E2I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779859588; c=relaxed/simple; bh=WEhDZ++slbWPB+Yb8K9OtkosQWMf8J3K7K2A4MwVDxc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BMs1NzS68lDFyT0UEaLEv3Bfn94d+/GnaOmHP0L3NGZJIruSFIqNJ/b1s7i9fGE17xyzLbu/8EUrnQix5Qc/EtscvUbivfTNbjgOpuye5W3hziGLSDKfEXpYol2lv+U3Jj7CnFUuq+f3yybec0gKMqgJ2pd1TTXjDylorOq5CWQ= 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=Snpw/GoW; arc=none smtp.client-ip=209.85.214.177 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="Snpw/GoW" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2be1dd4af34so101167225ad.1 for ; Tue, 26 May 2026 22:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779859586; x=1780464386; 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; bh=+izZGAVsti5zvwhRlmRKEL+2HzPRMlNhWQLgHFnK51c=; b=Snpw/GoWgaYVLullGg/dGJV6403QMyQyGw3NjNyBWd9/ZxhDTBnJtmfg50WrXO7m+p I18ZSCbeQ/J5zmqHT9OQqa8x61ieuXTpWptIj327gEYGG1DyZLbj0yIA+Bik8T95gWdU L6dzdqgJ2ycR1OW0ZYeJyv7O+IrWaX+R0hosaMCquCwbt8ehs86/XFDIqSTOvMtRRP4d yXBkHZCTB5hNhv0us/7d9azEnmIEN4UGbRq9KXDSHNxAZKnCfP6ZgJbVo7ZW64SNC/nk Ko6OsDsB1g1QpRV6q8xBHhtcxO6CeHP44ONkDkLjino/SvXHi4KWTyom1JQAS0/zheH9 pTCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779859586; x=1780464386; 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; bh=+izZGAVsti5zvwhRlmRKEL+2HzPRMlNhWQLgHFnK51c=; b=RdchJ5dOEuA5xMM5U3oeiMDjutcGE+gLv0ZSO/APaKFUnXu4B/NZi79Kl+8yAdCpTl 8lxw5aCwSS1ImO9uRDqwVpxUiD0UlKtzZFK6XjjfaG4A+ilCvi/eiAJai93MENbD8C0j FipEwV9h3QWWHJYATPPKyR2wy6BudJIpb4XUG67SRTZhzIrQLrXiPO0TCkzAffPsM3ek nOgrhFn8r1MJkG+y5iWPdHU76RGTLgsc8/t1apswcYgUZynXUmiWWdOeVUjowRMNkYGS zRipmEqz8Vqs3IJJxio1XvSYsagTpNG49m2+kGbpoZNTnYxmCR02ui1q4Hl2DbmOPyB6 sfuw== X-Forwarded-Encrypted: i=1; AFNElJ94DwqxZqru6oaasGQIUzTEgJT/RFvT7k8He6U9OxVKmBSZvHOnZBofR625D2ljtdnSCMFBzhjGrU/dDYY=@vger.kernel.org X-Gm-Message-State: AOJu0YxZ+h7DHWwZaSSQdAI8fRZ6rTtjYg7XIgeFoIVq+J1z1pyZVCzW pq39jrCfyDHmty9HG/ORkwCpllezlzmUkWRzNDARGamr6ZKsJNoUm6hr X-Gm-Gg: Acq92OHU2wzjHoM+9zlm5p+Khvgy98WWSxmGYPjcF3br3v5jiV+NBowg9ajvjymaKCA UK9CCrG3EWFUX0kpN28c1pcTQ8RqxNFnwgbj8sGtZUV4lPu1ZSmwzfp+UHAx93RHZHa/RAOVMAO fxmmkqSEMLs0Fqeteet+GLqoTIZIITraX4FKQdnsY+ktVJCYTSMGXkf3iGol+DSFbazVTBK0yTw hm+IbrjXod/6Hj4X5zTxk0P0oHYDo7eSlnT4JDn+/0ZBpaVk1o0MHQ6PsSw3ZCEMmQrp+khYa/6 hbEAWxmgjZ1PidORhijSECWtyZuvipeLl80cU/2lVWDF5zrWMohnpj84USxtWSi5ynv+l0o3ElZ 1oRkul2cGKuFofWoB/W5/UPVFmml7vRuxU2PdnIovypbJRrrhQxQ65yBWIXEp+wnLo0y95hjydu Rp+YqXJUQwBJrr2wwSUkF5TCId7RmcMep/8ShF0td+Ds/nSWg= X-Received: by 2002:a17:903:1b43:b0:2b7:abc0:3bd7 with SMTP id d9443c01a7336-2beb035b8edmr246804415ad.9.1779859585668; Tue, 26 May 2026 22:26:25 -0700 (PDT) Received: from localhost.localdomain ([220.83.29.221]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb58e4fcfsm144891465ad.71.2026.05.26.22.26.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 22:26:24 -0700 (PDT) From: Taegu Ha To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Eduard Zingerman , Kumar Kartikeya Dwivedi , Shuah Khan , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Taegu Ha Subject: [PATCH bpf 0/1] bpf: reject overlarge global subprog argument sizes Date: Wed, 27 May 2026 14:25:38 +0900 Message-ID: <20260527052539.3388700-1-hataegu0826@gmail.com> X-Mailer: git-send-email 2.43.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 This fixes a verifier argument-size overflow in global BPF subprogram calls. For global subprogram generic pointer arguments, the verifier derives the pointee size from program BTF and stores it as u32. That value is later passed to check_mem_reg(), which feeds a signed int access-size path. For stack pointers, the value is negated to mark the call-site validation path where STACK_POISON is allowed. That conversion is unsafe for BTF-resolved sizes above INT_MAX. A type such as int[0x3fffffff] resolves to 0xfffffffc bytes. On the vulnerable stack path, (int)0xfffffffc becomes -4, and the negation validates only a four-byte stack object. The callee is still verified with the original large memory size, so the caller/callee memory contract is inconsistent. I confirmed the issue with a non-executing raw-BTF verifier reproducer. On a vulnerable kernel, the verifier accepted a program with: - caller object: a four-byte stack slot - BTF callee argument: int[0x3fffffff] - resolved BTF size: 0xfffffffc - accepted callee access: *(u32 *)(r1 + 4) The relevant vulnerable verifier log contained: R1=mem_or_null(id=1,sz=0xfffffffc) r0 = *(u32 *)(r1 +4) The program was only loaded to prove verifier acceptance. It was not attached or executed. The fix rejects sizes that cannot be represented by the signed verifier access-size API before any conversion, and adds a verifier regression test that expects: R1 memory size 4294967292 is too large Security and reachability: This is reachable from BPF-loadable contexts that can supply program BTF and BPF-to-BPF global subprogram calls: direct CAP_BPF or CAP_SYS_ADMIN callers, explicit BPF token delegation, or privileged BPF loader services that accept user-controlled BPF objects. The delegated-loader case is relevant to bpfman/bpfd-style deployments where an API/RBAC boundary can ask a privileged daemon to perform the BTF and program load. The issue is not reachable by ordinary unprivileged users on systems where unprivileged BPF is disabled. Validation performed: - vulnerable QEMU guest: raw-BTF reproducer accepted - patched QEMU guest: raw-BTF reproducer rejected the oversized size - git diff --check - scripts/checkpatch.pl --strict - git apply --check on a clean tree - clean worktree object build: kernel/bpf/verifier.o kernel/bpf/btf.o - git send-email --dry-run Full BPF selftests were not run in this environment because clang is not installed. Taegu Ha (1): bpf: reject overlarge global subprog argument sizes kernel/bpf/verifier.c | 7 ++++++- .../bpf/progs/verifier_global_subprogs.c | 17 +++++++++++++++++ 2 files changed, 23 insertions(+), 1 deletion(-) -- 2.43.0