linux-kernel - Re: [PATCH 2/2] iommu/amd: Destroy api

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jun 2016 17:53:15 +0000
From:	"Vesely, Jan" <Jan.Vesely@....com>
To:	"joro@...tes.org" <joro@...tes.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: [PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain

On Wed, 2016-06-15 at 13:54 +0200, joro@...tes.org wrote:
> On Thu, Jun 09, 2016 at 03:48:44PM +0000, Vesely, Jan wrote:
> > On Sat, 2016-05-21 at 14:11 -0400, Jan Vesely wrote:
> > > From: Jan Vesely <jan.vesely@....com>
> > > 
> > > Signed-off-by: Jan Vesely <jan.vesely@....com>
> > > ---
> > >  drivers/iommu/amd_iommu.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/iommu/amd_iommu.c
> > > b/drivers/iommu/amd_iommu.c
> > > index 17c76f2..4ff5e40 100644
> > > --- a/drivers/iommu/amd_iommu.c
> > > +++ b/drivers/iommu/amd_iommu.c
> > > @@ -3016,6 +3016,7 @@ static void protection_domain_free(struct
> > > protection_domain *domain)
> > >  
> > >  	del_domain_from_list(domain);
> > >  
> > > +	mutex_destroy(&domain->api_lock);
> > >  	if (domain->id)
> > >  		domain_id_free(domain->id);
> > >  
> > 
> > ping
> 
> Your patches lack commit messages, please add a more detailed
> description of what you are fixing and why. Please also add 'Fixes:'
> tags when resubmitting. The changes itself look good to me.

There are no specific bugs/oopses that these patches fix (that I'm
aware of). Both were found while I was familiarizing myself with the
code looking for memory corruption (which turned out to be [0]).
Either issue would be very difficult to hit in the wild and
mutex_destroy is empty unless you compile using CONFIG_DEBUG_MUTEXES.

Jan

[0] https://lkml.org/lkml/2016/3/7/1087

> 
> 
> 	Joerg
>