linux-kernel - [RFC] inode.i_opflags - Usage of two different locking schemes

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:   Fri, 5 Mar 2021 14:10:09 +0100
From:   Alexander Lochmann <alexander.lochmann@...dortmund.de>
To:     Horst Schirmeier <horst.schirmeier@...dortmund.de>,
        Jan Kara <jack@...e.cz>, "Theodore Ts'o" <tytso@....edu>,
        Jan Kara <jack@...e.com>, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [RFC] inode.i_opflags - Usage of two different locking schemes

Hi folks,

I've stumbled across an interesting locking scheme. It's related to 
struct inode, more precisely it is an mqueue inode.
Our results show that inode:mqueue.i_opflags is read with i_rwsem being 
hold.
In d_flags_for_inode, and do_inode_permission the i_lock is used to read 
and write i_opflags.
Is this a real locking scheme? Is a lock needed to access i_opflags at all?
What is the magic behind this contradiction?

I've put the report of the counterexamples on our webserver: 
https://ess.cs.tu-dortmund.de/lockdoc-bugs/cex-inode-mqueue.html.
It contains the stacktraces leading to those accesses, and the locks 
that were actually held.

Regards,
Alex

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)