From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932951AbcIEJ5c (ORCPT ); Mon, 5 Sep 2016 05:57:32 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:58781 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932444AbcIEJ52 (ORCPT ); Mon, 5 Sep 2016 05:57:28 -0400 X-IronPort-AV: E=Sophos;i="5.30,286,1470693600"; d="scan'208";a="192079360" Date: Mon, 5 Sep 2016 11:56:38 +0200 From: Samuel Thibault To: Pavel Andrianov Cc: William Hubbs , Chris Brannon , Kirk Reiser , speakup@linux-speakup.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, Vaishali Thakkar , ldv-project@linuxtesting.org Subject: Re: A potential race in drivers/staging/speakup/speakup.ko Message-ID: <20160905095638.GL15376@var.bordeaux.inria.fr> Mail-Followup-To: Samuel Thibault , Pavel Andrianov , William Hubbs , Chris Brannon , Kirk Reiser , speakup@linux-speakup.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, Vaishali Thakkar , ldv-project@linuxtesting.org References: <2b13ceb6-9494-7bec-d0e5-8033c66a8721@ispras.ru> <20160905094317.GB15376@var.bordeaux.inria.fr> <58cca2ca-e73c-b7ae-9da9-36be6084caf4@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <58cca2ca-e73c-b7ae-9da9-36be6084caf4@ispras.ru> User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: > 05.09.2016 12:43, Samuel Thibault пишет: > >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > >>There is a potential race in drivers/staging/speakup/speakup.ko. > >>All operations with global pointers buff_in and buff_out are performed > >>without any locks. Thus, a simultaneous write (via synth_buffer_clear or > >>synth_buffer_add) to the pointers may lead to inconsistent data. > >> > >>Should a local lock be used here? > > > >AIUI, all callers of these functions have speakup_info.spinlock held. > > Regard a call stack > > -> synth_direct_store > -> synth_printf > -> synth_buffer_add > > The functions have not held speakup_info.spinlock. Apparently there is currently no caller of synth_direct_store and synth_store. But taking the lock here would be needed indeed. Samuel