Bug 2383525 (CVE-2025-8197) - CVE-2025-8197 libsoup: Global-buffer-overflow
Summary: CVE-2025-8197 libsoup: Global-buffer-overflow
Keywords:
Status: NEW
Alias: CVE-2025-8197
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-07-25 16:15 UTC by OSIDB Bzimport
Modified: 2025-08-12 20:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-07-25 16:15:42 UTC
The `soup_header_name_to_string` function does not validate the `name` parameter passed in, and directly accesses `soup_headr_name_strings[name]`. The value of `name` is controllable, when `name` exceeds the index range of `soup_headr_name_string`, it will cause an out-of-bounds access.


in soup_header_name_to_string /libsoup/libsoup/soup-header-names.c:697
```
const char *soup_header_name_to_string (SoupHeaderName name)
{
        if (name == SOUP_HEADER_UNKNOWN)
                return NULL;

        return soup_headr_name_strings[name]; //crash here
}
```

Comment 2 Simon McVittie 2025-08-12 14:19:41 UTC
I was notified about this vulnerability by Debian's CVE monitoring. There didn't appear to be a corresponding upstream bug report for it, so I opened <https://gitlab.gnome.org/GNOME/libsoup/-/issues/465>.

> The value of `name` is controllable

It isn't obvious to me that this parameter can be set to an out-of-range value by an attacker. If it can (can it?), I think the correct fix would be to change the caller of soup_header_name_to_string() so that it does appropriate validation to ensure it cannot call that function with invalid parameters, rather than changing the function to tolerate invalid use.

(This is the same reasoning as preventing applications from calling strlen(NULL), rather than changing strlen() to tolerate a NULL parameter.)

Red Hat appears to be the CNA that issued this CVE, so I hope that someone inside Red Hat has the necessary information about whether/how this is really exploitable. Please could someone from Red Hat share more information about the circumstances under which an attacker could trigger this undefined behaviour, either on the upstream issue, on a separate confidential upstream issue, or by private communication with the maintainers?

Comment 3 Michael Catanzaro 2025-08-12 20:11:13 UTC
I've just left a comment in your upstream issue. Suffice to say this CVE looks entirely bogus. I will ask Red Hat to retract it.


Note You need to log in before you can comment on or make changes to this bug.