linux-kernel - Re: Sleep during spinlock in TPM driver

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-next>] [day] [month] [year] [list]

Date:	Sun, 22 Apr 2007 15:06:10 -0400 (EDT)
From:	Parag Warudkar <parag.warudkar@...il.com>
To:	akpm@...ux-foundation.org
cc:	dsk6@...t.edu, linux-kernel@...r.kernel.org
Subject: Re: Sleep during spinlock in TPM driver

Andrew Morton <akpm <at> linux-foundation.org> writes:

>
> On Fri, 20 Apr 2007 18:11:10 -0400 "David Kyle" <dsk6 <at> pitt.edu> 
wrote:
>
> > int tpm_release(struct inode *inode, struct file *file)
> > {
> >         struct tpm_chip *chip = file->private_data;
> >         spin_lock(&driver_lock);
> >         file->private_data = NULL;
> >         chip->num_opens--;
> >         del_singleshot_timer_sync(&chip->user_read_timer);
> >         flush_scheduled_work();
> >         atomic_set(&chip->data_pending, 0);
> >         put_device(chip->dev);
> >         kfree(chip->data_buffer);
> >         spin_unlock(&driver_lock);
> >         return 0;
> > }
> > EXPORT_SYMBOL_GPL(tpm_release);
> >
> > I believe that flush_scheduled_work can sleep, correct?  Does anyone
> > know why this function is called while the spinlock is held?
> >
>
> yup, that's a bug.  It's not immediately clear to e what driver_lock is
> protecting.  Some global things, some per-device things, it appears.
>
> A suitable fix might be to make driver_lock a mutex.
>

AFAICS, moving flush_scheduled_work before spin_lock() should 
not cause any problems.

Reason being - The only thing that can race against tpm_release is 
tpm_open (tpm_release is called when last reference to the file is closed 
and only thing that can happen after that is tpm_open??) and tpm_open 
acquires driver_lock and more over it bails out with EBUSY if 
chip->num_opens is greater than 0.

I also moved chip->num_pending-- to after deleting timer and setting data 
pending as it looks more correct for the paranoid although it probably 
doesn't matter as it is guarded by driver_lock. None the less this change 
should not cause problems.

While I was at it I noticed a missing NULL check in tpm_register_hardware 
which is fixed with this patch as well.

David - could you please try the below patch and see if it works? Thanks.

Signed-off-by: Parag Warudkar <parag.warudkar@...il.com>

--- linux-2.6-us/drivers/char/tpm/tpm.c	2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c	2007-04-22 14:58:51.957999963 -0400
@@ -942,12 +942,12 @@
   {
   	struct tpm_chip *chip = file->private_data;

+	flush_scheduled_work();
   	spin_lock(&driver_lock);
   	file->private_data = NULL;
-	chip->num_opens--;
   	del_singleshot_timer_sync(&chip->user_read_timer);
-	flush_scheduled_work();
   	atomic_set(&chip->data_pending, 0);
+	chip->num_opens--;
   	put_device(chip->dev);
   	kfree(chip->data_buffer);
   	spin_unlock(&driver_lock);
@@ -1097,8 +1097,13 @@

   	/* Driver specific per-device data */
   	chip = kzalloc(sizeof(*chip), GFP_KERNEL);
-	if (chip == NULL)
+	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ 
+	if (chip == NULL || devname == NULL) {
+		kfree(chip);
+		kfree(devname);
   		return NULL;
+	}

   	init_MUTEX(&chip->buffer_mutex);
   	init_MUTEX(&chip->tpm_mutex);
@@ -1124,7 +1129,6 @@

   	set_bit(chip->dev_num, dev_mask);

-	devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
   	scnprintf(devname, DEVNAME_SIZE, "%s%d", "tpm", chip->dev_num);
   	chip->vendor.miscdev.name = devname;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/