On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
(still slowly digesting the thread)
> Yeah, as you mentioned earlier, I'd agree that nesting is rarely
> useful. The only thing I'd want to be careful about is ordering/scope. I
> *think* it would just operate as a "goto" and things like the cleanup.h
> handlers wouldn't be involved: they operate when a scope is crossed
> like before. And I think the overflow result wouldn't be represented
> anywhere. i.e. the wrapped/truncated value wouldn't be stored:
>
> int func()
> {
> ...
> u8 __ob_trap product = 5;
> ...
> product = a * b; // if store is truncated, goto __overflow
> ...
> return product;
>
> __overflow:
> pr_info("%u\n", product); // shows "5"
> return -1;
> }
Note that there is a 'fun' problem with this in combination with
cleanup.h.
Something like:
int func()
{
u8 __ob_trap prod = 0;
scoped_guard (mutex, &my_lock) {
prod = a * b;
}
return prod;
__overflow:
// whatever
return -1;
}
is fine. *HOWEVER*, something like:
int func()
{
int __ob_trap size = base + count * extra;
int err;
struct my_obj *obj __cleanup(kfree) = kzalloc(size, GFP_KERNEL);
err = my_obj_init(obj);
if (err)
return ERR_PTR(err);
return_ptr(obj);
__overflow:
// what now..
return NULL;
}
is most terribly broken. Specifically, the goto will jump into the scope
of obj -- and that is not allowed.
