linux-cve-announce - CVE-2024-47679: vfs: fix race between evice_inodes() and find

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2024102106-CVE-2024-47679-e793@gregkh>
Date: Mon, 21 Oct 2024 14:00:07 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-47679: vfs: fix race between evice_inodes() and find_inode()&iput()

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  ->spin_lock(inode)
  ->dec i_count to 0
  ->iput_final()                    generic_shutdown_super()
    ->__inode_add_lru()               ->evict_inodes()
      // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   ->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  ->find_inode()
    // found the above inode 261
    ->spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      ->__iget()
    ->spin_unlock(inode)                // schedule back
                                        ->spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  ->spin_unlock(inode)
  ->spin_lock(inode)			  ->evict()
  // dec i_count to 0
  ->iput_final()
    ->spin_unlock()
    ->evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.

The Linux kernel CVE team has assigned CVE-2024-47679 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 5.10.227 with commit 47a68c75052a
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 5.15.168 with commit 3721a6940329
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 6.1.113 with commit 540fb13120c9
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 6.6.54 with commit 0eed942bc65d
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 6.10.13 with commit 0f8a5b6d0daf
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 6.11.2 with commit 6c857fb12b91
	Issue introduced in 2.6.37 with commit 63997e98a3be and fixed in 6.12-rc1 with commit 88b1afbf0f6b

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-47679
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/inode.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195
	https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b
	https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1
	https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb
	https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1
	https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11
	https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687