Bug 2126586
| Summary: | DHCPv6 server replies with Advertise to a relay forwarded request, expect Relay-reply instead. [rhel9] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Harald Jensås <hjensas> | ||||
| Component: | dnsmasq | Assignee: | Petr Menšík <pemensik> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 9.1 | CC: | bstinson, jwboyer, pemensik, psklenar, sbaker | ||||
| Target Milestone: | rc | Keywords: | Regression, TestBlocker, TestCaseProvided, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | dnsmasq-2.85-6.el9 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 2164859 (view as bug list) | Environment: | |||||
| Last Closed: | 2023-05-09 07:53:17 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 2063290 | ||||||
| Bug Blocks: | 2154110, 2164859 | ||||||
| Attachments: |
|
||||||
Created attachment 1933126 [details]
Traffic capture from RHEL 9.1 dnsmasq-2.85-5.el9.x86_64
We are seeing this issue on RHEL 9.1 (Plow) with package: dnsmasq-2.85-5.el9.x86_64
-4 release has fixed CVE with bug #2063290. That was change by commit [1], MR !6. It should not changed anything related to DHCP relay. Is minimal reproducer just using dhcp relay on IPv6 request? 1. https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/commit/ea063256c74d532c34be9802785f0eff5b88bf75 (In reply to Petr Menšík from comment #4) > -4 release has fixed CVE with bug #2063290. > > Is minimal reproducer just using dhcp relay on IPv6 request? > I never set up a minimal reproducer, but I belive the issue should reproduce by just using DHCPv6 relay on IPv6 request. It may be required to request additional options for network booting to trigger the issue. In the OpenStack test case we use dnsmasq as the relay service like this: /usr/sbin/dnsmasq \ --conf-file=/dev/null \ --keep-in-foreground \ --log-dhcp \ --dhcp-relay=<%downstream_iface_ip%>,ff05::1:3,<%upstream_iface%> \ --port 0 The DHCPv6 client is a Libvrit VM with OVMF EFI firmware attempting network boot. Thank you for simple reproducer. Together with network namespaces it should allow simple reproducer. Unfortunately it has to wait after the New Year for a proper analysis and fix. Reproducing requires also --interface to allow incoming queries. But yes, there is regression in RHEL 9 and RHEL 8 too. Latest Fedora release works fine. I think I have found the issue. I have used my own change to fix CVE, but it contained some errors. I think better would be to use just minimal changes from upstream and small modifications of its commit [1]. Should fix the CVE and at the same time fix this regression in relay code. Created PR #8 [2] on CStream 1. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39 2. https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/-/merge_requests/8 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (dnsmasq bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2401 |
Created attachment 1911610 [details] Traffic capture version 2.85-3 (OK) and 2.85-4 (Not OK) - dhcpv6-capture/dnsmasq-2.85-3.el9.pcap + dhcpv6-capture/dnsmasq-2.85-4.el9.pcap Description of problem: DHCPv6 server replies with Advertise to a relay forwarded request. It should reply with a Relay-reply. Downgrade to dnsmasq-2.85-3.el9.x86_64.rpm fixes the problem. Attached traffic capture from both 2.85-3 (OK) and 2.85-4 (Not OK). Version-Release number of selected component (if applicable): dnsmasq-2.85-4.el9.x86_64 How reproducible: 100% Actual results: The DHCP server responds with what looks like a malformed Advertise message instead of a Relay-reply with a relay message. DHCPv6 Message type: Advertise (2) Transaction ID: 0x00fd00 Expected results: Expect Message type: Relay-reply with Relay Message similar to the example below, which is the result with dnsmasq-2.85-3 DHCPv6 Message type: Relay-reply (13) Hopcount: 0 Link address: fd00:fd00:fd00:2::fffe Peer address: fe80::f816:3eff:feb4:777f Interface-Id Option: Interface-Id (18) Length: 4 Interface-ID: 01000000 Relay Message Option: Relay Message (9) Length: 156 DHCPv6 Message type: Advertise (2) Transaction ID: 0x4cb852 Client Identifier Option: Client Identifier (1) Length: 18 DUID: 0004ffca010953544065b92f451e21dbaa53 DUID Type: Universally Unique IDentifier (UUID) (4) UUID: ffca010953544065b92f451e21dbaa53 Server Identifier Option: Server Identifier (2) Length: 14 DUID: 000100012ab32677fa163e3b6d21 DUID Type: link-layer address plus time (1) Hardware type: Ethernet (1) DUID Time: Sep 13, 2022 13:31:03.000000000 CEST Link-layer address: fa:16:3e:3b:6d:21 Identity Association for Non-temporary Address Option: Identity Association for Non-temporary Address (3) Length: 40 IAID: 29ce029f T1: 300 T2: 525 IA Address Status code Option: Status code (13) Length: 9 Status Code: Success (0) Status Message: success Preference Option: Preference (7) Length: 1 Pref-value: 0 Boot File URL Option: Boot File URL (59) Length: 46 Additional info: Downgrading dnsmasq to dnsmasq-2.85-3.el9.x86_64.rpm resolves the issue.