Re: [PATCH 4.4 01/13] GFS2: don't set rgrp gl_object until it's inserted into rgrp tree

[Sasha Levin <sashal@kernel.org>]

On Wed, Aug 28, 2019 at 12:09:06AM +0100, Ben Hutchings wrote:
>From: Bob Peterson <rpeterso@redhat.com>
>
>commit 36e4ad0316c017d5b271378ed9a1c9a4b77fab5f upstream.
>
>Before this patch, function read_rindex_entry would set a rgrp
>glock's gl_object pointer to itself before inserting the rgrp into
>the rgrp rbtree. The problem is: if another process was also reading
>the rgrp in, and had already inserted its newly created rgrp, then
>the second call to read_rindex_entry would overwrite that value,
>then return a bad return code to the caller. Later, other functions
>would reference the now-freed rgrp memory by way of gl_object.
>In some cases, that could result in gfs2_rgrp_brelse being called
>twice for the same rgrp: once for the failed attempt and once for
>the "real" rgrp release. Eventually the kernel would panic.
>There are also a number of other things that could go wrong when
>a kernel module is accessing freed storage. For example, this could
>result in rgrp corruption because the fake rgrp would point to a
>fake bitmap in memory too, causing gfs2_inplace_reserve to search
>some random memory for free blocks, and find some, since we were
>never setting rgd->rd_bits to NULL before freeing it.
>
>This patch fixes the problem by not setting gl_object until we
>have successfully inserted the rgrp into the rbtree. Also, it sets
>rd_bits to NULL as it frees them, which will ensure any accidental
>access to the wrong rgrp will result in a kernel panic rather than
>file system corruption, which is preferred.
>
>Signed-off-by: Bob Peterson <rpeterso@redhat.com>
>[bwh: Backported to 4.4: adjust context]
>Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>

I've queued the series up, thanks Ben!

--
Thanks,
Sasha