From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     "rtm@csail.mit.edu" <rtm@csail.mit.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: NFS client can crash server due to overrun in
 nfsd4_decode_bitmap4()
Thread-Topic: NFS client can crash server due to overrun in
 nfsd4_decode_bitmap4()
Thread-Index: AQHX2NFEStLOh5EPHEGsmzKRU+63DKwB8uQAgAAFgQCAAAGpAIAABxyAgABQQgA=
Date:   Sun, 14 Nov 2021 02:44:22 +0000
Message-ID: <421C8671-59D0-48B2-A03F-157BC65D653A@oracle.com>
References: <97860.1636837122@crash.local>
 <11B4530A-C0A0-4779-A9BA-F0E19B62C5A6@oracle.com>
 <20211113212544.GA27601@fieldses.org>
 <9A3E5D78-AE3C-4F45-8CB1-10F2EDA1D911@oracle.com>
 <20211113215707.GE27601@fieldses.org>
In-Reply-To: <20211113215707.GE27601@fieldses.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fQ3ShP88KWXRDqvFGOW/J+TIUt9d39J8Mdj8S6XNO6vrhi9PB8G/hMURZu+K?=
 =?us-ascii?Q?wfKsli+Areyk6c37Nvz1rBIJHMLJ0O6nkgvyxMPn2kIeSH4kV8+8PTVXVCGJ?=
 =?us-ascii?Q?2oPSwleh3AgLifEvfnOnhGHJ3TKAak4zIoCqM034bXvQDn7Zb2SHADxRTHXN?=
 =?us-ascii?Q?6ra4UAtnVQZTQBzmHIS5I33gpvorLV+cAWb+liH/y3C1I1ow+HNP5+JNbipv?=
 =?us-ascii?Q?Pr7TSL9uTDc7PoRuKw+YbScZC3EzFYokJvNdkkHH26WXKIgvPLOf16w6+pZt?=
 =?us-ascii?Q?Dgpnnouc8D/YfhkaUDr4p+xdJbnVzMEAUDQEaSi58wM7COLJukeHusgZgPn9?=
 =?us-ascii?Q?A7KmZSLK0cKbb07lnfn9m1VLPVpXs1jqP4GINf2lRKxpGdnnFHLImK+D+NsD?=
 =?us-ascii?Q?iyy+sOLwAAgzfZSQ1XMgNjoto+mT1MpM5TdeFRpxCjCGjHDE9+WBYTxoEKaR?=
 =?us-ascii?Q?Bl7diYYtU4M21RuZeCAdc9PK9uUQ1bBkTZPC1aSwZ7vdWCkARX7QKrYfHF6l?=
 =?us-ascii?Q?+o8dbfN657FgxEUMUjOxjHRCw4K54V/tzumi+wtvSO1iGCmwawpkzo2mtVCi?=
 =?us-ascii?Q?ip7yeqLn8OTp2fWeIG8sFa3/KhqlcyONOtn6U6dGOrMgKF8qSYD6zhs8Zv9q?=
 =?us-ascii?Q?xYpLagE6gB/JOPHNwYM4V8zFfqTJ3sC2LB+bDDDRBE1n4FJz/euVDr+dJEmB?=
 =?us-ascii?Q?wposzxahv7606FHLGn9LWzbOwLV2DM7ENjqFYz6A/jSSZb1HnhGwZJVwVxJM?=
 =?us-ascii?Q?PYtozo3BqCeCmyfLbohOcYU0bMh4TqJ8/uzgt/PRQ4RjjsifIC3KNL3T3f4L?=
 =?us-ascii?Q?cLdoimsWmvyg+JLAOfDILQADiVIDCdD23j8CCwRsMXA0mOAkX+98+1X4xeDh?=
 =?us-ascii?Q?iVds2CaNqKEZuRzEaSQNQlZtybOPHiIG73HWQigIUUEPsyDkXJrC0MI8+Tmm?=
 =?us-ascii?Q?WaH4BBVGHzO7GVWOPhz3u1uC6XqZZhZxGbu6dqqb4fvXksfLaviOGXsDFs1b?=
 =?us-ascii?Q?Txv+bmeR1xPneEcc9llwO/FGvasFk9QFDrZXT87skX/DMD44n0FsoEBv3yTD?=
 =?us-ascii?Q?4VgxQTkLFF4EK2lkEuJcsJ2rYh/JWcFgPlSTFZ63Lm7caozoTOzRwObqUr0b?=
 =?us-ascii?Q?nYDKeFCzLpa5Gma2/SoaRuxOQ7i7d8D5o8KGuVSITqtf/V/OC8wTS53H2b27?=
 =?us-ascii?Q?Nn0Q9LOHOZ6YQ2lwRG/dU0omEpeTo+/Ipyl7w6C7JzyMJb/O8n1DjdkizV8U?=
 =?us-ascii?Q?EhliOmaPArl5InCLZnvzD21cKcjo5Z4J8JgZXuoUtKyJ9BMXANjohevw6p6M?=
 =?us-ascii?Q?ROEnYcpX7o8J/WunOLzlAvBg7k7w+n04Ye7eXg0Hm25NqCZUsoXvD1BmIMbW?=
 =?us-ascii?Q?p8gIg+AZIP425vLz4klPJWEYlkZMkhqhiJFXZpIkF7nV/pXTXqsPkO5ltddM?=
 =?us-ascii?Q?6k5q5q9GRy+amtg2CPdbFvEaKHWkBJgqetAuUF44GQMeJxfaK9zVR1udDAVo?=
 =?us-ascii?Q?3XYD78q6crqwiu3spEtr+mqNYKpJarEqyZ7ZKXTX9CjiOxtl3SV+Yg2i0Fxu?=
 =?us-ascii?Q?kq3YbQ/38TPeLNbsF1roDLGQ6g37CujPd5ngX2gLwXMfe/j2uanLOjPgxMlN?=
 =?us-ascii?Q?ONrEV++7TpRYbAbEOCMrDZM=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D7785310B71A9242A6968197C7861806@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4688.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e0aced06-d074-4fe2-bb52-08d9a718aa68
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2021 02:44:22.8883
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6p1Qu6ud5MwYf3n3BtjJRKf84boet4OQ7qSkS6TrtHRFqQYoWdhm5yEAAicaHxLQdyZ1r8i9KVrE1vCSmzUksg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4164
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10167 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0
 adultscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000
 definitions=main-2111140012
