Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751610AbdISUFA (ORCPT ); Tue, 19 Sep 2017 16:05:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:59810 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751341AbdISUE7 (ORCPT ); Tue, 19 Sep 2017 16:04:59 -0400 Date: Tue, 19 Sep 2017 22:04:55 +0200 Message-ID: From: Takashi Iwai To: Meng Xu Cc: Meng Xu , alsa-devel@alsa-project.org, perex@perex.cz, vlad@tsyrklevich.net, linux-kernel@vger.kernel.org, sanidhya@gatech.edu, taesoo@gatech.edu Subject: Re: [PATCH] ALSA: asihpi: fix a potential double-fetch bug when copying puhm In-Reply-To: <8b2e7d4a-6b77-ffed-176f-257219b9ecb5@gatech.edu> References: <1505798516-22482-1-git-send-email-mengxu.gatech@gmail.com> <8b2e7d4a-6b77-ffed-176f-257219b9ecb5@gatech.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 37 On Tue, 19 Sep 2017 15:54:22 +0200, Meng Xu wrote: > > Hi Takashi, > > Thanks for the reply. In my opinion, many security issues > are in fact unhandled corner cases and this could be one. > > In the first fetch, get_user(hm->h.size, (u16 __user *)puhm), > only 2 bytes from puhm are copied in and later it is ensured > that hm->h.size (which is also hm->m0.size given hm is a union) > is no larger than sizeof(*hm). However, this relation is broken > after the second fetch, copy_from_user(hm, puhm, hm->h.size). > > As a concrete example, a user could put 0x000A when the first > fetch happens which make hm->h.size <= sizeof(*hm) and later > races to change it to 0xFFFF in the second fetch. What makes it > even worse is this call: hpi_send_recv_f(&hm->m0, &hr->r0, file), > which sends &hm->m0 to a lot of destinations. If any of the > downstream functions assumes that hm->m0.size <= sizeof(*hm) > which is actually not, an exploit can be constructed. > > In fact, similar issues have caused vulnerabilities before as in > https://bugzilla.kernel.org/show_bug.cgi?id=116651 > https://bugzilla.kernel.org/show_bug.cgi?id=120131, > and more recently the fix in sched/perf > https://marc.info/?l=linux-kernel&m=150401225812533&w=2 > > Feel free to let us know your opinion. OK, now it's clearer, it's about the overwrite by the second copy_from_user() call. I took the patch as is now. thanks, Takashi