From nobody Mon Sep 28 17:48:36 2026 Received: from outboundhk.mxmail.xiaomi.com (outboundhk.mxmail.xiaomi.com [118.143.206.90]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D5A4376A12; Thu, 20 Aug 2026 08:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.143.206.90 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787215626; cv=none; b=lEOS9IYjxqMlGPHE7EPsn+3WUTWOBo/C4BrdMZS/Y5kqARjcC9BI8D2ax1rjL5svl/jvmHNX5NdwCOFViDpiaUvfQ855EpgEBgQ2XZdKZy5RP3Xuu04fDLOFLej7yiQsEE+3N4cokIKtiK/9JkdAJoWX2AGm6y8HGkfMFHkkIrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787215626; c=relaxed/simple; bh=zF5fCM7nDYfymdMcvVadzG6IajfN+HxR0r9lfkbZLpg=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Oobpn3fkrACdr89jOd1chtuiDNi2ToJUVjS+Z5HqjMiDbUuIPnmFS1auOkRjMjws/dvW+6hD1u/ZM0Cxc1TdXGV9ThZnzjVO2W46XIWKF+YaG/E0+zJvrcTRxCC5x1Oe8aCKDPIhAeAX+BpcRhpZuh6kWYBJdR1utY85H4Dbk2U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=xiaomi.com; spf=pass smtp.mailfrom=xiaomi.com; arc=none smtp.client-ip=118.143.206.90 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=xiaomi.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=xiaomi.com X-CSE-ConnectionGUID: kjOtaCVCS2CZ8JCTdCG06w== X-CSE-MsgGUID: MWKiRehuTRGKF2xuzRaPlg== X-IronPort-AV: E=Sophos;i="6.25,232,1779120000"; d="scan'208";a="159903525" From: meishaoming To: CC: meishaoming , , , , , , , , , , , Subject: [PATCH bpf] bpf: array: reject max_entries > INT_MAX to prevent signed-iterator overflow Date: Thu, 20 Aug 2026 16:46:43 +0800 Message-ID: <20260820084643.35489-1-meishaoming@xiaomi.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: bj-mbx11.mioffice.cn (10.237.8.131) To BJ-MBX03.mioffice.cn (10.237.8.123) Content-Type: text/plain; charset="utf-8" BPF_MAP_TYPE_PROG_ARRAY (and other array maps) take max_entries as a u32 from userspace via bpf(BPF_MAP_CREATE), but array_map_alloc_check() only guards value_size > INT_MAX and leaves max_entries unchecked. When the map is later freed, fd_array_map_free() iterates the ptrs[] array with a signed int loop variable: for (i =3D 0; i < array->map.max_entries; i++) BUG_ON(array->ptrs[i] !=3D NULL); On arm64 (and any LP64 arch) int is 32-bit signed, while max_entries is u32. With max_entries having bit 31 set (e.g. 0xFF00000A, observed from a syzkaller run), the loop runs past i =3D 0x7FFFFFFF: i++ wraps to 0x8000000= 0, which as a signed int is negative. The address computation for &array->ptrs[i] sign-extends the 32-bit index (sxtw on arm64) into a 64-bit negative offset: array + sxtw(0x80000000) * 8 + offsetof(bpf_array, ptrs) =3D array + 0xFFFFFFFC00000000 + 0x108 -> wraps to an unmapped address, level-1 translation fault, panic This is reachable today because the existing overflow backstop in array_map_alloc() lives inside the `if (!bypass_spec_v1)` block. Since commit 2c78ee898d8f ("bpf: Implement CAP_BPF") renamed the old `if (unpriv)` guard to `if (!bypass_spec_v1)`, the semantics inverted: a root caller with CAP_PERFMON (or mitigations=3Doff) takes the bypass path and skips the -E2BIG check entirely, so the raw attr->max_entries is stored into map->max_entries unchanged and the ~32 GB vmalloc (overcommit) region is handed out. The earlier unprivileged-path fix for max_entries overflow was carried along into the bypass block, so it does not cover the root path described here. Reject max_entries > INT_MAX in array_map_alloc_check(), the common entry point shared by all callers including the bypass path. This mirrors the existing value_size > INT_MAX guard a few lines above. The cut half of the u32 range (0x80000000..0xFFFFFFFF) cannot back a usable map today: - a prog_array at the lower bound already needs ~16 GB of contiguous virtual memory (and ~32 GB for the 0xFF00000A value seen in the field), which either fails allocation or drives the system into OOM/softlockup long before becoming a working map; - legitimate prog_array usage is bounded by MAX_TAIL_CALL_CNT =3D 33 and typical array maps are orders of magnitude below INT_MAX. No valid BPF use case is affected; the change converts a deferred whole-system BUG_ON panic (or OOM/softlockup) into an accurate -E2BIG at creation time. Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF") Signed-off-by: meishaoming --- kernel/bpf/arraymap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index 248b4818178c..868bc9f66cdb 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -74,6 +74,9 @@ int array_map_alloc_check(union bpf_attr *attr) /* avoid overflow on round_up(map->value_size) */ if (attr->value_size > INT_MAX) return -E2BIG; + /* avoid signed int iterator overflow in fd_array_map_free() */ + if (attr->max_entries > INT_MAX) + return -E2BIG; /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) return -E2BIG; -- 2.50.1 (Apple Git-155) #/******=EF=BF=BD=EF=BF=BD=EF=BF=BD=CA=BC=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=E4=B8=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=D0=A1=EF= =BF=BD=D7=B9=EF=BF=BD=CB=BE=EF=BF=BD=C4=B1=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=CF=A2=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=DA=B7=EF=BF=BD=EF=BF=BD=CD=B8=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=D6=B7=EF=BF=BD=EF=BF=BD=EF=BF=BD=D0=B3=EF=BF=BD=EF=BF=BD=C4= =B8=EF=BF=BD=EF=BF=BD=CB=BB=EF=BF=BD=C8=BA=EF=BF=BD=E9=A1=A3=EF=BF=BD=EF=BF= =BD=D6=B9=EF=BF=BD=CE=BA=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=CE=BA=EF=BF=BD=EF=BF=BD=EF=BF=BD=CA= =BD=CA=B9=EF=BF=BD=C3=A3=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=C8=AB=EF= =BF=BD=EF=BF=BD=EF=BF=BD=F2=B2=BF=B7=D6=B5=EF=BF=BD=D0=B9=C2=B6=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=C6=A1=EF=BF=BD=EF=BF=BD=EF=BF=BD=C9=A2=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=CA=BC=EF=BF=BD= =EF=BF=BD=D0=B5=EF=BF=BD=EF=BF=BD=EF=BF=BD=CF=A2=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=CB=B1=EF=BF=BD=EF=BF=BD=CA=BC=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=E7=BB= =B0=EF=BF=BD=EF=BF=BD=EF=BF=BD=CA=BC=EF=BF=BD=CD=A8=D6=AA=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=CB=B2=EF=BF=BD=C9=BE=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=CA=BC=EF=BF=BD=EF=BF=BD=EF=BF=BD This e-mail and its att= achments contain confidential information from XIAOMI, which is intended on= ly for the person or entity whose address is listed above. Any use of the i= nformation contained herein in any way (including, but not limited to, tota= l or partial disclosure, reproduction, or dissemination) by persons other t= han the intended recipient(s) is prohibited. If you receive this e-mail in = error, please notify the sender by phone or email immediately and delete it= !******/#