On Wed, 24 Jul 2019 at 12:55, Steven Whitehouse wrote:
> On 24/07/2019 11:27, Christoph Hellwig wrote:
> > On Wed, Jul 24, 2019 at 11:22:46AM +0100, Steven Whitehouse wrote:
> >> and it would have the same effect, so far as I can tell. I don't mind
> >> changing it, if that is perhaps a clearer
Hi,
On 24/07/2019 11:27, Christoph Hellwig wrote:
On Wed, Jul 24, 2019 at 11:22:46AM +0100, Steven Whitehouse wrote:
and it would have the same effect, so far as I can tell. I don't mind
changing it, if that is perhaps a clearer way to write the same thing,
rather than >i_inode;
The cleanest
On Wed, Jul 24, 2019 at 11:22:46AM +0100, Steven Whitehouse wrote:
> and it would have the same effect, so far as I can tell. I don't mind
> changing it, if that is perhaps a clearer way to write the same thing,
> rather than >i_inode;
The cleanest thing is to not rely on any of that magic and
Hi,
On 24/07/2019 11:02, Christoph Hellwig wrote:
On Wed, Jul 24, 2019 at 09:48:38AM +0100, Steven Whitehouse wrote:
Hi,
On 24/07/2019 09:43, Jia-Ju Bai wrote:
In gfs2_alloc_inode(), when kmem_cache_alloc() on line 1724 returns
NULL, ip is assigned to NULL. In this case, "return >i_inode"
On 24/07/2019 11:02, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 09:48:38AM +0100, Steven Whitehouse wrote:
>> Hi,
>>
>> On 24/07/2019 09:43, Jia-Ju Bai wrote:
>>> In gfs2_alloc_inode(), when kmem_cache_alloc() on line 1724 returns
>>> NULL, ip is assigned to NULL. In this case, "return
On Wed, Jul 24, 2019 at 09:48:38AM +0100, Steven Whitehouse wrote:
> Hi,
>
> On 24/07/2019 09:43, Jia-Ju Bai wrote:
> > In gfs2_alloc_inode(), when kmem_cache_alloc() on line 1724 returns
> > NULL, ip is assigned to NULL. In this case, "return >i_inode" will
> > cause a null-pointer dereference.
On Wed, Jul 24, 2019 at 04:43:03PM +0800, Jia-Ju Bai wrote:
> index 0acc5834f653..c07c3f4f8451 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -1728,8 +1728,9 @@ static struct inode *gfs2_alloc_inode(struct
> super_block *sb)
> memset(>i_res, 0, sizeof(ip->i_res));
>
Thanks for the reply :)
On 2019/7/24 17:04, Steven Whitehouse wrote:
Hi,
On 24/07/2019 09:50, Jia-Ju Bai wrote:
In gfs2_rgrp_bh_get, there is an if statement on line 1191 to check
whether "rgd->rd_bits[0].bi_bh" is NULL.
That is how we detect whether the rgrp has already been read in, so
Hi,
On 24/07/2019 09:50, Jia-Ju Bai wrote:
In gfs2_rgrp_bh_get, there is an if statement on line 1191 to check
whether "rgd->rd_bits[0].bi_bh" is NULL.
That is how we detect whether the rgrp has already been read in, so the
function is skipped in the case that we've already read in the rgrp.
In gfs2_rgrp_bh_get, there is an if statement on line 1191 to check
whether "rgd->rd_bits[0].bi_bh" is NULL.
When "rgd->rd_bits[0].bi_bh" is NULL, it is used on line 1216:
gfs2_rgrp_in(rgd, (rgd->rd_bits[0].bi_bh)->b_data);
and on line 1225:
gfs2_rgrp_ondisk2lvb(...,
Hi,
On 24/07/2019 09:43, Jia-Ju Bai wrote:
In gfs2_alloc_inode(), when kmem_cache_alloc() on line 1724 returns
NULL, ip is assigned to NULL. In this case, "return >i_inode" will
cause a null-pointer dereference.
To fix this null-pointer dereference, NULL is returned when ip is NULL.
This bug
In gfs2_alloc_inode(), when kmem_cache_alloc() on line 1724 returns
NULL, ip is assigned to NULL. In this case, "return >i_inode" will
cause a null-pointer dereference.
To fix this null-pointer dereference, NULL is returned when ip is NULL.
This bug is found by a static analysis tool STCheck
12 matches
Mail list logo