X-Proofpoint-GUID: HPAFD58TwqVbG9EVPz5Yt-mq3Gr5e0KQ
X-Proofpoint-ORIG-GUID: HPAFD58TwqVbG9EVPz5Yt-mq3Gr5e0KQ
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Nov 13, 2021, at 4:57 PM, Bruce Fields <bfields@fieldses.org> wrote:
>=20
> On Sat, Nov 13, 2021 at 09:31:40PM +0000, Chuck Lever III wrote:
>> This allows the client to send bitmaps larger than bmval[],
>> as the old decoder did,
>=20
> Oh, thanks, right, I guess rejecting too-large bitmaps outright might
> cause compatibility problems with future implementations.
>=20
> (Hm, ideally, shouldn't we be checking whether bits are set beyond where
> we expect so that e.g. we can return NFS4ERR_ATTRNOTSUPP on operations
> that set attributes?  Perhaps that's more than is necessary; it's a
> separate issue, anyway.)

The spec might call for those bits to be ignored. The server would
simply not set those in the response. I believe that's how unsupported
bits are handled anyway, rather than returning an error response.

Also note that the "count > 1000" sanity check might be unneeded. If
the count is unrealistically large, it will cause the subsequent
xdr_inline_decode() to fail. I could send a separate patch to remove
that check if you agree.


>> and ensures that decode_bitmap()
>> cannot write farther than @bmlen into the bmval array.
>>=20
>>=20
>>> 		return nfserr_bad_xdr;
>>> 	p =3D xdr_inline_decode(argp->xdr, count << 2);
>>> 	if (!p)
>>=20
>> --
>> Chuck Lever

--
Chuck Lever