Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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
(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.
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.