From: Greg Kroah-Hartman Date: Thu, 19 Mar 2020 07:14:08 +0000 (+0100) Subject: drop locks-fix-a-potential-use-after-free-problem-when-wa.patch again X-Git-Tag: v4.4.217~22 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=de3ea1471c0a4ea2c79e2ee8e30172c42a5897c7;p=thirdparty%2Fkernel%2Fstable-queue.git drop locks-fix-a-potential-use-after-free-problem-when-wa.patch again --- diff --git a/queue-5.4/locks-fix-a-potential-use-after-free-problem-when-wa.patch b/queue-5.4/locks-fix-a-potential-use-after-free-problem-when-wa.patch deleted file mode 100644 index aa72e680197..00000000000 --- a/queue-5.4/locks-fix-a-potential-use-after-free-problem-when-wa.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 68edfb98d4afd5c15eaacf0c62d5ad0991c02e1b Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Wed, 4 Mar 2020 15:25:56 +0800 -Subject: locks: fix a potential use-after-free problem when wakeup a waiter -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -From: yangerkun - -[ Upstream commit 6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da ] - -'16306a61d3b7 ("fs/locks: always delete_block after waiting.")' add the -logic to check waiter->fl_blocker without blocked_lock_lock. And it will -trigger a UAF when we try to wakeup some waiter： - -Thread 1 has create a write flock a on file, and now thread 2 try to -unlock and delete flock a, thread 3 try to add flock b on the same file. - -Thread2 Thread3 - flock syscall(create flock b) - ...flock_lock_inode_wait - flock_lock_inode(will insert - our fl_blocked_member list - to flock a's fl_blocked_requests) - sleep -flock syscall(unlock) -...flock_lock_inode_wait - locks_delete_lock_ctx - ...__locks_wake_up_blocks - __locks_delete_blocks( - b->fl_blocker = NULL) - ... - break by a signal - locks_delete_block - b->fl_blocker == NULL && - list_empty(&b->fl_blocked_requests) - success, return directly - locks_free_lock b - wake_up(&b->fl_waiter) - trigger UAF - -Fix it by remove this logic, and this patch may also fix CVE-2019-19769. - -Cc: stable@vger.kernel.org -Fixes: 16306a61d3b7 ("fs/locks: always delete_block after waiting.") -Signed-off-by: yangerkun -Signed-off-by: Jeff Layton -Signed-off-by: Sasha Levin ---- - fs/locks.c | 14 -------------- - 1 file changed, 14 deletions(-) - -diff --git a/fs/locks.c b/fs/locks.c -index 44b6da0328426..426b55d333d5b 100644 ---- a/fs/locks.c -+++ b/fs/locks.c -@@ -753,20 +753,6 @@ int locks_delete_block(struct file_lock *waiter) - { - int status = -ENOENT; - -- /* -- * If fl_blocker is NULL, it won't be set again as this thread -- * "owns" the lock and is the only one that might try to claim -- * the lock. So it is safe to test fl_blocker locklessly. -- * Also if fl_blocker is NULL, this waiter is not listed on -- * fl_blocked_requests for some lock, so no other request can -- * be added to the list of fl_blocked_requests for this -- * request. So if fl_blocker is NULL, it is safe to -- * locklessly check if fl_blocked_requests is empty. If both -- * of these checks succeed, there is no need to take the lock. -- */ -- if (waiter->fl_blocker == NULL && -- list_empty(&waiter->fl_blocked_requests)) -- return status; - spin_lock(&blocked_lock_lock); - if (waiter->fl_blocker) - status = 0; --- -2.20.1 - diff --git a/queue-5.4/series b/queue-5.4/series index 86d004ad2f7..2db336a9ce2 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -49,5 +49,4 @@ net-rmnet-fix-bridge-mode-bugs.patch net-rmnet-fix-packet-forwarding-in-rmnet-bridge-mode.patch sfc-fix-timestamp-reconstruction-at-16-bit-rollover-.patch jbd2-fix-data-races-at-struct-journal_head.patch -locks-fix-a-potential-use-after-free-problem-when-wa.patch blk-mq-insert-flush-request-to-the-front-of-dispatch.patch diff --git a/queue-5.5/locks-fix-a-potential-use-after-free-problem-when-wa.patch b/queue-5.5/locks-fix-a-potential-use-after-free-problem-when-wa.patch deleted file mode 100644 index 2b3203d0fe5..00000000000 --- a/queue-5.5/locks-fix-a-potential-use-after-free-problem-when-wa.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 4cddc5e10cc4b3105fc8e2d13b1896d5c000958e Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Wed, 4 Mar 2020 15:25:56 +0800 -Subject: locks: fix a potential use-after-free problem when wakeup a waiter -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -From: yangerkun - -[ Upstream commit 6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da ] - -'16306a61d3b7 ("fs/locks: always delete_block after waiting.")' add the -logic to check waiter->fl_blocker without blocked_lock_lock. And it will -trigger a UAF when we try to wakeup some waiter： - -Thread 1 has create a write flock a on file, and now thread 2 try to -unlock and delete flock a, thread 3 try to add flock b on the same file. - -Thread2 Thread3 - flock syscall(create flock b) - ...flock_lock_inode_wait - flock_lock_inode(will insert - our fl_blocked_member list - to flock a's fl_blocked_requests) - sleep -flock syscall(unlock) -...flock_lock_inode_wait - locks_delete_lock_ctx - ...__locks_wake_up_blocks - __locks_delete_blocks( - b->fl_blocker = NULL) - ... - break by a signal - locks_delete_block - b->fl_blocker == NULL && - list_empty(&b->fl_blocked_requests) - success, return directly - locks_free_lock b - wake_up(&b->fl_waiter) - trigger UAF - -Fix it by remove this logic, and this patch may also fix CVE-2019-19769. - -Cc: stable@vger.kernel.org -Fixes: 16306a61d3b7 ("fs/locks: always delete_block after waiting.") -Signed-off-by: yangerkun -Signed-off-by: Jeff Layton -Signed-off-by: Sasha Levin ---- - fs/locks.c | 14 -------------- - 1 file changed, 14 deletions(-) - -diff --git a/fs/locks.c b/fs/locks.c -index 44b6da0328426..426b55d333d5b 100644 ---- a/fs/locks.c -+++ b/fs/locks.c -@@ -753,20 +753,6 @@ int locks_delete_block(struct file_lock *waiter) - { - int status = -ENOENT; - -- /* -- * If fl_blocker is NULL, it won't be set again as this thread -- * "owns" the lock and is the only one that might try to claim -- * the lock. So it is safe to test fl_blocker locklessly. -- * Also if fl_blocker is NULL, this waiter is not listed on -- * fl_blocked_requests for some lock, so no other request can -- * be added to the list of fl_blocked_requests for this -- * request. So if fl_blocker is NULL, it is safe to -- * locklessly check if fl_blocked_requests is empty. If both -- * of these checks succeed, there is no need to take the lock. -- */ -- if (waiter->fl_blocker == NULL && -- list_empty(&waiter->fl_blocked_requests)) -- return status; - spin_lock(&blocked_lock_lock); - if (waiter->fl_blocker) - status = 0; --- -2.20.1 - diff --git a/queue-5.5/series b/queue-5.5/series index badb6280328..a196d19dd2c 100644 --- a/queue-5.5/series +++ b/queue-5.5/series @@ -55,5 +55,4 @@ sfc-fix-timestamp-reconstruction-at-16-bit-rollover-.patch mlxsw-pci-wait-longer-before-accessing-the-device-af.patch net-dsa-mv88e6xxx-fix-masking-of-egress-port.patch jbd2-fix-data-races-at-struct-journal_head.patch -locks-fix-a-potential-use-after-free-problem-when-wa.patch blk-mq-insert-flush-request-to-the-front-of-dispatch.patch