This release of Mbed TLS provides bug fixes and minor enhancements. This
release includes fixes for following security issues:
* Timing side channel in private key RSA operations (CVE-2024-23170)
Mbed TLS is vulnerable to a timing side channel in private key RSA
operations. This side channel could be sufficient for an attacker to
recover the plaintext. A local attacker or a remote attacker who is
close to the victim on the network might have precise enough timing
measurements to exploit this. It requires the attacker to send a large
number of messages for decryption.
* Buffer overflow in mbedtls_x509_set_extension() (CVE-2024-23775)
When writing x509 extensions we failed to validate inputs passed in to
mbedtls_x509_set_extension(), which could result in an integer overflow,
causing a zero-length buffer to be allocated to hold the extension. The
extension would then be copied into the buffer, causing a heap buffer
overflow.
Fixes: CVE-2024-23170, CVE-2024-23775
References: https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-01-1/
References: https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-01-2/
Signed-off-by: orangepizza <tjtncks@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [formal fixes]
(cherry picked from commit 920414ca88)
While flashing sysupgrade image from U-Boot, then the rootfs_data
overlay filesystem formatting is left for the fstools during firstboot,
but that wont work as mkfs.f2fs is missing in the sysupgrade image:
mount_root: overlay filesystem in /dev/loop0 has not been formatted yet
mount_root: no usable overlay filesystem found, using tmpfs overlay
sh: mkfs.f2fs: not found
Filesystem Size Used Available Use% Mounted on
/dev/loop0 139.6M 46.9M 92.6M 34% /overlay
Number Start (sector) End (sector) Size Code Name
20 98850 406349 150.1 MiB FFFF rootfs
So lets fix it by adding f2fs support to the sysupgrade image.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ba415af570)
Use postinst script to reload service instead of uci-defaults hack. It's
possible thanks to recent base-files change that executes postinst after
uci-defaults.
This fixes support for uhttpd customizations. It's possible (again) to
adjust uhttpd config with custom uci-defaults before it gets started.
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Fixes: d25d281fd6 ("uhttpd: Reload config after uhttpd-mod-ubus was added")
Ref: b799dd3c70 ("base-files: execute package's "postinst" after executing uci-defaults")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 1f11a4e283)
Allow "postinst" scripts to perform extra actions after applying all
kind of fixups implemented using uci-defaults.
This is needed e.g. by uhttpd-mod-ubus which after installation in a
running systems needs to:
1. Update uhttpd config using its uci-defaults script
2. Reload uhttpd
While this approach makes sense there is a risk it'll blow up some
corner case postinst usages. There is only 1 way to find out.
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit b799dd3c70)
raspberrypi/firmware is about 40G, so getting the full history log isn't an
option.
There have been multiple improvements and also support for the RPi 5 has been
added.
(cherry picked from commit e8f5581701)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This is the last update for bcm27xx-userland as it has been
deprecated but funcional up to raspberry pi 5.
96a7334 README: Update to make it clear that most code in this repo is deprecated
3c97f76 userland: dtoverlay: /boot/firmware is a valid path
153a235 Assorted clang static analysis fixes
eca070c bcm_host: Update kms/fkms check for pi5
06a7618 dtoverlay: Support bcm2712 as a platform
0489c07 dtoverlay: Add dtoverlay_first/next_subnode
a1c7f81 dtoverlay: Support literal assignments of path strings
44a3953 raspivid: Also flush PTS file if flush is enabled
cc1ca18 userland: dtoverlay: Use os_prefix if set
9d5250f libfdt: Add null-ptr check for prop-data to resolve clang --analyzer warning
50527c6 mmal: Only include Videocore components if not running on Videocore
df245ea tvservice: Update unsupported message to recommend kmsprint
de0cfe8 dtoverlay: Fix clang warnings
0182f05 dtoverlay: Fix various compiler warnings
2a6306b dtoverlay: Fix path rebasing and exports
d1e92d7 dtoverlay: Add support for string escape sequences
b1ee39e gencmd: Add a fallback to mailbox interface if vchiq is not available
54fd97a hello_pi: Fix some build issues
Signed-off-by: Marty Jones <mj8263788@gmail.com>
(cherry picked from commit 3df664101a)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The original configuration might be copied from bcm2710 which uses
cortex A53 rather than A72 in BCM2711, without errata might be harmful
to system stability and security.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
(cherry picked from commit d549809c05)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The documentation links have changed and are no longer valid.
(cherry picked from commit 189838517e)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Booting from non-MMC devices on Rockchip targets without this
change results in a boot failure:
Model: FriendlyElec NanoPi R5S
Net: eth0: ethernet@fe2a0000
Hit any key to stop autoboot: 0
** Booting bootflow 'nvme#0.blk#1.bootdev.part_1' with script
** No partition table - mmc 0 **
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
Can't set block device
Wrong Image Type for bootm command
ERROR -91: Protocol wrong type for socket: can't get kernel image!
Boot failed (err=1)
This change fixes the default boot script for Rockchip targets to
support booting from non-MMC devices such as NVMe or USB drives.
Some targets with only a boot rom (e.g. NanoPi R5S) may require u-boot
to be installed on the eMMC or a MicroSD card in order to boot from
non-MMC devices.
Fixes: #14420
Reviewed-by: Tianling Shen <cnsztl@immortalwrt.org>
Signed-off-by: Justin Klaassen <justin@tidylabs.app>
(cherry picked from commit 4d49ce1bde)
Kernel 5.15 introduced a significant change to spi-nor subsystem [1],
which would the SPI-NOR core to no longer unprotect the Flash chips if
their protection bits are non-volatile, which is the case for MX25L6405D
and MX25L12805D, used in Ubiquiti XW and WA lines of devices [2].
However, their bootloader forcibly enables this protection before
continuing to boot, making the kernel not unprotect the flash upon boot,
causing JFFS2 to be unable write to the filesystem. Because sysupgrade
seems to unlock the flash explicitly, the upgrade will work, but the
system will be unable to save configrationm showing the following symptom
in the kernel log:
[ 86.168016] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[ 86.192344] jffs2_build_filesystem(): unlocking the mtd device...
[ 86.192443] done.
[ 86.200669] jffs2_build_filesystem(): erasing all blocks after the end marker...
[ 86.220646] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001e0000
[ 86.292388] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001d0000
[ 86.324867] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001c0000
[ 86.355316] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001b0000
[ 86.402855] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001a0000
Disable the write protection unconditionally for ath79/generic subtarget,
so the XW and WA devices can function again. However, this is only a
stopgap solution - it probably should be investigated if there is a way
to selectively unlock the area used by rootfs_data - but given the lock
granularity, this seems unlikely.
With this patch in place, rootfs_data partition on my Nanostation Loco
M5 XW is writable again.
Fixes: #12882Fixes: #13750
Fixes: 579703f38c ("ath79: switch to 5.15 as default kernel")
Link: http://www.infradead.org/pipermail/linux-mtd/2020-October/082805.html
Link: https://forum.openwrt.org/t/powerbeam-m5-xw-configuration-loss-after-reboot/141925
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
(cherry picked from commit f024f4b1b0)
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
The current dts file of dgs-1210-10p doesn't support link states
for the sfp ports (they are always up).
This patch tries to give better support for this and was run tested
on dgs-1210-10p.
It was already commited to the main branch.
Signed-off-by: Michel Thill <jmthill@gmail.com>
(cherry picked from commit 135e107620)
This wireless driver seems broken and causes kernel hang up.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit ef03ac6684)
(based on support for ASUS RT-AX59U by liushiyou006)
SOC: MediaTek MT7986
RAM: 512MB DDR4
FLASH: 128MB SPI-NAND (Winbond W25N01GV)
WIFI: Mediatek MT7986 DBDC 802.11ax 2.4/5 GHz
ETH: MediaTek MT7531 Switch
UART: 3V3 115200 8N1 (Pinout silkscreened / Do not connect VCC)
Upgrade from AsusWRT to OpenWRT using UART
Download the OpenWrt initramfs image.
Copy the image to a TFTP server reachable at 192.168.1.70/24. Rename the image to rtax59u.bin.
Connect the PC with TFTP server to the RT-AX59U.
Set a static ip on the ethernet interface of your PC.
(ip address: 192.168.1.70, subnet mask:255.255.255.0)
Conect to the serial console, interrupt the autoboot process by pressing '4' when prompted.
Download & Boot the OpenWrt initramfs image.
$ setenv ipaddr 192.168.1.1
$ setenv serverip 192.168.1.70
$ tftpboot 0x46000000 rtax59u.bin
$ bootm 0x46000000
Wait for OpenWrt to boot. Transfer the sysupgrade image to the device using scp and install using sysupgrade.
$ sysupgrade -n <path-to-sysupgrade.bin>
Upgrade from AsusWRT to OpenWRT using WebUI
Download transit TRX file from https://drive.google.com/drive/folders/1A20QdjK7Udagu31FSszpWAk8-cGlCwsq
Upgrade firmware from WebUI (192.168.50.1) using downloaded TRX file
Wait for OpenWRT to boot (192.168.1.1).
Upgrade system with sysupgrade image using luci or uploading it through scp and executing sysupgrade command
MAC Address for WLAN 5g is not following the same algorithm as in AsusWRT.
We have increased by one the WLAN 5g to avoid collisions with other networks from WLAN 2g
when bit 28 is already set.
: Stock : OpenWrt
WLAN 2g (1) : C8:xx:xx:0D:xx:D4 : C8:xx:xx:0D:xx:D4
WLAN 2g (2) : : CA:xx:xx:0D:xx:D4
WLAN 2g (3) : : CE:xx:xx:0D:xx:D4
WLAN 5g (1) : CA:xx:xx:1D:xx:D4 : CA:xx:xx:1D:xx:D5
WLAN 5g (2) : : CE:xx:xx:1D:xx:D5
WLAN 5g (3) : : C2:xx:xx:1D:xx:D5
WLAN 2g (1) : 08:xx:xx:76:xx:BE : 08:xx:xx:76:xx:BE
WLAN 2g (2) : : 0A:xx:xx:76:xx:BE
WLAN 2g (3) : : 0E:xx:xx:76:xx:BE
WLAN 5g (1) : 0A:xx:xx:76:xx:BE : 0A:xx:xx:76:xx:BF
WLAN 5g (2) : : 0E:xx:xx:76:xx:BF
WLAN 5g (3) : : 02:xx:xx:76:xx:BF
Signed-off-by: Xavier Franquet <xavier@franquet.es>
(cherry picked from commit 782eb05008)
[Upstream Backport]
The range for the 5 GHz channel 118 was encoded with an incorrect
channel number.
Fixes: ed8e13decc71 (ACS: Extract bw40/80/160 freqs out of acs_usable_bwXXX_chan())
Signed-off-by: Michael Lee <michael-cy.lee@mediatek.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 56d7887917)
Enabling SMP on the xway target results in two issues:
* some danube chipset-based devices fail on boot,
* on devices based on the arx100 chipset, enabling smp
results in a degradation of NAT performance.
After these two issues are fixed, SMP can be re-enabled.
This reverts commit 084c20f6c5.
Fixes: #13934Fixes: #14283
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Fine tuning PR: openwrt/openwrt#14355 Ref: 5a82bb909b
("mediatek: GL-MT6000: Add missing LED state definitions")
As the only LED is using white in the stock firmware when the device is
running and blue for the bootloader I suggest following changes:
- Using blue for the BL and preinit+failsafe
- White for normal operation (like the original FW) and sysupgrade
With this changes it's clear by looking to the LED in which operation
mode the device is and a possible BL stuck can be seen easily.
Tested with [GL-MT6000](https://openwrt.org/toh/gl.inet/gl-mt6000).
Signed-off-by: Thomas Schröder <tschroeder_github@outlook.com>
Tested-by: Hannu Nyman <hannu.nyman@iki.fi>
(cherry picked from commit 4d7bac1dca)
Router Asus TUF AX6000 have second MaxLinear GPY211 PHY controller for 2.5Gb LAN port.
The 5'th LAN port have inverted status of the LED.
Based on the commit from main branch 90fbec8 we could set proper status of the LED.
Signed-off-by: Patryk Kowalczyk <patryk@kowalczyk.ws>
(cherry picked from commit b22539b5fe)
(based on support for ASUS RT-AX59U by liushiyou006)
SOC: MediaTek MT7986
RAM: 512MB DDR4
FLASH: 128MB SPI-NAND (Winbond W25N01GV)
WIFI: Mediatek MT7986 DBDC 802.11ax 2.4/5 GHz
ETH: MediaTek MT7531 Switch
UART: 3V3 115200 8N1 (Pinout silkscreened / Do not connect VCC)
Upgrade from AsusWRT to OpenWRT using UART
Download the OpenWrt initramfs image.
Copy the image to a TFTP server reachable at 192.168.1.70/24. Rename the image to rtax59u.bin.
Connect the PC with TFTP server to the RT-AX59U.
Set a static ip on the ethernet interface of your PC.
(ip address: 192.168.1.70, subnet mask:255.255.255.0)
Conect to the serial console, interrupt the autoboot process by pressing '4' when prompted.
Download & Boot the OpenWrt initramfs image.
$ setenv ipaddr 192.168.1.1
$ setenv serverip 192.168.1.70
$ tftpboot 0x46000000 rtax59u.bin
$ bootm 0x46000000
Wait for OpenWrt to boot. Transfer the sysupgrade image to the device using scp and install using sysupgrade.
$ sysupgrade -n <path-to-sysupgrade.bin>
Upgrade from AsusWRT to OpenWRT using WebUI
Download transit TRX file from https://drive.google.com/drive/folders/1A20QdjK7Udagu31FSszpWAk8-cGlCwsq
Upgrade firmware from WebUI (192.168.50.1) using downloaded TRX file
Wait for OpenWRT to boot (192.168.1.1).
Upgrade system with sysupgrade image using luci or uploading it through scp and executing sysupgrade command
MAC Address for WLAN 5g is not following the same algorithm as in AsusWRT.
We have increased by one the WLAN 5g to avoid collisions with other networks from WLAN 2g
when bit 28 is already set.
: Stock : OpenWrt
WLAN 2g (1) : C8:xx:xx:0D:xx:D4 : C8:xx:xx:0D:xx:D4
WLAN 2g (2) : : CA:xx:xx:0D:xx:D4
WLAN 2g (3) : : CE:xx:xx:0D:xx:D4
WLAN 5g (1) : CA:xx:xx:1D:xx:D4 : CA:xx:xx:1D:xx:D5
WLAN 5g (2) : : CE:xx:xx:1D:xx:D5
WLAN 5g (3) : : C2:xx:xx:1D:xx:D5
WLAN 2g (1) : 08:xx:xx:76:xx:BE : 08:xx:xx:76:xx:BE
WLAN 2g (2) : : 0A:xx:xx:76:xx:BE
WLAN 2g (3) : : 0E:xx:xx:76:xx:BE
WLAN 5g (1) : 0A:xx:xx:76:xx:BE : 0A:xx:xx:76:xx:BF
WLAN 5g (2) : : 0E:xx:xx:76:xx:BF
WLAN 5g (3) : : 02:xx:xx:76:xx:BF
Signed-off-by: Xavier Franquet <xavier@franquet.es>
(cherry picked from commit 782eb05008)
Read back the reset register in order to flush the cache. This fixes
spurious reboot hangs on TP-Link TL-WDR3600 and TL-WDR4300 with Zentel
DRAM chips.
This issue was fixed in the past, but switching to the reset-driver
specific implementation removed the cache barrier which was previously
implicitly added by reading back the register in question.
Link: https://github.com/freifunk-gluon/gluon/issues/2904
Link: https://github.com/openwrt/openwrt/issues/13043
Link: https://dev.archive.openwrt.org/ticket/17839
Link: f8a7bfe1cb2c ("MIPS: ath79: fix system restart")
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 2fe8ecd880)
Hardware
--------
CPU: Qualcomm Atheros QCA9563
RAM: 128M DDR2
FLASH: 16MB SPI-NOR
WiFi: Qualcomm Atheros QCA9563 2x2:2 802.11n 2.4GHz
Qualcomm Atheros QCA9880 2x2:2 802.11ac 5GHz
Antennas
--------
The device features internal antennas as well as external antenna
connectors. By default, the internal antennas are used.
Two GPIOs are exported by name, which can be used to control the
antenna-path mux. Writing a logical 0 enables the external antenna
connectors.
Installation
------------
1. Download the OpenWrt sysupgrade image to the device. You can use scp
for this task. The default username and password are "ubnt" and the
device is reachable at 192.168.1.20.
$ scp -O openwrt-sysupgrade.bin ubnt@192.168.1.20:/tmp/firmware.bin
2. Connect to the device using SSH.
$ ssh ubnt@192.168.1.20
3. Disable the write-protect
$ echo "5edfacbf" > /proc/ubnthal/.uf
4. Verify kernel0 and kernel1 match mtd2 and mtd3
$ cat /proc/mtd
5. Write the sysupgrade image to kernel0 and kernel1
$ dd if=/tmp/firmware.bin of=/dev/mtdblock2
$ dd if=/tmp/firmware.bin of=/dev/mtdblock3
6. Write the bootselect flag to boot from kernel0
$ dd if=/dev/zero bs=1 count=1 of=/dev/mtd4
7. Reboot the device
$ reboot
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit bf94e0a383)
This allows us to embrace alphabetical sorting for the UK-Ultra.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit c9e58f85f6)
Setting/clearing bits on the first byte of the mac address causes collisions
when using multiple SSIDs on both PHYs. Change the allocation to alter the
last byte instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 38bec08e87)
Frequent crashes have been observed on MT7916 based platforms. While the
root of these crashes are currently unknown, they happen when decoding
rate information of connected STAs in AP mode. The rate-information is
associated with a band which is not available on the PHY.
Check for this condition in order to avoid crashing the whole system.
This patch should be removed once the roout cause has been found and
fixed.
Link: https://github.com/freifunk-gluon/gluon/issues/2980
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 1278d47bea)
Adjust LED names and provide the OpenWrt status indicator aliases
to actually use LEDs by the OpenWrt boot & sysupgrade processes.
* Name both LEDs clearly by the color
* Add the missing OpenWrt LED status indicator aliases and
remove the now unnecessary default status from blue LED
After this commit, the LEDs are used as:
* bootloader, really early Linux boot: blue LED is on
* preinit/failsafe: white LED blinks rapidly
* late boot: white LED blinks slowly
* boot completed, running normally: blue LED is on
* sysupgrade: white LED blinks
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
(cherry picked from commit 5a82bb909b)
The COVR-X1860 are MT7621-based AX1800 devices (similar to DAP-X1860, but
with two Ethernet ports and external power supply) that are sold in sets
of two (COVR-X1862) and three (COVR-X1863).
Specification:
- MT7621
- MT7915 + MT7975 2x2 802.11ax (DBDC)
- 256MB RAM
- 128 MB flash
- 3 LEDs (red, orange, white), routed to one indicator in the top of the device
- 2 buttons (WPS in the back and Reset at the bottom of the device)
MAC addresses:
- LAN MAC (printed on the device) is stored in config2 partition as ASCII (entry factory_mac=xx:xx:xx:xx:xx:xx)
- WAN MAC: LAN MAC + 3
- 2.4G MAC: LAN MAC + 1
- 5G MAC: LAN MAC + 2
The pins for the serial console are already labeled on the board (VCC, TX, RX, GND). Serial settings: 3.3V, 115200,8n1
Flashing via OEM Web Interface:
- Download openwrt-ramips-mt7621-dlink_covr-x1860-a1-squashfs-factory.bin via the OEM web interface firmware update
- The configuration wizard can be skipped by directly going to http://192.168.0.1/UpdateFirmware_Simple.html
Flashing via Recovery Web Interface:
- Set your IP address to 192.168.0.10, subnetmask 255.255.255.0
- Press the reset button while powering on the deivce
- Keep the reset button pressed until the status LED blinks red
- Open a Chromium based browser and goto http://192.168.0.1
- Download openwrt-ramips-mt7621-dlink_covr-x1860-a1-squashfs-recovery.bin
Revert back to stock using the Recovery Web Interface:
- Set your IP address to 192.168.0.10, subnetmask 255.255.255.25
- Press the reset button while powering on the deivce
- Keep the reset button pressed until the status LED blinks red
- Open a Chromium based browser and goto http://192.168.0.1
- Flash a decrypted firmware image from D-Link. Decrypting an firmware image is described below.
Decrypting a D-Link firmware image:
- Download https://github.com/openwrt/firmware-utils/blob/master/src/dlink-sge-image.c and https://raw.githubusercontent.com/openwrt/firmware-utils/master/src/dlink-sge-image.h
- Compile a binary from the downloaded file, e.g. gcc dlink-sge-image.c -lcrypto -o dlink-sge-image
- Run ./dlink-sge-image COVR-X1860 <OriginalFirmware> <OutputFile> -d
- Example for firmware 102b01: ./dlink-sge-image COVR-X1860 COVR-X1860_RevA_Firmware_102b01.bin COVR-X1860_RevA_Firmware_102b01_Decrypted.bin -d
The pull request is based on the discussion in https://forum.openwrt.org/t/add-support-for-d-link-covr-x1860
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
(cherry picked from commit 0a18259e4a)
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
creates SGE encrypted factory images
to use via the D-Link web interface
rename the old factory unencrypted images to recovery
for use in the recovery console when recovery is needed
adjusted to not touch unrelated devices
Signed-off-by: Alan Luck <luckyhome2008@gmail.com>
(cherry picked and adjusted from commit 4c0dc68f46)
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
Patch "firmware-utils: ptgen: add SiFive GPT partition support" was
included as a separate change in 23.05. Now that we have a maintenance
branch for firmware-utils, the patch can be backported there and
included with other changes.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
