Re: [RFC] Mitigating unexpected arithmetic overflow

[Matthew Wilcox]

On Wed, May 08, 2024 at 11:11:35PM -0700, Kees Cook wrote:
>       Or even just simple math between u8s:
> 
>       while (xas->xa_offset == 255) {
>               xas->xa_offset = xas->xa_node->offset - 1;
> 
>       Is it expecting to wrap (truncate)? How is it distinguished from
>       the "num_elems++" case?

Hi ;-)

This looks to me like it's walking up the tree, looking to go to the
'prev' element.  So yes, the wrapping from 0 to 255 is intentional,
because once we find an offset that's not 0, we've set offset to the
right one.  Just to give more context, here's the few lines around it:

        if (xas->xa_offset != get_offset(xas->xa_index, xas->xa_node))
                xas->xa_offset--;

        while (xas->xa_offset == 255) {
                xas->xa_offset = xas->xa_node->offset - 1;
                xas->xa_node = xa_parent(xas->xa, xas->xa_node);
                if (!xas->xa_node)
                        return set_bounds(xas);
        }

So it's kind of nasty.  I don't want to write it as:

        while (xas->xa_offset == 0) {
                xas->xa_offset = xas->xa_node->offset;
                xas->xa_node = xa_parent(xas->xa, xas->xa_node);
        }
        xas->xa_offset--;

because there's that conditional subtraction before the loop starts.
The xarray test-suite is pretty good if anyone thinks they have a clearer
way to write this loop ...