From nobody Mon Jun 8 17:46:40 2026 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (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 80DA043637D for ; Wed, 27 May 2026 16:30:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779899457; cv=none; b=a/lBWS6+5PXothUx6Bwb0YO0tNsk6/1gHG/pu8qWM6eZv9m/blivcRjYuJ4TGcK73UU3MQzPLFzDLHaTAPFIa9QdTIKIX7UeB5ekaBPJowBeVpMffQ+bQHsmQIBwsgm3Aag98YHcZZxGgAWZS4BIYtxP+JB6k/qod3fphwlAzFM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779899457; c=relaxed/simple; bh=au1B1idzmviqSEnIMRgvFiKgYlGG8vetxZSvl9tT9uI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fY17zxhv/bi5AhU//qRlFpd9bactJy/Ghj12VaBNvBIcSl+zBiUULdRdOoWrp4ofW4wMp8nhVlDClJ9bnzKk75Vn3v+nN0QdwGoyHMHmhKyUpUtOYPrO3nmEeqR6fmBenW7Od9qhKzMcOD20H5aEh2ECauRa6Y6fQebR6r79kgs= 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=dPzvUBxR; arc=none smtp.client-ip=74.125.224.54 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="dPzvUBxR" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-65eb1b25c77so6617536d50.0 for ; Wed, 27 May 2026 09:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779899454; x=1780504254; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=xHGOkpSqPyA6V8pXIPUUSy/4t7q9czhH9f99sPgTYbI=; b=dPzvUBxRs2lz45ZAVCqW2KHARZ+gHmtNU/zu6ve6RCsQQ5VyikFsZH16sr9I4dZyqr T8XST70RG4jdG2zWcQ0KBpFRu37SeOlxg9TtOuGjKwn9WgLpEYIHQgxAhizDs1OwWlvB G9CF5a0MWP1mODT2CXsxcjUtJENO69T8o6vxvB/2shMmS7l4h6oNc+x//CdkG/8ehSvT X7LiKndf6HEhiglnDpVgbKY9p8EP3G3+jisASii/u217mj6/K2xxcI/t76pmUBThxZEc GW4LU0lXgX/sfRq3a86jNAIIrtp2sAtDl1S3hfuzXX3g6TeiI4VKuEeOKGTI61y2NekA /jFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779899454; x=1780504254; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xHGOkpSqPyA6V8pXIPUUSy/4t7q9czhH9f99sPgTYbI=; b=IkZg52hg60rNX2ksxrTbdhVKR/4aoMBSV1jm5+qyl5XelpxtILheyNw2zvCxdYjdk+ ZCNJd3PtbKvVha2WK2X0U1PyPLx/pCD7/eXN6/IkV6VfCf8fdBVtUaAUjoLPXvdFFCZn TzF6c1KxKINBETHBk+q6R2ks1BVjb2NXJpUSzimxmA7Y0cxcSlaPEXuBY6bQzmpjc4DC xzLuwe7ZqY3LFR4Q2dwYUaCtBnxpfjqiku1SRBtLpuerxJby3spq/kVzAB2p/5Od3NF3 XbvW4anqkc2GYYDgH6VKsd6eym9+hlrFhztSaFNoLcbrbGby76+05Klc6+oK9tsyWdzg 95iw== X-Forwarded-Encrypted: i=1; AFNElJ/sDQMLWP2Lt4kX0gf6c5llokiUUSBMVZKTjaWg1FV8Gmwu5mh6cFmpr7MbA3PFhyOmNL5+xhrxpCoAAgY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0FQRNLy64+d2wvrzpFj8wO78Y5QuLyto/+0u8WvMvy0PVqkXH 45ffL0Gfl1R00xmVIv//TuCRmR6zXqn551m6XWs0my2RexW7ewF/y3ep X-Gm-Gg: Acq92OFQknwCgx8nF38kFbpxsKLeb+q13wbPcR1iVGW/+WCyTqsXOUC3XahLDwoKFyG vXTUL+lIubHHmciVJ4LjkI0RIPDNHeA5DwUGlRyrc5BYzjafGLxHW5O/6okrtjuJ9t6hNhLsxGq DRPHA9KjPwa3c69x/3K4UFHg5DJQGqgTM5Lf5JsN+0/P2Xn/BqZvCY2ivyODFQ8ME4GQ1WvP1Rs N+YgpN8XX0dIpINLJAY5NBB9B1WzANh+oj9y5NiyHR9JrZKGVfbiFL7nqYTR/9oBt/xXym+wOOg 4ssgsSXtx/Ydq4CdZkT6LMH93oW3qcUxe87/jrnWxzz0u+b/rDUA2Ffw4GMfWzrOQb97lqSE4GI i2+h6ZfxNCCsBhIEBk8LHfZkwP2O5Alk5eLrBgh1RZfbUpkbUX/CAQHS3BeTop8cad3Fnb9hfl2 KXLNEsZydixNrT1UBrJK3yAARfF1VYMY6zia7BZgSCZFg7zmIV0j13DMtXiPkmb33aH5og1b/OM 1IDHQMka5Fs/iZ/lKL/DWl9Dx35g01oOQMZTtNnV/WQ8waAt3m6kA== X-Received: by 2002:a05:690e:4289:20b0:657:1da9:7b36 with SMTP id 956f58d0204a3-65ec965ca03mr16989941d50.17.1779899454350; Wed, 27 May 2026 09:30:54 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8cc812e0413sm188819356d6.31.2026.05.27.09.30.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 09:30:53 -0700 (PDT) From: Michael Bommarito To: Trond Myklebust , Anna Schumaker Cc: Jeff Layton , Tom Haynes , Peng Tao , Kees Cook , Mike Snitzer , Tigran Mkrtchyan , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v2 1/2] NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr Date: Wed, 27 May 2026 12:30:35 -0400 Message-ID: <20260527163036.1524927-2-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260527163036.1524927-1-michael.bommarito@gmail.com> References: <20260527163036.1524927-1-michael.bommarito@gmail.com> 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" nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its "*str =3D NULL; return ret" tail, leaving buf NULL with a return value of 0. The "< 0" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client. Cc: stable@vger.kernel.org Fixes: 6b7f3cf96364 ("nfs41: pull decode_ds_addr from file layout to generi= c pnfs") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito --- Reproduced via a malicious NFSv4.1/pNFS server returning a flexfile GETDEVICEINFO body with multipath_count >=3D 3 and one valid (netid, uaddr) pair. Linux 7.0-rc7 + KASAN, QEMU/KVM. Stock kernel: Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:strrchr+0x24/0x80 Call Trace: nfs4_decode_mp_ds_addr+0xca/0x570 nfs4_ff_alloc_deviceid_node+0x357/0x1370 nfs4_find_get_deviceid+0x6b6/0xa90 nfs4_ff_layout_prepare_ds+0x3cf/0xa40 ff_layout_choose_ds_for_read+0x14c/0x350 ff_layout_pg_init_read+0x2a2/0xb90 ... nfs_file_splice_read+0xcf/0x190 do_sendfile+0x8eb/0xdf0 Kernel panic - not syncing: Fatal exception Deterministic for any multipath_count >=3D 3; multipath_count <=3D 2 does not crash because the loop ends before consuming the malformed trailing bytes. Patched kernel rejects the same crafted body and a baseline multipath_count =3D 1 mount + read completes normally. fs/nfs/pnfs_nfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/pnfs_nfs.c b/fs/nfs/pnfs_nfs.c index 12632a706da88..0ff43dbcb7cd7 100644 --- a/fs/nfs/pnfs_nfs.c +++ b/fs/nfs/pnfs_nfs.c @@ -1075,14 +1075,14 @@ nfs4_decode_mp_ds_addr(struct net *net, struct xdr_= stream *xdr, gfp_t gfp_flags) /* r_netid */ nlen =3D xdr_stream_decode_string_dup(xdr, &netid, XDR_MAX_NETOBJ, gfp_flags); - if (unlikely(nlen < 0)) + if (unlikely(nlen <=3D 0)) goto out_err; =20 /* r_addr: ip/ip6addr with port in dec octets - see RFC 5665 */ /* port is ".ABC.DEF", 8 chars max */ rlen =3D xdr_stream_decode_string_dup(xdr, &buf, INET6_ADDRSTRLEN + IPV6_SCOPE_ID_LEN + 8, gfp_flags); - if (unlikely(rlen < 0)) + if (unlikely(rlen <=3D 0)) goto out_free_netid; =20 /* replace port '.' with '-' */ --=20 2.53.0 From nobody Mon Jun 8 17:46:40 2026 Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 3700C439003 for ; Wed, 27 May 2026 16:30:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779899458; cv=none; b=dU9AsTCoEL7KkIa6js75TRWiWKZrC+G0hInmmaVrAdip6YmiHtlCKU3r95KfzAfnWz4qSreIZ4jNkB6UkByNPvviMe8POKogONS/yjBpwNcnqCXHsdrZV4YmcZEQY8bxGeSVcyz2BdeO4LAlx6Iw3788VAQPIfzC/fUMXnNZ1jA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779899458; c=relaxed/simple; bh=JNGzOcG5QMeYd5MA7ngdXnkn9vPeKX2Kslyj9FVCsKw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y7KUYjMEjQ0LqG3AZLewoZwXK9Ner8kEXWh/okG6nfRg7MuOrCpwoSH4QoTdsfK0B53XpKxk2Z7FuYLZ29TBdkAfzMTNGMW5SeUMaE+jeGotnS76o4TAnDC2BoP5rOzyRgPwovhaiWiwUha+rXBQXMJ0Qr7Sd3jSuy1A0kqE1rc= 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=ZVHrtEB8; arc=none smtp.client-ip=209.85.222.45 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="ZVHrtEB8" Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-95f6b47b309so2419407241.0 for ; Wed, 27 May 2026 09:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779899456; x=1780504256; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Ap86tkOp/ebDH9IC2+Z2JnCI+7L+9R6FqA6vt+enK7I=; b=ZVHrtEB8hxQWDMgh/YEaeaJQcicKukTxHxgxqOHWEfit2seOkYdJP6mBCGRBeomWzH FC5EuSGqfxR4G7ukhku6o57Nx67Yi/pLVFBKEu0sbMoLI4eSUN4t2Qz3w/FbxDXBrXnG QlLbHM7a6Cn625Ylv6GKVBXajhG5Q4mdJePGpcklhpv9tL5+ef5LLL1ZqF0yGGMwhTXD TGdPj5xBjlbznXMPVLC7VW4SDQZswrVhd5K2juFBHWJ5oaHs5WHEBWdd3jOJS+iUjLbv zhHeBMCzioO71YXQOYmRPBIKsLvE54AbdzLZ8Vx0K3UvIVPQLnVLgMYgFcjynJ+nJRvU DNrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779899456; x=1780504256; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Ap86tkOp/ebDH9IC2+Z2JnCI+7L+9R6FqA6vt+enK7I=; b=Pd43Wge5uuIIeMzklhj/IInO4aOKjoZC6CnhY9JkisEfFKGgH63hSZRv2DbkGI97RQ upu6I2rTAhC7F2JYHiNDoD3B3XfNpIcrHNqwpf9HK6OwaA93IYKj/zSJdXftqx0iEXwX 732X/F9aoEebgsMgPxvi5REDLwg8dfbzSBFbGwUULWq9Pb2R/sRQNah96o9tBXB+Tcmm L2oGX3SLYXtvQXg3EmxlabRGojhpcQs7vtrNnjwha0a8pCBPgAd7y6NMfveX/ioN3NB8 tQ+Nh+Kc8miaEr7v1RtBExjfQlzlo46h2dpKe2DrBoJrtsDh7E5Mbu2TsnJOnivWHCAV /PIQ== X-Forwarded-Encrypted: i=1; AFNElJ/Hqg2w6m65lqi4d9pjJEKkM2oTVuNf19TMb59k2dd95BNcF54z+RgKuP4hg+VWoB7TJecnH5WjX8rS7V8=@vger.kernel.org X-Gm-Message-State: AOJu0Yz29Affzvhn3ppZo1uZiUCgcyufuPo/6nrsvHj8hTQbjgpbQl+V 9v/as5F/K14HGMqMR1WZU0ZnpN7Cc47AexIzmAX+feMbMmP3yzG09ODa X-Gm-Gg: Acq92OFotNxqku/38jqqFTzXchGpoDsgxOGdVbgNhcmyu36QzLJxu5BDaX+uDBESgdn tOzcJcHPTdQ4zl5kYg/qeE4kHcmwAjJ9NHatT3KUq9OwQr0Z6ZGHs9+VKTNJ7PVFt6XVcrXuMLo sAr2whmvN7nQJHgyJ+DBQthRjwNAWGpyIeuNNPLVynm5XNjljSN6Yk1ep0lC41k9ZAViQQgFxjS K6g2iRwiJtX4CPp3tvlHFK1Mpbaf/m8z82ha4hLWByRwIEQIsjS41Y864R4wo3MdoUuDitLZQEg TFiHAnIeBo7GKUVLbkFnjIIz2+lys3AtMQ8A5NczZZBsD63ry/46LAYahf0ODXZtZt1jzvAci5l wMwPxbswsajFDlDkPMeRe9iwZtRNoV4jsSADinkcAqPDPbL+ntYPQZ1E79wTppF6h5YYnSUmwOO Re5unnTYmwCFi2h2dGOAx+dwoSLg03WlDnw6X+Gbe+rP2Bm2GA9qvfGZHSR5CQatw6r8PLxDMAT oc4OIyFoeCcerD/PFLpuA5yny8mZ+aiSONxnC4jeFylk6u9nMxxgA== X-Received: by 2002:a05:6102:3f08:b0:631:4d87:ba5f with SMTP id ada2fe7eead31-67c7490af39mr11660094137.3.1779899455976; Wed, 27 May 2026 09:30:55 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8cc812e0413sm188819356d6.31.2026.05.27.09.30.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 09:30:55 -0700 (PDT) From: Michael Bommarito To: Trond Myklebust , Anna Schumaker Cc: Jeff Layton , Tom Haynes , Peng Tao , Kees Cook , Mike Snitzer , Tigran Mkrtchyan , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v2 2/2] NFSv4/flexfile,filelayout: bound multipath DS count in GETDEVICEINFO Date: Wed, 27 May 2026 12:30:36 -0400 Message-ID: <20260527163036.1524927-3-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260527163036.1524927-1-michael.bommarito@gmail.com> References: <20260527163036.1524927-1-michael.bommarito@gmail.com> 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" Both the flexfile and the (legacy) file pNFS layout drivers decode a multipath-DS count from a server-supplied GETDEVICEINFO body and then iterate it via nfs4_decode_mp_ds_addr() without any upper bound. The filelayout driver already caps the outer ds_num against NFS4_PNFS_MAX_MULTI_CNT (=3D=3D 256) but applies no equivalent cap to the inner mp_count; the flexfile driver applies no cap on either. In addition, both inner loops ignore a NULL return from nfs4_decode_mp_ds_addr(), so once the on-wire data no longer matches a valid netaddr4 encoding the loop is free to consume the trailing bytes of the device_addr opaque as garbage netid + uaddr pairs. A malicious or compromised pNFS metadata server can therefore drive the inner loop indefinitely (up to 2^32 - 1 iterations) against a fixed-size 56-byte body, with each iteration triggering an allocation / kmemdup_nul cycle inside the decoder. Promote NFS4_PNFS_MAX_MULTI_CNT from the filelayout private header to include/linux/nfs4.h so both drivers (and any future pNFS layout driver that decodes a multipath address list) bound the wire-level field consistently. Apply the cap to the inner mp_count in both drivers, matching the existing ds_num check, and bail on the first NULL return so a server that lies about mp_count cannot quietly extend the loop into the trailing layout-body bytes. This is defense-in-depth on top of the companion patch which closes the NULL-deref in nfs4_decode_mp_ds_addr(); either patch alone closes the kernel-panic shape, both together close the latent unbounded-decode class. Cc: stable@vger.kernel.org Fixes: 35124a0994fc ("Cleanup XDR parsing for LAYOUTGET, GETDEVICEINFO") Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito --- Changes in v2: - Carry the stripe_index provenance comment from filelayout.h to the new NFS4_PNFS_MAX_MULTI_CNT location in include/linux/nfs4.h, as Anna requested. With this patch alone the crafted GETDEVICEINFO at multipath_count >=3D 3 is rejected at the bound check; malformed netaddr in the inner loop bails on the first NULL return. Either this patch or the companion 1/2 closes the panic; both together close the unbounded-decode class. Baseline multipath_count =3D 1 mount + read completes normally. fs/nfs/filelayout/filelayout.h | 2 +- fs/nfs/filelayout/filelayoutdev.c | 7 +++++-- fs/nfs/flexfilelayout/flexfilelayoutdev.c | 10 ++++++++-- include/linux/nfs4.h | 5 +++++ 4 files changed, 19 insertions(+), 5 deletions(-) diff --git a/fs/nfs/filelayout/filelayout.h b/fs/nfs/filelayout/filelayout.h index c7bb5da93307d..03298f2e7cd69 100644 --- a/fs/nfs/filelayout/filelayout.h +++ b/fs/nfs/filelayout/filelayout.h @@ -39,7 +39,7 @@ * RFC 5661 multipath_list4 structures. */ #define NFS4_PNFS_MAX_STRIPE_CNT 4096 -#define NFS4_PNFS_MAX_MULTI_CNT 256 /* 256 fit into a u8 stripe_index */ +/* NFS4_PNFS_MAX_MULTI_CNT now in ; shared with flexfile. */ =20 enum stripetype4 { STRIPE_SPARSE =3D 1, diff --git a/fs/nfs/filelayout/filelayoutdev.c b/fs/nfs/filelayout/filelayo= utdev.c index 7226989ee4d53..c58c786dcf011 100644 --- a/fs/nfs/filelayout/filelayoutdev.c +++ b/fs/nfs/filelayout/filelayoutdev.c @@ -159,10 +159,13 @@ nfs4_fl_alloc_deviceid_node(struct nfs_server *server= , struct pnfs_device *pdev, goto out_err_free_deviceid; =20 mp_count =3D be32_to_cpup(p); /* multipath count */ + if (mp_count > NFS4_PNFS_MAX_MULTI_CNT) + goto out_err_free_deviceid; for (j =3D 0; j < mp_count; j++) { da =3D nfs4_decode_mp_ds_addr(net, &stream, gfp_flags); - if (da) - list_add_tail(&da->da_node, &dsaddrs); + if (!da) + break; + list_add_tail(&da->da_node, &dsaddrs); } if (list_empty(&dsaddrs)) { dprintk("%s: no suitable DS addresses found\n", diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c b/fs/nfs/flexfilelay= out/flexfilelayoutdev.c index c40395ae08142..faed05cbe9f1c 100644 --- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c +++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c @@ -78,12 +78,18 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, = struct pnfs_device *pdev, goto out_err_drain_dsaddrs; mp_count =3D be32_to_cpup(p); dprintk("%s: multipath ds count %d\n", __func__, mp_count); + if (mp_count > NFS4_PNFS_MAX_MULTI_CNT) { + dprintk("%s: multipath count %u greater than supported maximum %d\n", + __func__, mp_count, NFS4_PNFS_MAX_MULTI_CNT); + goto out_err_drain_dsaddrs; + } =20 for (i =3D 0; i < mp_count; i++) { /* multipath ds */ da =3D nfs4_decode_mp_ds_addr(net, &stream, gfp_flags); - if (da) - list_add_tail(&da->da_node, &dsaddrs); + if (!da) + break; + list_add_tail(&da->da_node, &dsaddrs); } if (list_empty(&dsaddrs)) { dprintk("%s: no suitable DS addresses found\n", diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h index d87be1f25273a..79f4168cb6ab7 100644 --- a/include/linux/nfs4.h +++ b/include/linux/nfs4.h @@ -767,6 +767,11 @@ enum pnfs_block_extent_state { PNFS_BLOCK_NONE_DATA =3D 3, }; =20 +/* Maximum NFSv4.1 pNFS multipath data-server address count; + * 256 fits in the u8 stripe_index used by the filelayout driver. + */ +#define NFS4_PNFS_MAX_MULTI_CNT 256 + /* on the wire size of a block layout extent */ #define PNFS_BLOCK_EXTENT_SIZE \ (7 * sizeof(__be32) + NFS4_DEVICEID4_SIZE) --=20 2.53.0