linux-kernel - [BUG] media: dvb: dib9000: buggy locking

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

Message-ID: <20110119131010.GA10321@albatros>
Date:	Wed, 19 Jan 2011 16:10:10 +0300
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	Patrick Boettcher <patrick.boettcher@...com.fr>,
	Olivier Grenie <olivier.grenie@...com.fr>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [BUG] media: dvb: dib9000: buggy locking

Hi,

I've noticed that locking in drivers/media/dvb/frontends/dib9000.c is
not correct:

static int dib9000_fw_get_channel(...)
{
    ...
	DibAcquireLock(&state->platform.risc.mem_mbx_lock);
    ...

error:
	DibReleaseLock(&state->platform.risc.mem_mbx_lock);
	return ret;
}

#define DibAcquireLock(lock) do { if (mutex_lock_interruptible(lock) < 0) dprintk("could not get the lock"); } while (0)
#define DibReleaseLock(lock) mutex_unlock(lock)


1) If mutex is not hold, then the critical section is not protected.

2) If mutex was not hold, then the code tries to release not holded
mutex.


This locking "style" is used all over the driver.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/