netdev - Inconsistent lock state and possible irq lock inversion dependency detected in ax25.ko

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, 21 Nov 2007 23:13:31 +0100
From:	Bernard Pidoux <pidoux@....jussieu.fr>
To:	Alexey Dobriyan <adobriyan@...il.com>, ralf@...ux-mips.org
CC:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Inconsistent lock  state and possible irq lock inversion dependency
 detected in ax25.ko

Hi,

I am practicing intensively AX25 packet radio that uses ax25.ko together 
with mkiss, crc16, netrom, and rose modules using two PIII CPU Linux 
machines with 2.6.23.8 kernel.

On the first Linux machine I did not validate kernel hacking and AX25 
applications are running 100% of the time without serious problems.

On the second machine I validated kernel hacking and sooner or later I 
get exactly the same message after a connect timeout expires :

[ INFO: inconsistent lock state ]

The error seems to reside around ax25_disconnect+0x46/0xaf [ax25] that 
is called when an AX25 connect timeout or a connection failure occurs.
Connect timeout is probably activating
ax25_std_heartbeat_expiry+0x19/0xd3 [ax25]

The message is only displayed once on a boot session.

Ralf Baechle explained to me that ax25 code is very buggy and spinlocks 
difficult to trace.
However, as the cause of error is clearlHowever, as the cause of error 
is clearly identified and the y identified and the reported address is 
constant I suspect that an experienced programmer (which I am not) could 
trace the problem.

Moreover, I had the opportunity to catch a different message, that was 
longer than usual, and seem more explicit :

[ INFO: possible irq lock inversion dependency detected ]

Although the symptom is different it is related to the same origin :

fpac/4933 just changed the state of lock:
  (slock-AF_AX25){--..}, at: [<d8be3312>] ax25_disconnect+0x46/0xaf [ax25]

Whatever the running application is the inconsistent lock state could be 
observed with ax25_call, flexd, fpac ax25 application programms.

Please find attached a few reports captured from dmesg after each event.

Could someone look at the listing and identify the origin of the problem 
,if unique ?

Thanks.

Bernard Pidoux

View attachment "inconsistent_locks_report" of type "text/plain" (21621 bytes)