This changelog lists all commits done in OpenWrt since the v19.07.9 tag, grouped by subsystem. The changes are chronologically ordered from top to bottom and cover the Git repository history until the tagging of the 19.07.10 release.
See also the release notes that provide a more accessible overview of the main changes in 19.07.10.
0af411f zlib: backport security fix for a reproducible crash in compressor (+688,-2)
9aa35fa patchelf: backport fix for rpath endianness (+41)
5ecc7ea imagebuilder: fix partition signature (+2)
058c234 imagebuilder: fix broken image generation with external targets (+1,-1)
9ced994 kernel: bump 4.14 to 4.14.269 (+18,-18)
565159d kernel: bump 4.14 to 4.14.272 (+84,-75)
ea0e521 kernel: bump 4.14 to 4.14.273 (+8,-8)
b24905c kernel: bump 4.14 to 4.14.274 (+4,-4)
d39a6c6 kernel: bump 4.14 to 4.14.275 (+10,-10)
ae2af91 kernel: generic: reorder kernel config options (+3,-3)
26a8be9 kernel: generic: add missing symbol for arm64 spectre mitigation (+1)
31bb27f wolfssl: bump to 5.1.1-stable (+86,-8)
f49eec6 wolfssl: fix API breakage of SSL_get_verify_result (+27,-1)
c5c047f openssl: bump to 1.1.1n (+2,-2)
0af411f zlib: backport security fix for a reproducible crash in compressor (+688,-2)
9ce6aa9 wolfssl: bump to 5.2.0 (+9,-11)
6b8407c base-files: call "sync" after initial setup (+1)
cc344f1 ubus: backport fixes for UAF and other issues (+3,-3)
⇒ c3f3e19 libubus: use list_empty/list_first_entry in ubus_process_pending_msg (+3,-2)
⇒ edda23f libubus: process pending messages in data handler if stack depth is 0 (+9,-1)
⇒ b32a0e1 libubus: increase stack depth for processing obj msgs (+2)
572a1f9 ar71xx: fix MikroTik wAP detection (+2,-1)
9ced994 kernel: bump 4.14 to 4.14.269 (+18,-18)
ea0e521 kernel: bump 4.14 to 4.14.273 (+8,-8)
9ced994 kernel: bump 4.14 to 4.14.269 (+18,-18)
a518a4f ath79: fix link for long cables with OCEDO Raccoon (+12,-1)
d39a6c6 kernel: bump 4.14 to 4.14.275 (+10,-10)
565159d kernel: bump 4.14 to 4.14.272 (+84,-75)
565159d kernel: bump 4.14 to 4.14.272 (+84,-75)
9ced994 kernel: bump 4.14 to 4.14.269 (+18,-18)
d39a6c6 kernel: bump 4.14 to 4.14.275 (+10,-10)
698cdf0 mac80211: Update to version 4.19.237-1 (+13,-13)
Description: wolfSSL before 4.8.1 incorrectly skips OCSP verification in certain situations of irrelevant response data that contains the NoCheck extension.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38597
Commits:
31bb27f wolfssl: bump to 5.1.1-stable (+86,-8)
Description: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44718
Commits:
31bb27f wolfssl: bump to 5.1.1-stable (+86,-8)
Description: The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0778
Commits:
c5c047f openssl: bump to 1.1.1n (+2,-2)
Description: wolfSSL 5.x before 5.1.1 uses non-random IV values in certain situations. This affects connections (without AEAD) using AES-CBC or DES3 with TLS 1.1 or 1.2 or DTLS 1.1 or 1.2. This occurs because of misplaced memory initialization in BuildMessage in internal.c.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23408
Commits:
31bb27f wolfssl: bump to 5.1.1-stable (+86,-8)
Description: In wolfSSL before 5.2.0, certificate validation may be bypassed during attempted authentication by a TLS 1.3 client to a TLS 1.3 server. This occurs when the sig_algo field differs between the certificate_verify message and the certificate message.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25638
Commits:
9ce6aa9 wolfssl: bump to 5.2.0 (+9,-11)
Description: In wolfSSL before 5.2.0, a TLS 1.3 server cannot properly enforce a requirement for mutual authentication. A client can simply omit the certificate_verify message from the handshake, and never present a certificate.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25640
Commits:
9ce6aa9 wolfssl: bump to 5.2.0 (+9,-11)