staging/pepe2k/package, branch v19.07.10

OpenWrt v19.07.10: adjust config defaults

2022-04-17T17:35:25Z

Signed-off-by: Hauke Mehrtens

wolfssl: bump to 5.2.0

2022-04-16T13:13:32Z

Fixes two high-severity vulnerabilities: - CVE-2022-25640: A TLS v1.3 server who requires mutual authentication can be bypassed. If a malicious client does not send the certificate_verify message a client can connect without presenting a certificate even if the server requires one. - CVE-2022-25638: A TLS v1.3 client attempting to authenticate a TLS v1.3 server can have its certificate heck bypassed. If the sig_algo in the certificate_verify message is different than the certificate message checking may be bypassed. Signed-off-by: Eneas U de Queiroz Signed-off-by: Petr Štetiar [ABI version change] (cherry picked from commit e89f3e85eb1c1d81294e5d430a91b0ba625e2ec0) (cherry picked from commit 2393b09b5906014047a14a79c03292429afcf408)

mac80211: Update to version 4.19.237-1

2022-04-11T21:25:53Z

This updates mac80211 to version 4.19.237-1 which is based on kernel 4.19.237. This new release contains many fixes which were merged into the upstream Linux kernel. Signed-off-by: Hauke Mehrtens

zlib: backport security fix for a reproducible crash in compressor

2022-03-24T09:02:01Z

Tavis has just reported, that he was recently trying to track down a reproducible crash in a compressor. Believe it or not, it really was a bug in zlib-1.2.11 when compressing (not decompressing!) certain inputs. Tavis has reported it upstream, but it turns out the issue has been public since 2018, but the patch never made it into a release. As far as he knows, nobody ever assigned it a CVE. Runtime tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Suggested-by: Tavis Ormandy References: https://www.openwall.com/lists/oss-security/2022/03/24/1 Signed-off-by: Petr Štetiar (cherry picked from commit b3aa2909a79aeff20d594160b207a89dc807c033) (cherry picked from commit 3965dda0fa70dc9408f1a2e55a3ddefde78bd50e) (cherry picked from commit f65edc9b990c2bcc10c9e9fca29253adc6fe316d)

openssl: bump to 1.1.1n

2022-03-16T15:34:26Z

This is a bugfix release. Changelog: *) Fixed a bug in the BN_mod_sqrt() function that can cause it to loop forever for non-prime moduli. (CVE-2022-0778) *) Add ciphersuites based on DHE_PSK (RFC 4279) and ECDHE_PSK (RFC 5489) to the list of ciphersuites providing Perfect Forward Secrecy as required by SECLEVEL >= 3. Signed-off-by: Martin Schiller (cherry picked from commit e17c6ee62770005e398364ee5d955c9a8ab6f016)

base-files: call "sync" after initial setup

2022-03-15T09:15:39Z

OpenWrt uses a lot of (b)ash scripts for initial setup. This isn't the best solution as they almost never consider syncing files / data. Still this is what we have and we need to try living with it. Without proper syncing OpenWrt can easily get into an inconsistent state on power cut. It's because: 1. Actual (flash) inode and data writes are not synchronized 2. Data writeback can take up to 30 seconds (dirty_expire_centisecs) 3. ubifs adds extra 5 seconds (dirty_writeback_centisecs) "delay" Some possible cases (examples) for new files: 1. Power cut during 5 seconds after write() can result in all data loss 2. Power cut happening between 5 and 35 seconds after write() can result in empty file (inode flushed after 5 seconds, data flush queued) Above affects e.g. uci-defaults. After executing some migration script it may get deleted (whited out) without generated data getting actually written. Power cut will result in missing data and deleted file. There are three ways of dealing with that: 1. Rewriting all user-space init to proper C with syncs 2. Trying bash hacks (like creating tmp files & moving them) 3. Adding sync and hoping for no power cut during critical section This change introduces the last solution that is the simplest. It reduces time during which things may go wrong from ~35 seconds to probably less than a second. Of course it applies only to IO operations performed before /etc/init.d/boot . It's probably the stage when the most new files get created. All later changes are usually done using smarter C apps (e.g. busybox or uci) that creates tmp files and uses rename() that is expected to be atomic. Signed-off-by: Rafał Miłecki Acked-by: Hauke Mehrtens Acked-by: Sergey Ryazanov (cherry picked from commit 9851d4b6ce6e89d164a04803817625a9041b060a)

