linux-cve-announce - CVE-2024-50229: nilfs2: fix potential deadlock with newly created symlinks

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: <2024110929-CVE-2024-50229-c18d@gregkh>
Date: Sat,  9 Nov 2024 11:15:37 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-50229: nilfs2: fix potential deadlock with newly created symlinks

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

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

nilfs2: fix potential deadlock with newly created symlinks

Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.

This is because after commit 21fc61c73c39 ("don't put symlink bodies in
pagecache into highmem"), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().

This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs->ns_segctor_sem is held:

Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.

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

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

	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 4.19.323 with commit cc38c596e648
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 5.4.285 with commit a1686db1e59f
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 5.10.229 with commit c72e0df0b56c
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 5.15.171 with commit 69548bb663fc
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 6.1.116 with commit 58c7f44c7b9e
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 6.6.60 with commit 1246d86e7bbd
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 6.11.7 with commit 9aa5d43ac4ca
	Issue introduced in 4.5 with commit 21fc61c73c39 and fixed in 6.12-rc6 with commit b3a033e3ecd3
	Issue introduced in 4.4.116 with commit 076e4ab3279e

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-50229
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/nilfs2/namei.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/cc38c596e648575ce58bfc31623a6506eda4b94a
	https://git.kernel.org/stable/c/a1686db1e59f8fc016c4c9361e2119dd206f479a
	https://git.kernel.org/stable/c/c72e0df0b56c1166736dc8eb62070ebb12591447
	https://git.kernel.org/stable/c/69548bb663fcb63f9ee0301be808a36b9d78dac3
	https://git.kernel.org/stable/c/58c7f44c7b9e5ac7e3b1e5da2572ed7767a12f38
	https://git.kernel.org/stable/c/1246d86e7bbde265761932c6e2dce28c69cdcb91
	https://git.kernel.org/stable/c/9aa5d43ac4cace8fb9bd964ff6c23f599dc3cd24
	https://git.kernel.org/stable/c/b3a033e3ecd3471248d474ef263aadc0059e516a