On Thu, Jun 01, 2017 at 04:57:07PM +0800, Su Yue wrote:
> When reading out name from inode_ref, dir_item, it's possible that
> corrupted name_len leads to read beyond boundary.
> Since there are already patches for btrfs-progs, this patchset is
> for btrfs.
> 
> Introduce 'btrfs_is_namelen_valid' to make check namelen with
> item boundary.
> If read name from dir_item, use 'verify_dir_item' to do more strict
> check. Otherwise, use 'btrfs_is_namelen_valid'.
> 
> It's unnessary to do check before every read/memcmp_extent_buffer name.
> Checking namelen when read name for the first time in the call graph is
> enough.
> 
> Changlog:
> v2:
>       1.Change 'btrfs_check_namelen' to 'btrfs_is_namelen_valid'.
>       2.Split patches according call graph.

Now it looks much better, thanks. I briefly went through the patchset
and checked the callgraphs and haven't spotted any serious problems
(beyond what's been commented already).

The changelogs could be improved a bit, and mention how/where the extent
buffer is read for the first time. For example using btrfs_search_slot,
or by other means (like iterating leaves).

One thing that I'd still like to discuss: whether to use namelen or
name_len.  As name_len matches the member name, I think it should also
be used in the helper name and subject lines.

> Su Yue (9):
>   btrfs: Introduce btrfs_is_namelen_valid to avoid reading beyond
>     boundary
>   btrfs: Check namelen with boundary in verify dir_item
>   btrfs: Check name len on add_inode_ref call path
>   btrfs: Verify dir_item in 'replay_xattr_deletes'
>   btrfs: Check namelen in 'btrfs_check_ref_name_override'
>   btrfs: Check name before read in 'iterate_dir_item'
>   btrfs: Check namelen before read in 'btrfs_get_name'
>   btrfs: Check namelen before in 'btrfs_del_root_ref'
>   btrfs: Verify dir_item 'in iterate_object_props'

It's not necessary to quote the function in the subject.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to