wolfssl: fix API breakage of SSL_get_verify_result

2022-02-22T19:32:11Z

Backport fix for API breakage of SSL_get_verify_result() introduced in v5.1.1-stable. In v4.8.1-stable SSL_get_verify_result() used to return X509_V_OK when used on LE powered sites or other sites utilizing relaxed/alternative cert chain validation feature. After an update to v5.1.1-stable that API calls started returning X509_V_ERR_INVALID_CA error and thus rendered all such connection attempts imposible: $ docker run -it openwrt/rootfs:x86_64-21.02.2 sh -c "wget https://letsencrypt.org" Downloading 'https://letsencrypt.org' Connecting to 18.159.128.50:443 Connection error: Invalid SSL certificate Fixes: #9283 References: https://github.com/wolfSSL/wolfssl/issues/4879 Signed-off-by: Petr Štetiar (cherry picked from commit b9251e3b407592f3114e739231088c3d27663c4c) (cherry picked from commit b99d7aecc83fd180f7a3c3efaae00845e7a73129)

ubus: backport fixes for UAF and other issues

2022-02-21T06:41:05Z

Backporting following fixes: a72457b61df0 libubus: increase stack depth for processing obj msgs ef038488edc3 libubus: process pending messages in data handler if stack depth is 0 2099bb3ad997 libubus: use list_empty/list_first_entry in ubus_process_pending_msg where at least commit 2099bb3ad997 ("libubus: use list_empty/list_first_entry in ubus_process_pending_msg") fixes UAF issue I've introduced in commit c5f2053dfcfd ("workaround possibly false positive uses of memory after it is freed") while fixing another false positive UAF reported[1] by clang's static analyzer. Those fixes are being used in master/21.02 for about 6 months, so should be tested enough and considered for backporting. I've runtested those fixes on mvebu/turris-omnia and ipq40xx/glinet-b1300 devices. 1. https://openwrt.gitlab.io/-/project/ubus/-/jobs/2096090992/artifacts/build/scan/2022-02-15-150310-70-1/index.html Signed-off-by: Petr Štetiar

wolfssl: bump to 5.1.1-stable

2022-02-21T06:37:57Z

This is amalgamation of backported changes since 4.7.0-stable release: Sergey V. Lobanov (2): 5b13b0b02c70 wolfssl: update to 5.1.1-stable 7d376e6e528f libs/wolfssl: add SAN (Subject Alternative Name) support Andre Heider (3): 3f8adcb215ed wolfssl: remove --enable-sha512 configure switch 249478ec4850 wolfssl: always build with --enable-reproducible-build 4b212b1306a9 wolfssl: build with WOLFSSL_ALT_CERT_CHAINS Ivan Pavlov (1): 16414718f9ae wolfssl: update to 4.8.1-stable David Bauer (1): f6d8c0cf2b47 wolfssl: always export wc_ecc_set_rng Christian Lamparter (1): 86801bd3d806 wolfssl: fix Ed25519 typo in config prompt The diff of security related changes we would need to backport would be so huge, that there would be a high probability of introducing new vulnerabilities, so it was decided, that bumping to latest stable release is the prefered way for fixing following security issues: * OCSP request/response verification issue. (fixed in 4.8.0) * Incorrectly skips OCSP verification in certain situations CVE-2021-38597 (fixed in 4.8.1) * Issue with incorrectly validating a certificate (fixed in 5.0.0) * Hang with DSA signature creation when a specific q value is used (fixed in 5.0.0) * Client side session resumption issue (fixed in 5.1.0) * Potential for DoS attack on a wolfSSL client CVE-2021-44718 (fixed in 5.1.0) * Non-random IV values in certain situations CVE-2022-23408 (fixed in 5.1.1) Cc: Hauke Mehrtens Cc: Eneas U de Queiroz Signed-off-by: Petr Štetiar Acked-by: Hauke Mehrtens Acked-by: Eneas U de Queiroz

OpenWrt v19.07.9: revert to branch defaults

2022-02-17T18:43:38Z

Signed-off-by: Hauke Mehrtens