netdev - Possible dangling mutex_lock in function (rfcomm_tty_open) in file(linux3.3/net/bluetooth/rfcomm/tty.c)

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: <CAFZT-jJuPPK_EQbv-mJ8Dm9nXBJhfViuxvedAK-agJB2GF1Oaw@mail.gmail.com>
Date:	Wed, 20 Aug 2014 11:37:37 -0500
From:	Ahmed Tamrawi <ahmedtamrawi@...il.com>
To:	netdev@...r.kernel.org
Subject: Possible dangling mutex_lock in function (rfcomm_tty_open) in file(linux3.3/net/bluetooth/rfcomm/tty.c)

Bug Report Filed: https://bugzilla.kernel.org/show_bug.cgi?id=82881
Linux Version [3.3]
Configuration: Default configuration for x86

Function Source:
http://lxr.free-electrons.com/source/net/bluetooth/rfcomm/tty.c?v=3.3#L669

In function (rfcomm_tty_open) in file(linux3.3/net/bluetooth/rfcomm/tty.c):

The mutex object locked by (tty_lock) at line 728 can possibly kept
locked after exiting the function when one of the breaks at lines
(715, 719, or 723) is executed. Causing race conditions if multiple
calls to the same functions occurs with the same errors. Or causing
dangling lock to the mutex object held by (tty_lock).

A possible solution is to call (tty_unlock) upon exiting the function.
Possibly before the break points at lines (715, 719, or 723).

Thanks,
Ahmed
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html