When using external targets there is a symlink being created for the
target under target/linux which then becomes dangling under Image
Builder. Fix it by dereferencing the possible symlink.
Tested on IB with external target, ipq40xx and mvebu.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 621f39d1f4)
(cherry picked from commit ec9af870f3)
(cherry picked from commit 3008f1f441)
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This is backport of upstream fix introduced in commit e88d83c8b4e4
("patchelf: Check ELF endianness before writing new runpath") which
fixes broken rpath handling on big endian systems:
$ patchelf --set-rpath '/opt/foo/bar' lxc4-start
$ readelf -d lxc4-start
...
0x1d000000 (<unknown>: 1d000000) 0x72f
...
Expected output, having following patch applied is:
$ readelf -d lxc4-start
...
0x0000001d (RUNPATH) Library runpath: [/opt/foo/bar]
...
Build and runtime tested on mvebu/turris-omnia, ipq40xx/glinet-b1300
and external target xrx500/nec-wx3000hp (MIPS BE).
Signed-off-by: Matthias Van Gestel <matthias.vangestel_ext@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The OCEDO Raccoon had significant packet-loss with cables longer than 50
meter. Disabling EEE restores normal operation.
Also change the ethernet config to reduce loss on sub-1G links.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 4551bfd91f)
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
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 <taviso@gmail.com>
References: https://www.openwall.com/lists/oss-security/2022/03/24/1
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit b3aa2909a7)
(cherry picked from commit 3965dda0fa)
(cherry picked from commit f65edc9b99)
Added new config symbol `HARDEN_BRANCH_HISTORY` in order to harden
Spectre style attacks against branch history and fixed rejects in
following patches:
* generic/hack-4.14/220-gc_sections.patch
* generic/backport-4.14/306-v4.16-netfilter-remove-saveroute-indirection-in-struct-nf_.patch
Other patches refreshed automagically.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
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 <ms@dev.tdt.de>
(cherry picked from commit e17c6ee627)
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 <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
(cherry picked from commit 9851d4b6ce)
When building images with the imagebuilder, the partition signature
never changes. The signature is generated by hashing SOURCE_DATE_EPOCH
and LINUX_VERMAGIC which are undefined. Prepopulate these variables, as
done by the SDK.
Signed-off-by: Matthew Gyurgyik <matthew@gyurgyik.io>
(cherry picked from commit aab36200e7)
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 <ynezz@true.cz>
(cherry picked from commit b9251e3b40)
(cherry picked from commit b99d7aecc8)
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 <ynezz@true.cz>
This is amalgamation of backported changes since 4.7.0-stable release:
Sergey V. Lobanov (2):
5b13b0b02c wolfssl: update to 5.1.1-stable
7d376e6e52 libs/wolfssl: add SAN (Subject Alternative Name) support
Andre Heider (3):
3f8adcb215 wolfssl: remove --enable-sha512 configure switch
249478ec48 wolfssl: always build with --enable-reproducible-build
4b212b1306 wolfssl: build with WOLFSSL_ALT_CERT_CHAINS
Ivan Pavlov (1):
16414718f9 wolfssl: update to 4.8.1-stable
David Bauer (1):
f6d8c0cf2b wolfssl: always export wc_ecc_set_rng
Christian Lamparter (1):
86801bd3d8 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 <hauke@hauke-m.de>
Cc: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
MikroTik released a 3rd revision of that board, virtually identical
to the previous one as far as software is concerned.
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [wixed typo]
All patches refreshed automagically without conflicts, but test builds
choked on new BPF_UNPRIV_DEFAULT_OFF kernel config symbol introduced in
upstream commit e69f08ba23a3 ("bpf: Add kconfig knob for disabling
unpriv bpf by default").
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This fixes some recent security problems in hostapd.
See here for details: https://w1.fi/security/2022-1
* CVE-2022-23303
* CVE-2022-23304
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes the following security problems:
* Zeroize several intermediate variables used to calculate the expected
value when verifying a MAC or AEAD tag. This hardens the library in
case the value leaks through a memory disclosure vulnerability. For
example, a memory disclosure vulnerability could have allowed a
man-in-the-middle to inject fake ciphertext into a DTLS connection.
* Fix a double-free that happened after mbedtls_ssl_set_session() or
mbedtls_ssl_get_session() failed with MBEDTLS_ERR_SSL_ALLOC_FAILED
(out of memory). After that, calling mbedtls_ssl_session_free()
and mbedtls_ssl_free() would cause an internal session buffer to
be free()'d twice. CVE-2021-44732
The sizes of the ipk changed on MIPS 24Kc like this:
182454 libmbedtls12_2.16.11-2_mips_24kc.ipk
182742 libmbedtls12_2.16.12-1_mips_24kc.ipk
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 57f38e2c82)
The http://www.us.tcpdump.org mirror will go offline soon, only use the
normal download URL.
Reported-by: Denis Ovsienko <denis@ovsienko.info>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 18bdfc803b)
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
[rebased for OpenWrt 21.02 branch]
(cherry picked from commit 4dddb7ca36)
This fixes the following security problem:
The command-line argument parser in tcpdump before 4.99.0 has a buffer
overflow in tcpdump.c:read_infile(). To trigger this vulnerability the
attacker needs to create a 4GB file on the local filesystem and to
specify the file name as the value of the -F command-line argument of
tcpdump.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 8f5875c4e2)
(cherry picked from commit 59e7ae8d65)
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The source date epoch is the only reproducible date close to the actual
build date. It can be used for tooling like the firmware wizard to show
the image age.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 165f0b00cd)
[store source_date_epoch as integer]
Signed-off-by: Paul Spooren <mail@aparcar.org>
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This is a bugfix release. Changelog:
*) Avoid loading of a dynamic engine twice.
*) Fixed building on Debian with kfreebsd kernels
*) Prioritise DANE TLSA issuer certs over peer certs
*) Fixed random API for MacOS prior to 10.12
Patches were refreshed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 5beaa75d94)
All patches refreshed automagically without conflicts.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
All patches refreshed automagically without conflicts, but upstream in
commit 48c2461f28fe ("ARM: 8800/1: use choice for kernel unwinders")
added new config options UNWINDER_ARM and UNWINDER_FRAME_POINTER so we
need to adjust default configs as well.
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Rebased patches:
* generic: 273-batman-adv-Convert-packet.h-to-uapi-header.patch
* ipq806x: 0065-arm-override-compiler-flags.patch
* mvebu: 513-arm64-dts-marvell-armada37xx-Add-emmc-sdio-pinctrl-d.patch
Removed patches:
Fixed upstream:
* ar71xx: 821-serial-core-add-support-for-boot-console-with-arbitr.patch
* ath79: 921-serial-core-add-support-for-boot-console-with-arbitr.patch
- in 4.14.256 via 9112e7ef87149b3d8093e7446d784117f6e18d69
* mvebu: 527-PCI-aardvark-allow-to-specify-link-capability.patch
- in 4.14.257 via 62a3dc9b65a2b24800fc4267b8cf590fad135034
* mvebu: 524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch
- should be hopefully fixed by the bunch of changes in .256 and .257
Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia.
Fixes: CVE-2021-3640
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The following patch was backported from upstream before and is not
needed any more:
package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When doing parallel build on a fast machine with bottleneck in i/o,
m_xt.so may start linking faster than dynsyms.list gets populated,
resulting in error:
ld:dynsyms.list:0: syntax error in dynamic list
Fix this by adding dynsyms.list as make dependency to m_xt.so
Described also here:
https://bugs.openwrt.org/index.php?do=details&task_id=3353
Change from v1:
- add dynsysms.list dependancy only when shared libs are enabled
Signed-off-by: Roman Yeryomin <roman@advem.lv>
Fixes: FS#3353
(cherry-picked from commit edd53df168)
Follow up to commit 8fb714edd6. Managed to
hit the very same issue again while playing with the NOR SPL builds.
Signed-off-by: Mathias Kresin <dev@kresin.me>
At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
assembly of LzmaProps_Decode. While the decission made by the compiler
looks perfect fine, it triggers some obscure hang on lantiq danube-s
v1.5 with MX29LV640EB NOR flash chips.
Only if the offset 1 is used, the hang can be observed. Using any other
offset works fine:
lwl s0,0(a1) - s0 == 0x6d000080
lwl s0,1(a1) - hangs
lwl s0,2(a1) - s0 == 0x0080xxxx
lwl s0,3(a1) - s0 == 0x80xxxxxx
It isn't clear whether it is a limitation of the flash chip, the EBU or
something else.
Force 8bit reads to prevent gcc optimizing the read with lwr/lwl
instructions.
Signed-off-by: Mathias Kresin <dev@kresin.me>
e983a25 Update regulatory rules for Ecuador (EC)
a0bcb88 wireless-regdb: Update regulatory rules for Norway (NO) on 6 and 60 GHz
cdf854d wireless-regdb: Update regulatory rules for Germany (DE) on 6GHz
86cba52 wireless-regdb: reduce bandwidth for 5730-5850 and 5850-5895 MHz in US
6fa2384 wireless-regdb: remove PTMP-ONLY from 5850-5895 MHz for US
9839e1e wireless-regdb: recent FCC report and order allows 5850-5895 immediately
42dfaf4 wireless-regdb: update 5725-5850 MHz rule for GB
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit dbb4c47798)
All updated automatically.
Compile-tested on: malta/le, lantiq/xrx200
Runtime-tested on: malta/le, lantiq/xrx200
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Extensive testing on the board showed that ethernet does
not work when forced to 10Mbps.
Trial-and-error revealed that the correct PLL value
should be altered to 0x00001313 (iso 0x00001616)
The change is done for this specific board only as I do not have
other boards using this specific SoC.
The board now works correctly in 1000, 100 and 10 Mode
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
All updated automatically.
Compile-tested on: lantiq/xrx200, armvirt/64
Runtime-tested on: lantiq/xrx200, armvirt/64
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It's not possible to compile some applications which are using
`-Werror=missing-include-dirs` compiler flags with the SDK as some
target directories are missing in the SDK tarball:
cc1: error: staging_dir/target/usr/include: No such file or directory [-Werror=missing-include-dirs]
cc1: error: staging_dir/target/include: No such file or directory [-Werror=missing-include-dirs]
Fix this by adding the missing directories in the SDK.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ec0ec0428e)
gcc 10 defaults to -fno-common, which causes an error
when linking.
Back-port the following Linux kernel commit to fix it:
e33a814e772c (scripts/dtc: Remove redundant YYLOC global declaration)
Tested on an Arch Linux host with gcc 10.1.0
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
(cherry picked from commit 8b870418f1)
The package uses the host compiler to build the dtc binary. With gcc-10,
the option -fno-common is now the default behavior. Thus multiple
definitions of the same variable are now forbidden and results in following
error during linking:
HOSTLD scripts/dtc/dtc
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
The easiest workaround is to add the upstream commit 018921ee79d3 ("Remove
redundant YYLOC global declaration").
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The package uses the host compiler to build the dtc binary. With gcc-10,
the option -fno-common is now the default behavior. Thus multiple
definitions of the same variable are now forbidden and results in following
error during linking:
HOSTLD scripts/dtc/dtc
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
The easiest workaround is to add the upstream commit 018921ee79d3 ("Remove
redundant YYLOC global declaration").
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Backport a patch from upstream U-Boot to fix the compile with host GCC 10.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 8d143784cb)
