lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 25 Aug 2022 10:07:46 +0200 From: Juergen Gross <jgross@...e.com> To: Jan Beulich <jbeulich@...e.com> Cc: Stefano Stabellini <sstabellini@...nel.org>, Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>, stable@...r.kernel.org, Rustam Subkhankulov <subkhankulov@...ras.ru>, xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] xen/privcmd: fix error exit of privcmd_ioctl_dm_op() On 25.08.22 09:38, Jan Beulich wrote: > On 24.08.2022 16:26, Juergen Gross wrote: >> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() >> potentially with pages being NULL, leading to a NULL dereference. >> >> Fix that by calling unlock_pages only if lock_pages() was at least >> partially successful. >> >> Cc: <stable@...r.kernel.org> >> Fixes: ab520be8cd5d ("xen/privcmd: Add IOCTL_PRIVCMD_DM_OP") >> Reported-by: Rustam Subkhankulov <subkhankulov@...ras.ru> >> Signed-off-by: Juergen Gross <jgross@...e.com> > > Reviewed-by: Jan Beulich <jbeulich@...e.com> > albeit I wonder whether you did consider the variant actually > reducing code size (and avoiding the need for yet another label), > ... > >> --- a/drivers/xen/privcmd.c >> +++ b/drivers/xen/privcmd.c >> @@ -679,7 +679,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) >> rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned); >> if (rc < 0) { >> nr_pages = pinned; > > ... dropping this line and ... > >> - goto out; >> + goto unlock; >> } >> >> for (i = 0; i < kdata.num; i++) { >> @@ -691,8 +691,9 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) >> rc = HYPERVISOR_dm_op(kdata.dom, kdata.num, xbufs); >> xen_preemptible_hcall_end(); >> >> -out: >> + unlock: >> unlock_pages(pages, nr_pages); > > ... passing "pinned" here. Looking into this I found another problem: NOT using pinned is wrong, as lock_pages() doesn't guarantee that all pages were really locked. I think lock_pages() should return an error, in case pin_user_pages_fast() didn't lock as many pages es expected. Juergen Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes) Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists