On 2 Mar 2026, at 10:25, Ales Musil wrote:

> On Mon, Mar 2, 2026 at 9:56 AM Eelco Chaudron via dev <
> [email protected]> wrote:
>
>>
>>
>> On 27 Feb 2026, at 18:21, Mike Pattrick wrote:
>>
>>> On Thu, Feb 26, 2026 at 5:59 AM Eelco Chaudron via dev <
>>> [email protected]> wrote:
>>>
>>>> Coverity reports a tainted scalar issue (CID 368760) in the
>>>> log_received_backtrace() function. The function reads untrusted data
>>>> from a file descriptor into a backtrace structure but only validates
>>>> the upper bound of n_frames, not the lower bound. Fixes this by
>>>> checking both lower and upper bound.
>>>>
>>>> Fixes: 759a29dc2d97 ("backtrace: Extend the backtrace functionality.")
>>>> Signed-off-by: Eelco Chaudron <[email protected]>
>>>> ---
>>>>  lib/backtrace.c | 2 +-
>>>>  lib/util.h      | 4 ++++
>>>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/backtrace.c b/lib/backtrace.c
>>>> index 65c92fd72..2e68bbb81 100644
>>>> --- a/lib/backtrace.c
>>>> +++ b/lib/backtrace.c
>>>> @@ -149,7 +149,7 @@ log_received_backtrace(int fd)
>>>>      if (read_received_backtrace(fd, &bt, sizeof bt)) {
>>>>          struct ds ds = DS_EMPTY_INITIALIZER;
>>>>
>>>> -        bt.n_frames = MIN(bt.n_frames, BACKTRACE_MAX_FRAMES);
>>>> +        bt.n_frames = CLAMP(bt.n_frames, 0, BACKTRACE_MAX_FRAMES);
>>>>
>>>
>>> Is the new define needed? The rest of the code base uses MAX(.., MIN(...
>>
>> ACK, will change to:
>>
>> bt.n_frames = MIN(MAX(bt.n_frames, 0), BACKTRACE_MAX_FRAMES);
>>
>> Thanks for the review!
>>
>> //Eelco
>>
>
> Hi Eelco, just one question,
>
> I've found only the following that mentions a possibility of being <0:
>
> "The return value may be (size_t)(-1) instead of 0 on some platforms:
> FreeBSD 12.4/i386."
> https://www.gnu.org/software/gnulib/manual/html_node/backtrace.html
>
> For libunwind, it seems the value can never be less than 0. So I guess the
> check is really only for FreeBSD then right?

I was mainly trying to address the issues reported by Coverity and did not look 
closely at the implementation-specific behavior. But I think you are right that 
on FreeBSD this could potentially happen.

//Eelco

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to