summaryrefslogtreecommitdiff
path: root/src/libsystemd-network/dhcp6-option.c
Commit message (Collapse)AuthorAgeFilesLines
...
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-091-1/+1
|
* tree-wide: define iterator inside of the macroZbigniew Jędrzejewski-Szmek2020-09-081-2/+1
|
* dhcp6: parse the FQDN optionBeniamino Galvani2020-08-031-38/+80
| | | | | Parse option 39 (Client Fully Qualified Domain Name, RFC 4704) from the DHCP reply, which specifies the FQDN assigned by the server to the client.
* dhcp6: remove assertions in dhcp6_option_parse_domainname()Beniamino Galvani2020-07-281-2/+4
| | | | | Assertions are for programming errors; here the input comes directly from the DHCP response packet.
* sd-dhcp6: Introduce vendor specific informationSusant Sahani2020-05-291-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: 8415 21.17. Vendor-specific Information Option This option is used by clients and servers to exchange vendor- specific information. The format of the Vendor-specific Information option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_OPTS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Vendor-specific Information Option Format option-code OPTION_VENDOR_OPTS (17). option-len 4 + length of vendor-option-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-option-data Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in the option-len field). The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. A DHCP client that does not receive requested vendor-specific information will still configure the node's IPv6 stack to be functional. The vendor-option-data field MUST be encoded as a sequence of code/length/value fields of format identical to the DHCP options (see Section 21.1). The sub-option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the sub-options is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-opt-code | sub-option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: Vendor-specific Options Format sub-opt-code The code for the sub-option. A 2-octet field. sub-option-len An unsigned integer giving the length of the sub-option-data field in this sub-option in octets. A 2-octet field. sub-option-data The data area for the sub-option. The length, in octets, is specified by sub-option-len. Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific Information option MAY contain multiple sub-options. A client that is interested in receiving a Vendor-specific Information option: - MUST specify the Vendor-specific Information option in an Option Request option. - MAY specify an associated Vendor Class option (see Section 21.16). - MAY specify the Vendor-specific Information option with appropriate data. Servers only return the Vendor-specific Information options if specified in Option Request options from clients and: - MAY use the Enterprise Numbers in the associated Vendor Class options to restrict the set of Enterprise Numbers in the Vendor-specific Information options returned. - MAY return all configured Vendor-specific Information options. - MAY use other information in the packet or in its configuration to determine which set of Enterprise Numbers in the Vendor-specific Information options to return.
* sd-network: Rectify Advertise Message Processing by a ClientSusant Sahani2020-05-291-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to fix RCC 2215 behaviour with rfc7550 errata and https://tools.ietf.org/html/rfc8415. [RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client, and [RFC3633] specifies that a client must ignore an Advertise message if a server returns the NoPrefixAvail status to a requesting router. Thus, a client requesting both IA_NA and IA_PD, with a server that only offers either addresses or delegated prefixes, is not supported by the current protocol specifications. Solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when none of the requested IA options include offered addresses or delegated prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. Replace Section 17.1.3 of RFC 3315: (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message(s) to the user. With the following text (which addresses the existing erratum [Err2471] and includes the changes made by [RFC7083]): The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the client: - MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083). A client can display any associated status message(s) to the user or activity log. The client ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
* sd-network: DHCPv6 - Add support to send vendor class dataSusant Sahani2020-05-201-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` 21.16. Vendor Class Option This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware configuration. The format of the Vendor Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-class-data . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: Vendor Class Option Format option-code OPTION_VENDOR_CLASS (16). option-len 4 + length of vendor-class-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-class-data The hardware configuration of the node on which the client is running. A variable-length field (4 octets less than the value in the option-len field). The vendor-class-data field is composed of a series of separate items, each of which describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client. Each instance of vendor-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | vendor-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 29: Format of vendor-class-data Field The vendor-class-len field is 2 octets long and specifies the length of the opaque vendor-class-data in network byte order. Servers and clients MUST NOT include more than one instance of OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances. ```
* sd-network: DHCPv6 - add support to send userclass optionSusant Sahani2020-05-191-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sd-network: DHCPv6 - add support to send userclass option 21.15. User Class Option The User Class option is used by a client to identify the type or category of users or applications it represents. The format of the User Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . user-class-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: User Class Option Format option-code OPTION_USER_CLASS (15). option-len Length of user-class-data field. user-class-data The user classes carried by the client. The length, in octets, is specified by option-len. The information contained in the data area of this option is contained in one or more opaque fields that represent the user class or classes of which the client is a member. A server selects configuration information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client. The data area of the User Class option MUST contain one or more instances of user-class-data information. Each instance of user-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 27: Format of user-class-data Field
* DHCP client: make SendOption work for DHCPv6 too.Andrew Doran2020-05-111-0/+40
|
* sd-network: DHCP6 - Use readable error status rather than numericSusant Sahani2020-04-131-2/+2
| | | | value in the log message
* tree-wide: drop string.h when string-util.h or friends are includedYu Watanabe2019-11-041-1/+0
|
* network: DHCPv6 client add support for prefix delegation hintSusant Sahani2019-10-011-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for prefix hint lenth and prefix hint address ``` Frame 43: 177 bytes on wire (1416 bits), 177 bytes captured (1416 bits) on interface 0 Ethernet II, Src: f6:c1:08:4d:45:f1 (f6:c1:08:4d:45:f1), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02) Internet Protocol Version 6, Src: fe80::d250:c82:7f6e:28d6, Dst: ff02::1:2 User Datagram Protocol, Src Port: 546, Dst Port: 547 DHCPv6 Message type: Solicit (1) Transaction ID: 0x5c7902 Rapid Commit Identity Association for Non-temporary Address Fully Qualified Domain Name Identity Association for Prefix Delegation Option: Identity Association for Prefix Delegation (25) Length: 41 Value: 1b97b1690000000000000000001a0019ffffffffffffffff… IAID: 1b97b169 T1: 0 T2: 0 IA Prefix Option: IA Prefix (26) Length: 25 Value: ffffffffffffffff3c000000000000000000000000000000… Preferred lifetime: infinity Valid lifetime: infinity Prefix length: 60 Prefix address: :: Option Request Client Identifier Elapsed time ```
* util: split out memcmp()/memset() related calls into memory-util.[ch]Lennart Poettering2019-03-131-1/+1
| | | | Just some source rearranging.
* dhcp6: prefer offsetof() over sizeof() for structs with undefined sizesLennart Poettering2018-10-251-15/+15
| | | | | | This doesn't change anything in the generated source, but I think makes semantically more sense, as these structures have undefined size, and we only want to know the size up to the data field in these cases.
* dhcp6: make sure we have enough space for the DHCP6 option headerLennart Poettering2018-10-251-1/+1
| | | | | | | | | Fixes a vulnerability originally discovered by Felix Wilhelm from Google. CVE-2018-15688 LP: #1795921 https://bugzilla.redhat.com/show_bug.cgi?id=1639067
* dhcp6: reduce whitespace a bitLennart Poettering2018-10-251-3/+3
|
* dhcp6: split assert_return() to be more debuggable when hitLennart Poettering2018-10-251-1/+4
|
* dhcp6: constify things where we canLennart Poettering2018-10-251-2/+2
|
* sd-dhcp6: drop empty 'error' labelYu Watanabe2018-10-191-36/+19
|
* sd-dhcp6: make dhcp6_option_parse_domainname() not store empty domainYu Watanabe2018-10-191-37/+29
| | | | | This improves performance of fuzzer. C.f. oss-fuzz#11019.
* sd-dhcp6: fix argument and error handling of dhcp6_option_parse_status()Yu Watanabe2018-10-191-4/+6
|
* dhcp6: check option length before reading valuesYu Watanabe2018-10-031-5/+6
| | | | | Fixes oss-fuzz#10746 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10746.
* dhcp6: fix an off-by-one error in dhcp6_option_parse_domainnameEvgeny Vereshchagin2018-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | ==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200055fa9c at pc 0x0000005458f1 bp 0x7ffc78940d90 sp 0x7ffc78940d88 READ of size 1 at 0x60200055fa9c thread T0 #0 0x5458f0 in dhcp6_option_parse_domainname /work/build/../../src/systemd/src/libsystemd-network/dhcp6-option.c:555:29 #1 0x54706e in dhcp6_lease_set_domains /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-lease.c:242:13 #2 0x53fce0 in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:984:29 #3 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13 #4 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21 #5 0x7f0f7159deee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21 #6 0x7f0f7159d431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21 #7 0x7f0f7159ea8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21 #8 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9 #9 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9 #10 0x57bec8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15 #11 0x579d67 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3 #12 0x57dc92 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19 #13 0x580ca6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:838:5 #14 0x55e968 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6 #15 0x551a1c in main /src/libfuzzer/FuzzerMain.cpp:20:10 #16 0x7f0f701a082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #17 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)
* tree-wide: use proper unicode © instead of (C) where we canLennart Poettering2018-06-141-1/+1
| | | | | | Let's use a proper unicode copyright symbol where we can, it's prettier. This important patch is very important.
* tree-wide: drop 'This file is part of systemd' blurbLennart Poettering2018-06-141-2/+0
| | | | | | | | | | | | | | | | This part of the copyright blurb stems from the GPL use recommendations: https://www.gnu.org/licenses/gpl-howto.en.html The concept appears to originate in times where version control was per file, instead of per tree, and was a way to glue the files together. Ultimately, we nowadays don't live in that world anymore, and this information is entirely useless anyway, as people are very welcome to copy these files into any projects they like, and they shouldn't have to change bits that are part of our copyright header for that. hence, let's just get rid of this old cruft, and shorten our codebase a bit.
* resolved: fix typo in macro nameZbigniew Jędrzejewski-Szmek2018-06-081-1/+1
|
* tree-wide: drop license boilerplateZbigniew Jędrzejewski-Szmek2018-04-061-13/+0
| | | | | | | | | | Files which are installed as-is (any .service and other unit files, .conf files, .policy files, etc), are left as is. My assumption is that SPDX identifiers are not yet that well known, so it's better to retain the extended header to avoid any doubt. I also kept any copyright lines. We can probably remove them, but it'd nice to obtain explicit acks from all involved authors before doing that.
* macro: introduce TAKE_PTR() macroLennart Poettering2018-03-221-2/+1
| | | | | | | | | | | | | | | | This macro will read a pointer of any type, return it, and set the pointer to NULL. This is useful as an explicit concept of passing ownership of a memory area between pointers. This takes inspiration from Rust: https://doc.rust-lang.org/std/option/enum.Option.html#method.take and was suggested by Alan Jenkins (@sourcejedi). It drops ~160 lines of code from our codebase, which makes me like it. Also, I think it clarifies passing of ownership, and thus helps readability a bit (at least for the initiated who know the new macro)
* dhcp6: fix warnings by clang with -Waddress-of-packed-memberYu Watanabe2018-01-171-5/+4
| | | | | | | | | | | | | | This fixes the following warnings: ``` [194/1521] Compiling C object 'src/libsystemd-network/systemd-network@sta/dhcp6-option.c.o'. ../../git/systemd/src/libsystemd-network/dhcp6-option.c:110:25: warning: taking address of packed member 'id' of class or structure 'ia_na' may result in an unaligned pointer value [-Waddress-of-packed-member] iaid = &ia->ia_na.id; ^~~~~~~~~~~~ ../../git/systemd/src/libsystemd-network/dhcp6-option.c:115:25: warning: taking address of packed member 'id' of class or structure 'ia_ta' may result in an unaligned pointer value [-Waddress-of-packed-member] iaid = &ia->ia_ta.id; ^~~~~~~~~~~~ 2 warnings generated. ```
* dhcp6: Fix valgrind nitpick about returned test case valuePatrik Flykt2018-01-151-1/+1
| | | | | | | | | Calling dhcp6_option_parse_address() will always return a value < 0 on error even though lt_valid remains unset. This is more than valgrind can safely detect, but let's fix the valgrind nitpick anyway. While fixing, use UINT32_MAX instead of ~0 on the same line.
* dhcp6: Add function appending an IA PD to the DHCP6 messagePatrik Flykt2018-01-041-0/+36
| | | | | Add function that appends an IA PD option and any number of IA PD Prefix options.
* dhcp6: Parse IA PD and PD Prefix optionsPatrik Flykt2018-01-041-10/+123
| | | | | | | | | | | | | Parse IA PD options and the prefixes in one or more PD Prefix options. As the PD option contains identical data as the IA NA option, re-use the same general data structures and sub-option parsing logic. Similar to IA NA addresses, PD and associated prefixes are stored in the address list of the IA PD lease. An IA sub-option Status code will affect the IA NA and IA PD option in question and cause those options to be ignored. A Status code option in an IA Address or IA PD Prefix option affects only that IA Address or Prefix.
* dhcp6: Fix IA Address option parsingPatrik Flykt2018-01-041-21/+52
| | | | | | | | | | | | | Factor out IA Address option parsing and fix it so that all conditions are checked before a new address is allocated and added to the address list. Note also that the IA Address option can contain a nested Status option. If the status in anything else than zero, the DHCPv6 server is communicating an error condition and the address cannot be used. Status option nesting is clarified in RFC 7550, Section 4.1. The IA Address option is included as a typedef so that the lifetimes can be inspected before allocating a new address and the option length needed is easily available.
* dhcp6: Add function for DHCPv6 Status optionPatrik Flykt2018-01-041-5/+20
| | | | | Factor out code to parse a DHCPv6 Status option using a common function.
* dhcp6: Sanitize DHCPv6 IA option parsingPatrik Flykt2018-01-041-37/+29
| | | | | | | | | | | | Sanitize code for parsing DHCPv6 IA NA and TA options and their nested Status options so that the options can be fully and properly ignored should they not be conformant to the specification. Do this by defining a proper DHCP6Option structure and sending that structure to the parsing function. The parsing function will then not manipulate either any option data pointers or their lengths in order to iterate over the current option. Needless to say, this affects a few files including the test program.
* dhcp6: Name structs in DHCP6IAPatrik Flykt2018-01-041-14/+14
| | | | | | Name structs containing IA NA with ID and T1 and T2 lifetimes and IA TA containing only the ID so that the structs can be expressed properly.
* Add SPDX license identifiers to source files under the LGPLZbigniew Jędrzejewski-Szmek2017-11-191-0/+1
| | | | | This follows what the kernel is doing, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
* sd-dhcp6-client: Implement FQDN Option (#7309)Stefan Agner2017-11-161-0/+27
| | | | | | | | | | | | | | Implement DHCPv6 option to exchange information about the Fully Qualified Domain Name (FQDN) according to RFC 4704. The RFC 4704 describes two models of operations in section 3, currently only the second model is supported (DHCPv6 server updates both the AAAA and the PTR RRs). The existing DHCP Section Options SendHostname and Hostname are sent as FQDN to the server. According to section 4.2 sending only parts of its FQDN is allowed. Fixes #4682.
* sd-network: fix memleak in dhcp6_option_parse_domainname (#5114)Evgeny Vereshchagin2017-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..7b0a5ef 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -168,7 +168,7 @@ static uint8_t msg_advertise[198] = { 0x00, 0x17, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x0b, - 0x03, 0x6c, 0x61, 0x62, 0x05, 0x69, 0x6e, 0x74, + 0x01, 0x6c, 0x01, 0x62, 0x00, 0x0a, 0x6e, 0x74, 0x72, 0x61, 0x00, 0x00, 0x1f, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, @@ -338,9 +338,7 @@ static int test_advertise_option(sd_event *e) { assert_se(!memcmp(addrs, &msg_advertise[124], r * 16)); r = sd_dhcp6_lease_get_domains(lease, &domains); - assert_se(r == 1); - assert_se(!strcmp("lab.intra", domains[0])); - assert_se(domains[1] == NULL); + assert_se(r == -ENOENT); r = sd_dhcp6_lease_get_ntp_addrs(lease, &addrs); assert_se(r == 1); ``` Fixes: ``` ================================================================= ==15043==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 #6 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 #5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 #6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 #7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 #8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 #9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 #10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 #11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 #12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 #13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```
* Merge pull request #2589 from keszybz/resolve-tool-2Lennart Poettering2016-02-131-2/+1
|\ | | | | Better support of OPENPGPKEY, CAA, TLSA packets and tests
| * Add memcpy_safeZbigniew Jędrzejewski-Szmek2016-02-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISO/IEC 9899:1999 §7.21.1/2 says: Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. In base64_append_width memcpy was called as memcpy(x, NULL, 0). GCC 4.9 started making use of this and assumes This worked fine under -O0, but does something strange under -O3. This patch fixes a bug in base64_append_width(), fixes a possible bug in journal_file_append_entry_internal(), and makes use of the new function to simplify the code in other places.
* | tree-wide: remove Emacs lines from all filesDaniel Mack2016-02-101-2/+0
|/ | | | | This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.
* dhcp: make DHCP6_OPTION_* enum publicBeniamino Galvani2016-01-201-7/+9
| | | | | | | | libsystemd-network provides the public function sd_dhcp6_client_set_request_option() to enable the request of a given DHCP option. However the enum defining such options is defined in the internal header dhcp6-protocol.h. Move the enum definition to the public header sd-dhcp6-client.h and properly namespace values.
* dns-domain: rework dns_label_escape() to not imply memory allocationLennart Poettering2015-11-251-10/+8
| | | | | | The new dns_label_escape() call now operates on a buffer passed in, similar to dns_label_unescape(). This should make decoding a bit faster, and nicer.
* tree-wide: sort includesThomas Hindoe Paaboel Andersen2015-11-161-1/+1
| | | | Sort the includes accoding to the new coding style.
* sd-dhcp6-client: fix assert in options parsingTom Gundersen2015-10-301-1/+1
|
* util-lib: split out allocation calls into alloc-util.[ch]Lennart Poettering2015-10-271-5/+5
|
* tree-wide: we place the opening bracket on the same line as the function nameLennart Poettering2015-08-271-3/+1
| | | | Let's do this everywhere the same way.
* sd-dhcp6: fix domainname memleakDavid Herrmann2015-08-261-1/+0
| | | | | | | | | strv_extend() does not consume the passed entry, hence, we must properly free it. Furthermore, we should *not* use strv_consume() as we do greedy allocations on 'ret'; and greedy-allocations should only be used for short lived objects or caches. Fix the domainname parser to properly free temporary storage when done.
* dhcp6-option: Add helper function for uncompressed domain namesPatrik Flykt2015-08-211-0/+82
| | | | | | | Add a helper function containing a modified version of dns_packet_read_name() that does not use DnsPacket to extract a string array of domain names from the provided option data. The domain names are stored uncompressed as defined in Section 8. of RFC 3315.