Re: [PATCH v2 2/3] perf dwarf-aux: Add C++ vtable helpers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf dwarf-aux: DW_AT_virtuality presence check incorrectly skips non-virtual bases
- [Medium] perf dwarf-aux: infinite loop in C++ inheritance traversal on malformed DWARF
--

commit e1f1b87424c8d58d923a8c3fbc1408fa0ae0c3b9
Author: Yanbo Zhao <yzhao62@ncsu.edu>

perf dwarf-aux: Add C++ vtable helpers
    
Add DWARF helper functions needed to resolve C++ virtual function calls
statically in the data type profiling.

> diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
> index eb4b8f3475df1..b1f3dca057abb 100644
> --- a/tools/perf/util/dwarf-aux.c
> +++ b/tools/perf/util/dwarf-aux.c
> @@ -2293,6 +2293,222 @@ Dwarf_Die *die_get_member_type(Dwarf_Die *type_die, int offset,
> [ ... ]
> +static int __die_find_primary_base_cb(Dwarf_Die *die_mem, void *arg __maybe_unused)
> +{
> +	Dwarf_Attribute attr;
> +	Dwarf_Die base_die, vptr_die;
> +	Dwarf_Word loc;
> +
> +	if (dwarf_tag(die_mem) != DW_TAG_inheritance)
> +		return DIE_FIND_CB_SIBLING;
> +
> +	if (dwarf_attr_integrate(die_mem, DW_AT_virtuality, &attr))
> +		return DIE_FIND_CB_SIBLING;

[Severity: Medium]
Does this code incorrectly skip valid primary base classes when parsing DWARF 5?

DWARF 5 allows DW_AT_virtuality to be present with the default value
DW_VIRTUALITY_none (0x00).

If a compiler explicitly emits this default value, will the presence check
evaluate to true and falsely identify the non-virtual base as virtual,
skipping it?

> +
> +	if (die_get_data_member_location(die_mem, &loc) < 0 || loc != 0)
> [ ... ]
> +Dwarf_Die *die_find_virtual_func(Dwarf_Die *class_die, int index,
> +				 Dwarf_Die *die_mem)
> +{
> +	Dwarf_Die cur_die = *class_die;
> +	Dwarf_Die base_die;
> +
> +	while (die_is_compound_type(&cur_die)) {

[Severity: Medium]
Can this loop hang indefinitely when processing malformed DWARF?

If a maliciously crafted or malformed DWARF file contains cyclic inheritance,
die_get_real_type() resolves the type back to the current class.

Since the loop does not maintain a depth counter or cycle detection, does it
spin infinitely as it re-evaluates the same class type?

> +		if (die_find_child(&cur_die, __die_find_virtual_func_cb,
> +				   (void *)(long)index, die_mem))
> +			return die_mem;
> [ ... ]
> +Dwarf_Die *die_get_vptr_class(Dwarf_Die *type_die, int offset,
> +			      Dwarf_Die *die_mem)
> +{
> +	Dwarf_Die class_die = *type_die;
> +	Dwarf_Die vptr_class = *type_die;
> +	Dwarf_Die member_die, mb_type;
> +	Dwarf_Word loc;
> +
> +	while (die_is_compound_type(&class_die)) {

[Severity: Medium]
Similarly, does this loop also lack a depth limit or cycle detection when
traversing base class subobjects dynamically, risking infinite cycles on
malformed DWARF?

> +		if (die_find_child(&class_die, __die_find_member_offset_cb,
> +				   (void *)(long)offset, &member_die) == NULL)
> +			return NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930210038.196928-1-yzhao62@ncsu.edu?part=2