From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751462AbcCIDrg (ORCPT ); Tue, 8 Mar 2016 22:47:36 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50639 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbcCIDrb (ORCPT ); Tue, 8 Mar 2016 22:47:31 -0500 Message-ID: <1457495231.27389.33.camel@decadent.org.uk> Subject: Re: [PATCH 4.4 13/74] cifs: fix out-of-bounds access in lease parsing From: Ben Hutchings To: Justin Maggard , Steve French Cc: stable@vger.kernel.org, Greg Kroah-Hartman , LKML Date: Wed, 09 Mar 2016 03:47:11 +0000 In-Reply-To: <20160308000315.712589111@linuxfoundation.org> References: <20160308000315.294406921@linuxfoundation.org> <20160308000315.712589111@linuxfoundation.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-e4/gV7biisNWC095Q0xu" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 2a02:8011:400e:2:b06c:6b7a:5449:a1ad X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-e4/gV7biisNWC095Q0xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-03-07 at 16:02 -0800, Greg Kroah-Hartman wrote: > 4.4-stable review patch.=C2=A0=C2=A0If anyone has any objections, please = let me know. >=20 > ------------------ >=20 > From: Justin Maggard >=20 > commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream. >=20 > When opening a file, SMB2_open() attempts to parse the lease state from t= he > SMB2 CREATE Response.=C2=A0=C2=A0However, the parsing code was not carefu= l to ensure > that the create contexts are not empty or invalid, which can lead to out- > of-bounds memory access.=C2=A0=C2=A0This can be seen easily by trying > to read a file from a OSX 10.11 SMB3 server.=C2=A0=C2=A0Here is sample cr= ash output: >=20 > BUG: unable to handle kernel paging request at ffff8800a1a77cc6 > IP: [] SMB2_open+0x804/0x960 > PGD 8f77067 PUD 0 > Oops: 0000 [#1] SMP > Modules linked in: > CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14 > Hardware name: NETGEAR ReadyNAS 314=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0/ReadyNAS 314=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0, BIOS 4.6.5 10/11/2012 > task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000 > RIP: 0010:[]=C2=A0=C2=A0[] SMB2_open+0x804/0x960 > RSP: 0018:ffff88005b31fa08=C2=A0=C2=A0EFLAGS: 00010282 > RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006 > RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0 > RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866 > R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800 > R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0 > FS:=C2=A0=C2=A000007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:000= 0000000000000 > CS:=C2=A0=C2=A00010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0 > Stack: > =C2=A0ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80 > =C2=A0ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000 > =C2=A0ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0 > Call Trace: > =C2=A0[] ? cifsConvertToUTF16+0x159/0x2d0 > =C2=A0[] smb2_open_file+0x98/0x210 > =C2=A0[] ? __kmalloc+0x1c/0xe0 > =C2=A0[] cifs_open+0x2a4/0x720 > =C2=A0[] do_dentry_open+0x1ff/0x310 > =C2=A0[] ? cifsFileInfo_get+0x30/0x30 > =C2=A0[] vfs_open+0x52/0x60 > =C2=A0[] path_openat+0x170/0xf70 > =C2=A0[] ? remove_wait_queue+0x48/0x50 > =C2=A0[] do_filp_open+0x79/0xd0 > =C2=A0[] ? __alloc_fd+0x3a/0x170 > =C2=A0[] do_sys_open+0x114/0x1e0 > =C2=A0[] SyS_open+0x19/0x20 > =C2=A0[] entry_SYSCALL_64_fastpath+0x12/0x6a > Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f= 1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75= 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8 > RIP=C2=A0=C2=A0[] SMB2_open+0x804/0x960 > =C2=A0RSP=20 > CR2: ffff8800a1a77cc6 > ---[ end trace d9f69ba64feee469 ]--- >=20 > Signed-off-by: Justin Maggard > Signed-off-by: Steve French > Signed-off-by: Greg Kroah-Hartman >=20 > --- > =C2=A0fs/cifs/smb2pdu.c |=C2=A0=C2=A0=C2=A024 ++++++++++++++---------- > =C2=A01 file changed, 14 insertions(+), 10 deletions(-) >=20 > --- a/fs/cifs/smb2pdu.c > +++ b/fs/cifs/smb2pdu.c > @@ -1109,21 +1109,25 @@ parse_lease_state(struct TCP_Server_Info > =C2=A0{ > =C2=A0 char *data_offset; > =C2=A0 struct create_context *cc; > - unsigned int next =3D 0; > + unsigned int next; > + unsigned int remaining; > =C2=A0 char *name; > =C2=A0 > =C2=A0 data_offset =3D (char *)rsp + 4 + le32_to_cpu(rsp->CreateContextsO= ffset); > + remaining =3D le32_to_cpu(rsp->CreateContextsLength); What if remaining is > the response length? > =C2=A0 cc =3D (struct create_context *)data_offset; > - do { > - cc =3D (struct create_context *)((char *)cc + next); > + while (remaining >=3D sizeof(struct create_context)) { > =C2=A0 name =3D le16_to_cpu(cc->NameOffset) + (char *)cc; > - if (le16_to_cpu(cc->NameLength) !=3D 4 || > - =C2=A0=C2=A0=C2=A0=C2=A0strncmp(name, "RqLs", 4)) { > - next =3D le32_to_cpu(cc->Next); > - continue; > - } > - return server->ops->parse_lease_buf(cc, epoch); > - } while (next !=3D 0); > + if (le16_to_cpu(cc->NameLength) =3D=3D 4 && > + =C2=A0=C2=A0=C2=A0=C2=A0strncmp(name, "RqLs", 4) =3D=3D 0) > + return server->ops->parse_lease_buf(cc, epoch); > + > + next =3D le32_to_cpu(cc->Next); > + if (!next) > + break; > + remaining -=3D next; What if next > remaining? This change seems to be only scratching the surface of the security failure here. Ben. > + cc =3D (struct create_context *)((char *)cc + next); > + } > =C2=A0 > =C2=A0 return 0; > =C2=A0} --=20 Ben Hutchings When in doubt, use brute force. - Ken Thompson --=-e4/gV7biisNWC095Q0xu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJW35y/AAoJEOe/yOyVhhEJKdYP/3LsHynMHgdkQ1XQy0HsSFrF zFArawF/5kRZsM6XWRXBc611W8X57MkSrC6em14BGTHXCIcY3QQdZmr5HgmRHlNz 80egzPx2bPz7jNH1LG3FB/MZtQmeGph3nkl3o7PQaXCnIzm5xwdjjJ2o4boTqYU3 N/2ogIPW7XrB981hRjshXgOdYDctzWjzgIj45zO7U6E9LsJfp/wYD6AdFkOHg4Df yUJWW8p0EzO7XruzPUgSPpeJsqiyF5TEM3tmbhSPm0QEpnhlrr7mnJ7KPTn1UJEj tzjNAkBoNRypqV3jZaEl7mMcSEBJrQo46JarE4elyVK9G3/48RLZK3riXDWtdlZY +eReBEfG0qDFFGBCa/R9A8tbbSu7nH36S7VK7KxaOQhZxPInSBlp3uVgJJ4xw+o2 wRSVFPY/Yr1LFhHYhDAPpNj8MFuJnNJ383Iimt/bQjvkbkVswMccPwe2C9i1C2wN uIZlmMBdxO32Rm7ZerI0DVow2UR0nrjD34SdbxMCxixNs2CCZrE+f+JcHstfzALk +zDOzO7F53LJw7w0+1CMJnu26slzG+pacO6wVXiHwhDJ0fTC0u8EmUZ4b3F5Jjfs adJ2alGhdnqYIpThf2/VP1clselFNYoAUbFYLDcLB7dgQCqBElL84DmzE0Dxkkkc Pm9bRLpIfv3acfgfIw9z =8li7 -----END PGP SIGNATURE----- --=-e4/gV7biisNWC095Q0xu--