From nobody Mon Jun 15 07:34:00 2026 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (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 05CF33176E0 for ; Thu, 9 Apr 2026 02:06:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775700409; cv=none; b=RHIaXqpA79G75Qn6gCW+Tx5FSToSZbwEPUS3RJxIhWofvrqC85fEEGr4L6g8k9FRVsMzo8r3AFQJ527bznyEwmkZmem28t1aC6Hm3tqk2Yc+g9hmMO/huM6JnSlqJFxZmk5I9QMH6PSyMwGgUeR4OiBddz03aE1SOj1w6ZdEz6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775700409; c=relaxed/simple; bh=rdhFa3e2WMbChsZMzubZEXU7dpUFERhI2ba0DFYs5ZQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=JC7nXsfWfJhzel1LWkUCj45vfiA1u4xIpiRixiIIWF39AZJUPqltDIW3sT7apxTjsdXhWnLyDzlUYlVxYLDFKteqXIRf6RwbF257pfSTMwynogZXLFuJdcxcGeTKD3nfbXUBqJKWslKxoxjNyNqhsqPrF7zWmzPUjC2xzF2aIKw= 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=M31KUWYP; arc=none smtp.client-ip=209.85.160.171 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="M31KUWYP" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-506aa68065eso3218381cf.1 for ; Wed, 08 Apr 2026 19:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775700407; x=1776305207; 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=63JnZwKI8z1ZfG7CgudDISfXsVgf5kZG8BX74X0mHaU=; b=M31KUWYPdzAk6K8eEOrMF18HqO7NpBVQ20zV0x+ArVvUYaQSd0cPTpBfRm8I2zl4Wn +rHd6LcodaAFodHmAmnMESBaqv6pk7sJlg5aMqhjYPsd/3wTe57R4fH/zZtwiT3v3o8n hlTbrR4XV9J/WWPKa1TKezlkxVnTFWcp64i1NoJmiCHoDFBtYzXmrImjEI8ARMGB30hn YQYMoTHZN3jBeBiL+4yVL4m0VQU2rHP7HAQ+4gpzz4fSLb6ljCCM1fTv3p7qE4Ln0Tx2 II9fvwHYqrH2BYfklAwcD4lWCfZPEjTlRRt/gqhNQ5yc09n6J1v+cr8lUtf3D1AX+FEM jdbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775700407; x=1776305207; 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=63JnZwKI8z1ZfG7CgudDISfXsVgf5kZG8BX74X0mHaU=; b=MsC2gzUC3xBYJ43H2upGUc0XufdYtYfDNte9nor1qzOTXAMyZZ4cucl0QX7pe1MFLG aWgKcCZwW/afzUXK5IEgH/pxUN2TKhCtVezXUZKN5fbkHqv45knycRPE3TpRERT4GwfQ dn1L6I2BH0qNJ/Q6V4ub7f8vqLFPChcGJ7icwDYP1Tgqi5AKRmZpU4XRnn91fvC+I/sc DLCfUd+iL4gkTca+nV6RaV1taHMllwK9ggbkJ3GOXivC1ds+pllqUhOl6TNK2K7XSITj gvRbCs6S426TEDMG67NRd85p1iGvJOUWrnKScly7FmiYFDyArZL6b4sEAxv9Qt+aiGj5 e8sg== X-Gm-Message-State: AOJu0Yyig9swH48uOqxrHEHtXhrxNV/5ZcgIcgpyFKySVjnIdfGFP532 4L7TSkxobJ9+L40vbvUmJeoipSy4lwZLYMhvzAfSmcIJThed2ID6PE1T X-Gm-Gg: AeBDiet1tJFC7NHLQpSUo21VPaioncSR19LMA4RCkyh5IGTD/qa3vd4dHaH4akZa7lK NqdqqOBjAEhfH0woePRC36bePASuX0+LrFyJzt1s/OS3FB1rpeLy5f4VgJTtxIb7yF4nonrobdL tqkrCk4iZVshkJh4aXJtRDGQagZt1OBgtSxmicsl4EgKdER+5pkw3EOjvFkIcv+gFSfZGU3+jFk Q8bu9u6AdFV0pU0WbrTZ/iMKWGMrXE5eOPiRZ2ymt7Sh5fodZp1oYFxAQZ7361A92KdlhsPrMvl 3zqlCvN6tXFm511FS4Jld7gxC0uesy/8GAM0My4LGuKrTLlzgvToM4FR2+5eKHBNlXC4vipa7MI CWbn12VkTvzKI3jAP4FZ7TTfudDe9bcCNC1XvvgEJCPAScSrTSpcZOhVjLL0VRR0BT/v9kL+B0J ivJB9MXXYEgEfyvHhc2f48b+9Ymeiw4Rf9drQGH/nMh7blvr16sEd6LdQVhiZPu4kYCryfj172C jNjh/fRGtRAg/UcW27KEdvroGQHiHlQ9CUyT1o= X-Received: by 2002:a05:622a:a707:b0:50d:a8f5:1c0f with SMTP id d75a77b69052e-50da8f521b2mr96660731cf.24.1775700406862; Wed, 08 Apr 2026 19:06:46 -0700 (PDT) Received: from TDC4045031631.e0cglfehwr0e5gttmepj3hi3hf.ux.internal.cloudapp.net ([20.63.37.123]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50d4d4a034asm171684591cf.6.2026.04.08.19.06.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 19:06:46 -0700 (PDT) From: Ashutosh Desai To: Jan Kara Cc: linux-kernel@vger.kernel.org, Ashutosh Desai Subject: [PATCH] udf: fix potential heap buffer overflow in handle_partition_descriptor(). Date: Thu, 9 Apr 2026 02:06:45 +0000 Message-Id: <20260409020645.2059456-1-ashutoshdesai993@gmail.com> X-Mailer: git-send-email 2.34.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 Content-Type: text/plain; charset="utf-8" When the partition descriptor array needs to grow, the new allocation size is computed using the on-disk partitionNumber field rather than the number of entries that actually need to fit. If a UDF image presents 33 unique partition descriptors and the 33rd has a partitionNumber in the range 1..32, ALIGN(partnum, 32) returns 32 - the same as the existing allocation size. As a result the buffer does not grow, yet the new entry is written at index num_part_descs (now 32), one slot past the end of the 32-element array. This ends up corrupting 8 bytes of adjacent heap memory with the volDescSeqNum and block number taken from the on-disk descriptor, both of which are under the control of whoever crafted the image. On kernels where unprivileged users can mount filesystems (e.g. via user namespaces) this could be reached without any special privileges. The straightforward fix is to base the new size on how many entries actually need to be stored (num_part_descs + 1) instead of relying on an untrusted on-disk value for that purpose. Signed-off-by: Ashutosh Desai --- fs/udf/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/udf/super.c b/fs/udf/super.c index 27f463fd1..9505b5c14 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -1694,7 +1694,8 @@ static struct udf_vds_record *handle_partition_descri= ptor( return &(data->part_descs_loc[i].rec); if (data->num_part_descs >=3D data->size_part_descs) { struct part_desc_seq_scan_data *new_loc; - unsigned int new_size =3D ALIGN(partnum, PART_DESC_ALLOC_STEP); + unsigned int new_size =3D ALIGN(data->num_part_descs + 1, + PART_DESC_ALLOC_STEP); =20 new_loc =3D kzalloc_objs(*new_loc, new_size); if (!new_loc) --=20 2.34.1