1 Commits

Author	SHA1	Message	Date
Petr Menšík	168294acac	Use hashtable when parsing a message ... When parsing messages use a hashtable instead of a linear search to reduce the amount of work done in findname when there's more than one name in the section. There are two hashtables: 1) hashtable for owner names - that's constructed for each section when we hit the second name in the section and destroyed right after parsing that section; 2) per-name hashtable - for each name in the section, we construct a new hashtable for that name if there are more than one rdataset for that particular name. (cherry picked from commit b8a96317544c7b310b4f74360825a87b6402ddc2) (cherry picked from commit 0ceed03ebea395da1a39ad1cb39205ce75a3f768) Backport isc_ht API changes from BIND 9.18 To prevent allocating large hashtable in dns_message, we need to backport the improvements to isc_ht API from BIND 9.18+ that includes support for case insensitive keys and incremental rehashing of the hashtables. (cherry picked from commit a4baf324159ec3764195c949cb56c861d9f173ff) (cherry picked from commit 2fc28056b33018f7f78b625409eb44c32d5c9b11) fix a message parsing regression the fix for CVE-2023-4408 introduced a regression in the message parser, which could cause a crash if duplicate rdatasets were found in the question section. this commit ensures that rdatasets are correctly disassociated and freed when this occurs. (cherry picked from commit 4c19d35614f8cd80d8748156a5bad361e19abc28) (cherry picked from commit 98ab8c81cc7739dc220aa3f50efa3061774de8ba) fix another message parsing regression The fix for CVE-2023-4408 introduced a regression in the message parser, which could cause a crash if an rdata type that can only occur in the question was found in another section. (cherry picked from commit 510f1de8a6add516b842a55750366944701d3d9a) (cherry picked from commit bbbcaf8b2ec17d2cad28841ea86078168072ae2f) Apply various tweaks specific to BIND 9.11 (cherry picked from commit c6026cbbaa9d297910af350fa6cc45788cc9f397) Fix case insensitive matching in isc_ht hash table implementation The case insensitive matching in isc_ht was basically completely broken as only the hashvalue computation was case insensitive, but the key comparison was always case sensitive. (cherry picked from commit c462d65b2fd0db362947db4a18a87df78f8d8e5d) (cherry picked from commit 418b3793598a1e1c7e391bb317866d405cd03501) Add a system test for mixed-case data for the same owner We were missing a test where a single owner name would have multiple types with a different case. The generated RRSIGs and NSEC records will then have different case than the signed records and message parser have to cope with that and treat everything as the same owner. (cherry picked from commit c8b623d87f0fb8f9cba8dea5c6a4b600953895e7) (cherry picked from commit 1f9bbe1fe34b7a2c9765431e8a86b460afc9b323) 6315. [security] Speed up parsing of DNS messages with many different names. (CVE-2023-4408) [GL #4234] ; Resolves: CVE-2023-4408 Resolves: RHEL-25691	2024-03-26 18:05:44 +01:00