* [PATCH] btrfs: unset left_info if it matches right_info
@ 2020-07-22 18:42 Josef Bacik
2020-07-22 18:45 ` [PATCH][v2] btrfs: only search for left_info if there is no right_info Josef Bacik
0 siblings, 1 reply; 3+ messages in thread
From: Josef Bacik @ 2020-07-22 18:42 UTC (permalink / raw)
To: linux-btrfs, kernel-team
The CVE referenced doesn't actually trigger the problem anymore because
of the tree-checker improvements, however the underlying issue can still
happen.
If we find a right_info, but rb_prev() is NULL, then we're the furthest
most item in the tree currently, and there will be no left_info.
However we'll still search from offset-1, which would return right_info
again which we store in left_info. If we then free right_info we'll
have free'd left_info as well, and boom, UAF. Instead fix this check so
that if we don't have a right_info we do the search for the left_info,
otherwise left_info comes from rb_prev or is simply NULL as it should
be.
Reference: CVE-2019-19448
Fixes: 963030817060 ("Btrfs: use hybrid extents+bitmap rb tree for free space")
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
fs/btrfs/free-space-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 6d961e11639e..37fd2fa1ac1f 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2298,7 +2298,7 @@ static bool try_merge_free_space(struct btrfs_free_space_ctl *ctl,
if (right_info && rb_prev(&right_info->offset_index))
left_info = rb_entry(rb_prev(&right_info->offset_index),
struct btrfs_free_space, offset_index);
- else
+ else if (!right_info)
left_info = tree_search_offset(ctl, offset - 1, 0, 0);
/* See try_merge_free_space() comment. */
--
2.24.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH][v2] btrfs: only search for left_info if there is no right_info
2020-07-22 18:42 [PATCH] btrfs: unset left_info if it matches right_info Josef Bacik
@ 2020-07-22 18:45 ` Josef Bacik
2020-07-27 11:55 ` David Sterba
0 siblings, 1 reply; 3+ messages in thread
From: Josef Bacik @ 2020-07-22 18:45 UTC (permalink / raw)
To: linux-btrfs, kernel-team
The CVE referenced doesn't actually trigger the problem anymore because
of the tree-checker improvements, however the underlying issue can still
happen.
If we find a right_info, but rb_prev() is NULL, then we're the furthest
most item in the tree currently, and there will be no left_info.
However we'll still search from offset-1, which would return right_info
again which we store in left_info. If we then free right_info we'll
have free'd left_info as well, and boom, UAF. Instead fix this check so
that if we don't have a right_info we do the search for the left_info,
otherwise left_info comes from rb_prev or is simply NULL as it should
be.
Reference: CVE-2019-19448
Fixes: 963030817060 ("Btrfs: use hybrid extents+bitmap rb tree for free space")
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
v1->v2:
- Fixed the title, I had changed the fix but forgot to change the title in v1
fs/btrfs/free-space-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 6d961e11639e..37fd2fa1ac1f 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2298,7 +2298,7 @@ static bool try_merge_free_space(struct btrfs_free_space_ctl *ctl,
if (right_info && rb_prev(&right_info->offset_index))
left_info = rb_entry(rb_prev(&right_info->offset_index),
struct btrfs_free_space, offset_index);
- else
+ else if (!right_info)
left_info = tree_search_offset(ctl, offset - 1, 0, 0);
/* See try_merge_free_space() comment. */
--
2.24.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH][v2] btrfs: only search for left_info if there is no right_info
2020-07-22 18:45 ` [PATCH][v2] btrfs: only search for left_info if there is no right_info Josef Bacik
@ 2020-07-27 11:55 ` David Sterba
0 siblings, 0 replies; 3+ messages in thread
From: David Sterba @ 2020-07-27 11:55 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs, kernel-team
On Wed, Jul 22, 2020 at 02:45:37PM -0400, Josef Bacik wrote:
> The CVE referenced doesn't actually trigger the problem anymore because
> of the tree-checker improvements, however the underlying issue can still
> happen.
What was the problem?
> If we find a right_info, but rb_prev() is NULL, then we're the furthest
> most item in the tree currently, and there will be no left_info.
> However we'll still search from offset-1, which would return right_info
> again which we store in left_info. If we then free right_info we'll
> have free'd left_info as well, and boom, UAF. Instead fix this check so
> that if we don't have a right_info we do the search for the left_info,
> otherwise left_info comes from rb_prev or is simply NULL as it should
> be.
>
> Reference: CVE-2019-19448
> Fixes: 963030817060 ("Btrfs: use hybrid extents+bitmap rb tree for free space")
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> v1->v2:
> - Fixed the title, I had changed the fix but forgot to change the title in v1
The title still repeats what the code does and left_info or right_info
are not terms that are understood without context (unlike eg. fs_info)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-07-27 11:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-22 18:42 [PATCH] btrfs: unset left_info if it matches right_info Josef Bacik
2020-07-22 18:45 ` [PATCH][v2] btrfs: only search for left_info if there is no right_info Josef Bacik
2020-07-27 11:55 ` David Sterba
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.