Files
linux/fs/gfs2
Bob Peterson d61e517e39 GFS2: don't set rgrp gl_object until it's inserted into rgrp tree
commit 36e4ad0316 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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-06 10:18:11 +02:00
..
2014-03-19 15:16:24 +00:00
2018-09-26 08:35:05 +02:00
2014-03-03 13:50:12 +00:00
2018-05-30 07:49:13 +02:00
2019-06-11 12:23:53 +02:00
2015-10-29 12:57:48 -05:00
2015-10-29 12:57:48 -05:00
2017-07-15 11:57:46 +02:00
2013-06-14 11:17:15 +01:00
2013-06-03 14:20:18 -07:00
2014-05-14 10:04:34 +01:00
2015-10-29 12:57:48 -05:00
2018-05-30 07:49:13 +02:00
2015-01-13 10:48:57 +00:00
2015-05-05 13:23:22 -05:00