|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2019-25074: frr: memory leak in the IS-IS daemon may lead to server memory exhaustion | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Carlos López <carlos.lopez> |
| Component: | Incidents | Assignee: | Security Team bot <security-team> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | carlos.lopez, jsegitz, mardnh, smash_bz |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://smash.suse.de/issue/338549/ | ||
| Whiteboard: | CVSSv3.1:SUSE:CVE-2019-25074:5.3:(AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) | ||
| Found By: | Security Response Team | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | 1196957 | ||
| Bug Blocks: | |||
This does not affect the versions we ship. (In reply to Carlos López from comment #1) > This does not affect the versions we ship. This is not true any more, since we've applied bug 1196505 aka CVE-2022-26125 fix, see: https://build.suse.de/package/view_file/home:mtomaschewski:branches:SUSE:SLE-15-SP3:Update/frr/0005-isisd-fix-router-capability-TLV-parsing-issues.patch?expand=1 Submission request to SLE is in https://build.suse.de/request/show/279073 Submission request to network is in https://build.opensuse.org/request/show/1001418 (In reply to Marius Tomaschewski from comment #8) > Submission request to network is in > https://build.opensuse.org/request/show/1001418 On the way to factory now in https://build.opensuse.org/request/show/1001456 Assigning back to security-team. SUSE-SU-2022:3246-1: An update that fixes two vulnerabilities is now available. Category: security (important) Bug References: 1202022,1202023 CVE References: CVE-2019-25074,CVE-2022-37032 JIRA References: Sources used: openSUSE Leap 15.4 (src): frr-7.4-150300.4.7.1 openSUSE Leap 15.3 (src): frr-7.4-150300.4.7.1 SUSE Linux Enterprise Module for Server Applications 15-SP4 (src): frr-7.4-150300.4.7.1 SUSE Linux Enterprise Module for Server Applications 15-SP3 (src): frr-7.4-150300.4.7.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. Done, closing. |
When FRR receives an IS-IS HELLO packet, it parses it and attempts to unpack the TLVs contained in it, resulting in a call trace that looks something like the following: ``` #0 unpack_tlvs() isisd/isis_tlvs.c #1 isis_unpack_tlvs() in isisd/isis_tlvs.c #2 process_hello() in isisd/isis_pdu.c #3 isis_handle_pdu() in isisd/isis_pdu.c ``` Down the call stack, different TLV unpackers are called via ops-like structures holding function pointers, depending on the TLV type. One of these unpackers is `unpack_tlv_router_cap()`. Here, FRR allocates a new structure to hold the received information; however, if the transmitted length is greater than the actual amount of data sent, the function bails out. ```c /* Functions related to TLV 242 Router Capability as per RFC7981 */ ... static int unpack_tlv_router_cap(...) { ... /* Allocate router cap structure and initialize SR Algorithms */ rcap = XCALLOC(MTYPE_ISIS_TLV, sizeof(struct isis_router_cap)); ... while (...) { ... if (length > STREAM_READABLE(s) || length > subtlv_len - 2) { stream_forward_getp(s, STREAM_READABLE(s)); return 0; } ... } ... tlvs->router_cap = rcap; return 0; } ``` Note that the pointer to the allocated structure (`rcap`) is leaked once the function returns with an error, since it is never freed. Normally, this structure would be freed via `isis_free_tlvs()` after the error bubbles up from `unpack_tlv_router_cap()` back to `process_hello()`: ```c static int process_hello(...) { ... if (isis_unpack_tlvs(STREAM_READABLE(circuit->rcv_stream), circuit->rcv_stream, &iih.tlvs, &error_log)) { /* error ... */ goto out; } ... out: isis_free_tlvs(iih.tlvs); return retval; } ``` ```c void isis_free_tlvs(struct isis_tlvs *tlvs) { ... free_tlv_router_cap(tlvs->router_cap); ... } ``` This issue could be exploited to exhaust the routing server's available memory, albeit slowly, eventually leading to denial of service. This issue was fixed with the following commit: https://github.com/FRRouting/frr/commit/49efc80d342d8e8373c8af040580bd7940808730