First published: Mon Jun 13 2011(Updated: )
hfs_find_init() is wrongly assuming that sb->ext_tree has already been opened and is not NULL but this function can be called when sb->ext_tree is currently being opened (NULL deref). Indeed when we have the following call path, the NULL deref. occurs: In hfs_mdb_get() we have (at this stage ext_tree == NULL): HFS_SB(sb)->ext_tree = hfs_btree_open(sb, HFS_EXT_CNID, hfs_ext_keycmp); hfs_btree_open() is calling read_mapping_page() which is indirectly a call to hfs_readpage(). Then hfs_readpage() can make the following calls: hfs_readpage() -> hfs_get_block() -> alloc_buffer_head() -> hfs_ext_read_extent() Then hfs_ext_read_extent() calls hfs_find_init() with an ext_tree == NULL. Then we have a NULL dereference in hfs_find_init(). ptr = kmalloc(tree->max_key_len (...)); Due to the huge call stack from hfs_btree_open() to hfs_find_init() there are many ways to fix this dereference but I can't find the proper way to fix it. Moreover if we look at the code in hfs_find_init(). 20 ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL); 21 if (!ptr) 22 return -ENOMEM; 23 fd->search_key = ptr; 24 fd->key = ptr + tree->max_key_len + 2; We can make "max_key_len * 2 + 4" wrap and have an fd->key pointing outside of the kmalloc()'ed space. Moreover we can make space in fd->search_key lower than max_key_len and bad things can occur. Reference: <a href="https://lkml.org/lkml/2011/6/8/154">https://lkml.org/lkml/2011/6/8/154</a> Acknowledgements: Red Hat would like to thank Clement Lecigne for reporting this issue.
Credit: secalert@redhat.com secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Linux Linux kernel | =2.6 | |
debian/linux-2.6 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.