Hauke Mehrtens [Mon, 11 Jan 2021 00:03:03 +0000 (01:03 +0100)]
dnsmasq: Backport some security updates
This fixes the following security problems in dnsmasq:
* CVE-2020-25681:
Dnsmasq versions before 2.83 is susceptible to a heap-based buffer
overflow in sort_rrset() when DNSSEC is used. This can allow a remote
attacker to write arbitrary data into target device's memory that can
lead to memory corruption and other unexpected behaviors on the target
device.
* CVE-2020-25682:
Dnsmasq versions before 2.83 is susceptible to buffer overflow in
extract_name() function due to missing length check, when DNSSEC is
enabled. This can allow a remote attacker to cause memory corruption
on the target device.
* CVE-2020-25683:
Dnsmasq version before 2.83 is susceptible to a heap-based buffer
overflow when DNSSEC is enabled. A remote attacker, who can create
valid DNS replies, could use this flaw to cause an overflow in a heap-
allocated memory. This flaw is caused by the lack of length checks in
rtc1035.c:extract_name(), which could be abused to make the code
execute memcpy() with a negative size in get_rdata() and cause a crash
in Dnsmasq, resulting in a Denial of Service.
* CVE-2020-25684:
A lack of proper address/port check implemented in Dnsmasq version <
2.83 reply_query function makes forging replies easier to an off-path
attacker.
* CVE-2020-25685:
A lack of query resource name (RRNAME) checks implemented in Dnsmasq's
versions before 2.83 reply_query function allows remote attackers to
spoof DNS traffic that can lead to DNS cache poisoning.
* CVE-2020-25686:
Multiple DNS query requests for the same resource name (RRNAME) by
Dnsmasq versions before 2.83 allows for remote attackers to spoof DNS
traffic, using a birthday attack (RFC 5452), that can lead to DNS
cache poisoning.
* CVE-2020-25687:
Dnsmasq versions before 2.83 is vulnerable to a heap-based buffer
overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A
remote attacker, who can create valid DNS replies, could use this flaw
to cause an overflow in a heap-allocated memory. This flaw is caused
by the lack of length checks in rtc1035.c:extract_name(), which could
be abused to make the code execute memcpy() with a negative size in
sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of
Service.
Hauke Mehrtens [Mon, 18 Jan 2021 20:52:48 +0000 (21:52 +0100)]
uboot-at91: Add PKG_MIRROR_HASH to fix download
The referenced commit is gone, but we already have this file on our
mirror, use that one by providing the correct mirror hash.
I generated a tar.xz file with the given git commit hash using a random
fork on github and it generated the same tar.xz file as found on our
mirror so this looks correct.
Hauke Mehrtens [Mon, 18 Jan 2021 20:50:26 +0000 (21:50 +0100)]
at91bootstrap: Add PKG_MIRROR_HASH to fix download
The referenced commit is gone, but we already have this file on our
mirror, use that one by providing the correct mirror hash.
I generated a tar.xz file with the given git commit hash using a random
fork on github and it generated the same tar.xz file as found on our
mirror so this looks correct.
Hauke Mehrtens [Sat, 9 Jan 2021 20:44:53 +0000 (21:44 +0100)]
kernel: bump 4.14 to 4.14.214
Refreshed all patches.
Removed patches because included in upstream:
- 499-mtd-parser-cmdline-Fix-parsing-of-part-names-with-co.patch
- 0071-2-PCI-qcom-Fixed-IPQ806x-PCIE-reset-changes.patch
Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x
Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64
Sven Roederer [Sun, 27 Sep 2020 21:07:38 +0000 (23:07 +0200)]
build, imagebuilder: Do not require compilers
The buildroot and SDK both require the compilers (gcc, g++) to be
installed on the host system, however the ImageBuilder uses precompiled
binaries.
This patch changes the prerequirements checks to skip the checking for
the compilers if running as ImageBuilder. A similar change has been
made for libncurses-dev in 4a1a58a3e2d2.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de> Acked-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit ae12a747cae3df16d84b7dc92f39427948d4e8e2)
Paul Spooren [Mon, 14 Dec 2020 00:36:17 +0000 (14:36 -1000)]
build/json: add filesystem information
Some images are created using different filesystems, most popular
squashfs and ext4. To allow downstream projects to distinguesh between
those, add the `filesystem` information to created json files.
where tplink-v1 defines KERNEL_INITRAMFS with tplink-v1-header and it's
then used by all devices inheriting from tplink-safeloader. Fix this by
overriding KERNEL_INITRAMFS to KERNEL variable again.
Previously only the power LED was working.
With this patch all leds except 5GHz are working.
Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
[rephrased commit title, drop status property] Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 67d019ac94015707926235a3ac0aa6bb12cee8c2)
David Bauer [Sun, 29 Nov 2020 18:14:05 +0000 (19:14 +0100)]
generic: ipeth: fix iOS 14 tethering
This fixes tethering with devices using iOS 14. Prior to this patch,
connections to remote endpoints were not possible while data transfers
between the OpenWrt device and the iOS endpoints worked fine.
It seems like after a build the /dl dir seems to now contain a .hash
file for each source file due to inproper cleanup so fix it by removing
those intermediate files before leaving the download action.
Fixes: 4e19cbc55335 ("download: handle possibly invalid local tarballs") Reported-by: Hannu Nyman <hannu.nyman@iki.fi> Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 52a5d0d27f2557db99fc5435fbd7783b649cb9b2)
Petr Štetiar [Thu, 19 Nov 2020 15:32:46 +0000 (16:32 +0100)]
download: handle possibly invalid local tarballs
Currently it's assumed, that already downloaded tarballs are always
fine, so no checksum checking is performed and the tarball is used even
if it might be corrupted.
From now on, we're going to always check the downloaded tarballs before
considering them valid.
Petr Štetiar [Fri, 27 Nov 2020 21:50:32 +0000 (22:50 +0100)]
cmake.mk,rules.mk: fix host builds using CMake and ccache
Commit f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as
well") has introduced regression as it didn't taken usage of ccache into
the account so fix it by handling ccache use cases as well.
In order to get this working we need to export HOSTCXX_NOCACHE in
rules.mk as well.
Fixes: f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as well") Reported-by: Ansuel Smith <ansuelsmth@gmail.com> Tested-by: Ansuel Smith <ansuelsmth@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 524fb5646eec6147aadfdd508219f39bcf8ba8fc)
Klaus Kudielka [Fri, 27 Dec 2019 13:26:37 +0000 (14:26 +0100)]
mvebu: fixup Turris Omnia U-Boot environment
Fixup dfa357a3de "mvebu: base-files: Update Turris Omnia U-Boot
environment" which should have included this file as well.
By rebasing the initial patch this file somehow disappeared.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia)
[explain fixup in commit message] Signed-off-by: Paul Spooren <mail@aparcar.org>
(backported from commit 485ce5bbe5cc33526e56817694a79a7d94160e01) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Klaus Kudielka [Fri, 27 Dec 2019 13:26:37 +0000 (14:26 +0100)]
mvebu: base-files: Update Turris Omnia U-Boot environment
Move the update procedure from sysupgrade to first boot, which is much
more convenient in the sysupgrade case (otherwise the environment is
always one generation behind).
Check whether we have an old U-Boot release installed, and update the
environment only if necessary.
Some notes on the U-Boot environment:
The first 9 lines are a copy of the default environment of the old U-Boot
release - only modified, to run "distro_bootcmd", in case "mmcboot" fails
to boot the factory OS.
The remaining 16 lines are a backport of the default environment of the
new U-Boot release (shipped with CZ11NIC23). The main entry point is
"distro_bootcmd", which eventually sources boot.scr. This way, we have
a unified boot protocol for all Turris Omnia revisions so far.
This commit also fixes a shortcoming of previous Turris Omnia support:
Users may install OpenWrt with the Turris Omnia in factory state
(i.e. invalid environment store). In that case, neither fw_setenv, nor
U-Boot itself, would import the default environment from the image -
screwing up the rescue system, at least!
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia)
(cherry picked from commit dfa357a3def512c13f22371d24138b6e8093be18)
Klaus Kudielka [Mon, 23 Dec 2019 07:34:49 +0000 (08:34 +0100)]
mvebu: Add turris-omnia.bootscript
In contrast to the U-Boot version shipped with older versions of Turris
Omnia (CZ11NIC13, CZ11NIC20), the version shipped with Turris Omnia 2019
(CZ11NIC23) relies on the existence of /boot.scr.
Consequently, add a suitable boot script to the sysupgrade image.
Flash instructions for Turris Omnia 2019:
- Download openwrt-...-sysupgrade.img.gz, gunzip it, and copy the resulting
.img file to the root of a USB flash drive (FAT32 or ext2/3/4).
- Enter a rescue shell: Either via 5-LED reset and ssh root@192.168.1.1
on LAN port 4, or via 7-LED reset and the serial console.
- Insert the USB drive and mount it:
mkdir /mnt; mount /dev/sda1 /mnt
- Flash the OpenWrt image to eMMC:
dd if=/mnt/openwrt-...-sysupgrade.img of=/dev/mmcblk0 bs=4096 conv=fsync
- Reboot.
Flash instructions using a temporary "medkit" installation were written for
the older versions of Turris Omnia, and will *not* work on the Turris Omnia
2019.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020")
(cherry picked from commit afd4375a33840fa949c898fb6bc603e8645edd61)
Klaus Kudielka [Fri, 27 Dec 2019 18:15:31 +0000 (19:15 +0100)]
uboot-envtools: mvebu: update uci defaults for Turris Omnia
On the Turris Omnia 2019, u-boot environment is located at 0xF0000, instead
of 0xC0000. The switch happened with u-boot-omnia package version 2019-04-2
(May 10, 2019).
Check the installed u-boot release, and set the default accordingly.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
[bump PKG_RELEASE, use lower case for hex offset] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 04d3b517dc3301e0148a2ce811ffc136568b04bd)
Alberto Bursi [Tue, 17 Nov 2020 07:58:40 +0000 (08:58 +0100)]
wireguard-tools: fix category/description in menuconfig
wireguard-tools is trying to import the menuconfig section
from the wireguard package, but since it's not anymore in
the same makefile this seems to fail and wireguard-tools
ends up in "extra packages" category instead with other
odds and ends.
Same for the description, it's trying to import it from the
wireguard package but it fails so it only shows the line
written in this makefile.
remove the broken imports and add manually the entries
and description they were supposed to load
Fixes: ea980fb9c6de ("wireguard: bump to 20191226") Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
[fix trailing whitespaces, add Fixes] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit a4d52522c7fbc47a04215b8f04a2e1f7cf7aafea)
David Bauer [Sat, 28 Nov 2020 11:38:22 +0000 (12:38 +0100)]
ipq40xx: disable double-tagging for PSGMII devices
This commit disables the double tagging recently backported to 19.07.
Operating the switch on the S-Tag had the advantage of being able to
have separate VLANs for the same C-VID on LAN and WAN. However, this
broke the ability to configure C-TAG modifications on the switch. Also
performance took a significant toll.
Sven Eckelmann [Sun, 22 Nov 2020 00:17:35 +0000 (01:17 +0100)]
kernel: mtd: parser: cmdline: Fix parsing of part-names with colons
Some devices (especially QCA ones) are already using hardcoded partition
names with colons in it. The OpenMesh A62 for example provides following
mtd relevant information via cmdline:
Such a partition list cannot be parsed and thus the device fails to boot.
Avoid this behavior by making sure that the start of the first part-name
("(") will also be the last byte the mtd-id split algorithm is using for
its colon search.
Fixes: 9c718b5478ac ("kernel: bump 4.14 to 4.14.200") Signed-off-by: Sven Eckelmann <sven@narfation.org>
(backported from commit 223eec7e81f8506592fc89cf79a2f14360f5c57b)
Commit c9c7b4b3945c ("kernel: add netfilter-actual-sk patch") has
touched net/ipv6/netfilter/ip6table_mangle.c which in turn has affected
910-unaligned_access_hacks.patch so the patch needs to be refreshed.
Fixes: c9c7b4b3945c ("kernel: add netfilter-actual-sk patch") Signed-off-by: Petr Štetiar <ynezz@true.cz>
The wcsnrtombs function in all musl libc versions up through 1.2.1 has
been found to have multiple bugs in handling of destination buffer
size when limiting the input character count, which can lead to
infinite loop with no forward progress (no overflow) or writing past
the end of the destination buffera.
This function is not used internally in musl and is not widely used,
but does appear in some applications. The non-input-limiting form
wcsrtombs is not affected.
All users of musl 1.2.1 and prior versions should apply the attached
patch, which replaces the overly complex and erroneous implementation.
The upcoming 1.2.2 release will adopt this new implementation.
David Bauer [Wed, 18 Nov 2020 15:02:23 +0000 (16:02 +0100)]
scripts: download.pl: retry download using filename
With this commit, the download script will try downloading source files
using the filename instead of the url-filename in case the previous
download attempt using the url-filename failed.
This is required, as the OpenWrt sources mirrors serve files using the
filename files might be renamed to after downloading. If the original
mirror for a file where url-filename and filename do not match goes
down, the download failed prior to this patch.
Further improvement can be done by performing this only for the
OpenWrt sources mirrors.
Roger Pueyo Centelles [Thu, 24 Oct 2019 13:29:14 +0000 (15:29 +0200)]
ath79: remove wmac mtd-mac-address for UniFi AC family
The MAC address for the wmac 2.4 GHz radio of the Ubiquiti UniFi AC
family of devices is actually embedded in the mtd-cal-data, so there
is no need for mtd-mac-address (which was incorrectly forcing wmac
to have the same MAC as eth0). This makes it coherent with the stock
firmware and the ar71xx target:
Sven Roederer [Mon, 11 May 2020 19:29:10 +0000 (21:29 +0200)]
feeds: add freifunk feed
Read the freifunk packages, that have been moved from the LuCI feed
into its own feed in January 2019.
Use openwrt-19.07 branch of that repository for openwrt-19.07.
Signed-off-by: Sven Roederer <freifunk@it-solutions.geroedel.de>
(cherry picked from commit 221f97ff4737f012c90feb086bc1c2ed86c6001b) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
David Bauer [Sat, 31 Oct 2020 15:41:04 +0000 (16:41 +0100)]
ath79: use correct firmware name for UniFi AP
The Ubiquiti UniFi AP does not have a AHB connected radio but a PCI one.
Also the EEPROM ist only 0x440 bytes of length.
Reported-by: Martin Weinelt <martin@darmstadt.freifunk.net> Tested-by: Martin Weinelt <martin@darmstadt.freifunk.net> Signed-off-by: David Bauer <mail@david-bauer.net>
(backported from commit 4c5eb1040f94871626f6a533242c3a9c068d5bb6) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
David Bauer [Wed, 26 Aug 2020 13:39:54 +0000 (15:39 +0200)]
ramips: fix logic level for DIR-645 buttons
The D-Link DIR-645 currently uses an incorrect logic level for its
buttons.
Correct them in order to prevent unintentional activation of failsafe
mode.
Reported-by: Perry Melange <isprotejesvalkata@gmail.com> Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 929e8f0f553637076f2612fb1c2225c5cee1f7ab)
Adrian Schmutzler [Sun, 27 Sep 2020 13:51:18 +0000 (15:51 +0200)]
ath79: fix LED labels for PowerCloud CAP324
The order of function and color in the labels in inverted for the
LAN LEDs. Fix it.
Fixes: 915966d86121 ("ath79: Port PowerCloud Systems CAP324 support") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 96023cd4ba66c33e77d9df562dda44b0a1ba1ac9)
Andre Heider [Sat, 12 Sep 2020 07:32:41 +0000 (09:32 +0200)]
mvebu: Add bootscript for espressobin to support mainline firmware
The generic bootscript is tailored around a downstream firmware and
doesn't work on a firmware built from mainline components.
Add a bootscript which:
* sets $console since mainline u-boot doesn't do that
* uses distro boot variables, so OpenWRT can be booted off any supported
device when using a mainline firmware
* sets missing distro boot variables for the downstream firmware
Booting with a downstream firmware is unchanged.
Booting with a mainline firmware now works.
* New upstream microcode datafile 20200616
+ Downgraded microcodes (to a previously shipped revision):
sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
sig 0x000506e3, pf_mask 0x36, 2019-10-03, rev 0x00d6, size 101376
* Works around hangs on boot on Skylake-U/Y and Skylake Xeon E3,
* This update *removes* the SRBDS mitigations from the above processors
* Note that Debian had already downgraded 0x406e3 in release 3.20200609.2
* REGRESSION FIX: 0x406e3: rollback to rev 0xd6 and document regression
* Microcode rollbacks (closes: LP#1883002)
sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
* THIS REMOVES THE SECURITY FIXES FOR SKYLAKE-U/Y PROCESSORS
* Avoid hangs on boot on (some?) Skylake-U/Y processors,
* ucode-blacklist: blacklist models 0x8e and 0x9e from late-loading,
just in case. Note that Debian does not do late loading by itself.
Refer to LP#1883002 for the report, 0x806ec hangs upon late load.
* SECURITY UPDATE
* For most processors: SRBDS and/or VRDS, L1DCES mitigations depending
on the processor model
* For Skylake HEDT and Skylake Xeons with signature 0x50654: VRDS and
L1DCES mitigations, plus mitigations described in the changelog entry
for package release 3.20191112.1.
* Expect some performance impact, the mitigations are enabled by
default. A Linux kernel update will be issued that allows one to
selectively disable the mitigations.
* New upstream microcode datafile 20200609
* Implements mitigation for CVE-2020-0543 Special Register Buffer Data
Sampling (SRBDS), INTEL-SA-00320, CROSSTalk
* Implements mitigation for CVE-2020-0548 Vector Register Data Sampling
(VRDS), INTEL-SA-00329
* Implements mitigation for CVE-2020-0549 L1D Cache Eviction Sampling
(L1DCES), INTEL-SA-00329
* Known to fix the regression introduced in release 2019-11-12 (sig
0x50564, rev. 0x2000065), which would cause several systems with
Skylake Xeon, Skylake HEDT processors to hang while rebooting
* Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552
sig 0x000306d4, pf_mask 0xc0, 2019-11-12, rev 0x002f, size 19456
sig 0x00040651, pf_mask 0x72, 2019-11-12, rev 0x0026, size 22528
sig 0x00040661, pf_mask 0x32, 2019-11-12, rev 0x001c, size 25600
sig 0x00040671, pf_mask 0x22, 2019-11-12, rev 0x0022, size 14336
sig 0x000406e3, pf_mask 0xc0, 2020-04-27, rev 0x00dc, size 104448
sig 0x00050653, pf_mask 0x97, 2020-04-24, rev 0x1000157, size 32768
sig 0x00050654, pf_mask 0xb7, 2020-04-24, rev 0x2006906, size 34816
sig 0x00050656, pf_mask 0xbf, 2020-04-23, rev 0x4002f01, size 52224
sig 0x00050657, pf_mask 0xbf, 2020-04-23, rev 0x5002f01, size 52224
sig 0x000506e3, pf_mask 0x36, 2020-04-27, rev 0x00dc, size 104448
sig 0x000806e9, pf_mask 0x10, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806e9, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806ea, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806eb, pf_mask 0xd0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806ec, pf_mask 0x94, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906e9, pf_mask 0x2a, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906ea, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
sig 0x000906eb, pf_mask 0x02, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906ec, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
sig 0x000906ed, pf_mask 0x22, 2020-04-23, rev 0x00d6, size 103424
* Restores the microcode-level fixes that were reverted by release
3.20191115.2 for sig 0x50654 (Skylake Xeon, Skylake HEDT)
* New microcode update packages from AMD upstream:
+ Removed Microcode updates (known to cause issues):
sig 0x00830f10, patch id 0x08301025, 2019-07-11
* README: update for new release
* New microcode update packages from AMD upstream:
+ New Microcodes:
sig 0x00830f10, patch id 0x08301025, 2019-07-11
+ Updated Microcodes:
sig 0x00800f12, patch id 0x08001250, 2019-04-16
sig 0x00800f82, patch id 0x0800820d, 2019-04-16
firewall: options: fix parsing of boolean attributes
Boolean attributes were parsed the same way as string attributes,
so a value of { "bool_attr": "true" } would be parsed correctly, but
{ "bool_attr": true } (without quotes) was parsed as false.
reg accesses on integrated ar8229 sometimes fails. As a result, phy read
got incorrect port status and wan link goes down and up mysteriously.
After comparing ar8216 with the old driver, these local_irq_save/restore
calls are the only meaningful differences I could find and it does fix
the issue.
The same changes were added in svn r26856 by Gabor Juhos:
ar71xx: ag71xx: make switch register access atomic
As I can't find the underlying problem either, this hack is broght
back to fix the unstable link issue.
This hack is only suitable for ath79 mdio and may easily break the
driver on other platform. Limit it to ath79-only as a target patch.
The number of local commits (1004 in this case) is wrong because it is
computed against master. As a result, it wrongly counts *all* commits
since the beginning of the openwrt-19.07 branch as local commits.
The fix is to compare to the openwrt-19.07 branch instead, which gives the
expected result such as:
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 06f510df6e2aa0b1e40124bbd758672458d01482)
[adapt variables and package names because we did not backport 2e5e9b459ed5 ("ath10k-ct-firmware: rename ct-htt packages")] Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
* March 19, 2020: Fix problem where power-save was not enabled when going off-channel to scan.
The problem was a boolean logic inversion in the chmgr code, a regression I introduced
a long time ago.
* March 19, 2020: When scanning only on current working channel, do not bother with disable/enable
powersave. This should make an on-channel scan less obtrusive than it was previously.
* March 23, 2020: Fix channel-mgr use-after-free problem that caused crashes in some cases. The crash
was exacerbated by recent power-save changes.
* March 23, 2020: Fix station-mode power-save related crash: backported the fix from 10.2 QCA firmware.
* March 23, 2020: Attempt to better clean up power-save objects and state, especially in station mode.
Release notes for 016:
Wave-1 changes, some debugging code for a crash someone reported, plus:
* February 28, 2020: Fix custom-tx path when sending in 0x0 for rate-code. Have tries == 0 mean
one try but NO-ACK (similar to how wave-2 does it).
wave-2:
* Fixed some long-ago regressions related to powersave and/or multicast. Maybe fix some
additional multicast and/or tx-scheduling bugs.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 84f4a783c6987fd9d67c089a76e2f90b7491f446)
Michael Yartys [Thu, 3 Sep 2020 20:56:47 +0000 (22:56 +0200)]
ath10k-firmware: update ath10k-ct firmware
This supports better per-chain noise floor reporting, which in turn allows for
better RSSI reporting in the driver.
Wave-2 fixes a long-standing rate-ctrl problem when connected to xbox (and probably other devices).
Wave-2 has fix for crash likely related to rekeying.
Wave-1 has some debugging code added where a user reported a crash.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq806x+qca9984,ipq4019+qca9986] Signed-off-by: Michael Yartys <michael.yartys@protonmail.com>
(cherry picked from commit 18622638831707038556b9b8bd5a0b4d4a53ce53)
* No changes to wave-1, but I make a version .014 copy anyway to keep
the makefile in sync.
The release notes since last time for wave-2:
* December 16, 2019: Wave-2 has a fix to make setting txpower work
better. Before setting the power was ignored at
least some of the time (it also appeared to work
mostly, so I guess it was being correctly set in
other ways).
NeilBrown [Tue, 29 Oct 2019 17:23:28 +0000 (10:23 -0700)]
ramips: ethernet: fix to interrupt handling
The current code acknowledged interrupts *after* polling.
This is the wrong way around, and could cause an interrupt to
be missed.
This is not likely to be fatal as another packet, and so another
interrupt, should come along soon. But maybe it is causing
problems, so let's fix it anyway.
Signed-off-by: NeilBrown <neil@brown.name>
(Note that this matches the upstream driver.) Signed-off-by: Rosen Penev <rosenp@gmail.com>
Hauke Mehrtens [Thu, 27 Aug 2020 10:09:58 +0000 (12:09 +0200)]
hostapd: Fix compile errors after wolfssl update
This fixes the following compile errors after the wolfssl 4.5.0 update:
LD wpa_cli
../src/crypto/tls_wolfssl.c: In function 'tls_match_alt_subject':
../src/crypto/tls_wolfssl.c:610:11: error: 'GEN_EMAIL' undeclared (first use in this function); did you mean 'ENAVAIL'?
type = GEN_EMAIL;
^~~~~~~~~
ENAVAIL
../src/crypto/tls_wolfssl.c:610:11: note: each undeclared identifier is reported only once for each function it appears in
../src/crypto/tls_wolfssl.c:613:11: error: 'GEN_DNS' undeclared (first use in this function)
type = GEN_DNS;
^~~~~~~
../src/crypto/tls_wolfssl.c:616:11: error: 'GEN_URI' undeclared (first use in this function)
type = GEN_URI;
^~~~~~~
../src/crypto/tls_wolfssl.c: In function 'wolfssl_tls_cert_event':
../src/crypto/tls_wolfssl.c:902:20: error: 'GEN_EMAIL' undeclared (first use in this function); did you mean 'ENAVAIL'?
if (gen->type != GEN_EMAIL &&
^~~~~~~~~
ENAVAIL
../src/crypto/tls_wolfssl.c:903:20: error: 'GEN_DNS' undeclared (first use in this function)
gen->type != GEN_DNS &&
^~~~~~~
../src/crypto/tls_wolfssl.c:904:20: error: 'GEN_URI' undeclared (first use in this function)
gen->type != GEN_URI)
^~~~~~~
Makefile:2029: recipe for target '../src/crypto/tls_wolfssl.o' failed
Fixes: 00722a720c77 ("wolfssl: Update to version 4.5.0") Reported-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit bc19481826e0da9119945eaae4f25736306f023b)
Hauke Mehrtens [Mon, 24 Aug 2020 10:11:29 +0000 (12:11 +0200)]
wolfssl: Update to version 4.5.0
This fixes the following security problems:
* In earlier versions of wolfSSL there exists a potential man in the
middle attack on TLS 1.3 clients.
* Denial of service attack on TLS 1.3 servers from repetitively sending
ChangeCipherSpecs messages. (CVE-2020-12457)
* Potential cache timing attacks on public key operations in builds that
are not using SP (single precision). (CVE-2020-15309)
* When using SGX with EC scalar multiplication the possibility of side-
channel attacks are present.
* Leak of private key in the case that PEM format private keys are
bundled in with PEM certificates into a single file.
* During the handshake, clear application_data messages in epoch 0 are
processed and returned to the application.
Full changelog:
https://www.wolfssl.com/docs/wolfssl-changelog/
Fix a build error on big endian systems by backporting a pull request:
https://github.com/wolfSSL/wolfssl/pull/3255
The size of the ipk increases on mips BE by 1.4%
old:
libwolfssl24_4.4.0-stable-2_mips_24kc.ipk: 386246
new:
libwolfssl24_4.5.0-stable-1_mips_24kc.ipk: 391528
Eneas U de Queiroz [Tue, 26 May 2020 13:45:22 +0000 (10:45 -0300)]
wolfssl: use -fomit-frame-pointer to fix asm error
32-bit x86 fail to compile fast-math feature when compiled with frame
pointer, which uses a register used in a couple of inline asm functions.
Previous versions of wolfssl had this by default. Keeping an extra
register available may increase performance, so it's being restored for
all architectures.
Eneas U de Queiroz [Fri, 1 May 2020 15:06:48 +0000 (12:06 -0300)]
wolfssl: update to 4.4.0-stable
This version adds many bugfixes, including a couple of security
vulnerabilities:
- For fast math (enabled by wpa_supplicant option), use a constant time
modular inverse when mapping to affine when operation involves a
private key - keygen, calc shared secret, sign.
- Change constant time and cache resistant ECC mulmod. Ensure points
being operated on change to make constant time.
Magnus Kroken [Tue, 1 Sep 2020 20:28:25 +0000 (22:28 +0200)]
mbedtls: update to 2.16.8
This release of Mbed TLS provides bug fixes and minor enhancements. This
release includes fixes for security issues and the most notable of them
are described in more detail in the security advisories.
* Local side channel attack on RSA and static Diffie-Hellman
* Local side channel attack on classical CBC decryption in (D)TLS
* When checking X.509 CRLs, a certificate was only considered as revoked
if its revocationDate was in the past according to the local clock if
available.
Full release announcement:
https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.8
Daniel Golle [Mon, 10 Aug 2020 22:33:00 +0000 (23:33 +0100)]
oxnas: reduce size of ATA DMA descriptor space
After years of trying to find the reason for random kernel crashes
while both CPU and SATA are under load it has been found.
Some odd commented-out #defines in kref's single-port driver [1] which
were copied from the vendor driver made me develop a theory:
The IO-mapped memory area for DMA descriptors apparetly got some holes
just before the alignment boundaries.
This feels like an off-by-one bug in the hardware or maybe those fields
are used internally by the SATA controller's firmware.
Whatever the cause is: they cannot be used and trying to use them
results in reading back unexpected stuff and ends up with oopsing
Unable to handle kernel paging request at virtual address d085c004
Work around the issue by reducing the area used for bmdma descriptors.
This reduces SATA performance (iops) quite a bit, but finally makes
things work reliably. Possibly one could optimize this much more by
really just skipping the holes in that memory area -- however, that
seems to be non-trivial with the driver and libata in it's current form
(suggestions are welcome).
The 'proper' way to have good SATA performance would be to make use of
the hardware RAID features (one can use the JBOD mode to access even
just a single disc transparently through the RAID controller integrated
in the SATA host instead of accessing the SATA ports 'raw' as we do
now).
Magnus Kroken [Sat, 25 Jul 2020 12:19:28 +0000 (14:19 +0200)]
mbedtls: update to 2.16.7
Mbed TLS 2.16.7 is a maintenance release of the Mbed TLS 2.16 branch,
and provides bug fixes and minor enhancements. This release includes
fixes for security issues and the most severe one is described in more
detail in a security advisory:
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-07
* Fix a side channel vulnerability in modular exponentiation that could
reveal an RSA private key used in a secure enclave.
* Fix side channel in mbedtls_ecp_check_pub_priv() and
mbedtls_pk_parse_key() / mbedtls_pk_parse_keyfile() (when loading a private
key that didn't include the uncompressed public key), as well as
mbedtls_ecp_mul() / mbedtls_ecp_mul_restartable() when called with a NULL
f_rng argument. An attacker with access to precise enough timing and
memory access information (typically an untrusted operating system
attacking a secure enclave) could fully recover the ECC private key.
* Fix issue in Lucky 13 counter-measure that could make it ineffective when
hardware accelerators were used (using one of the MBEDTLS_SHAxxx_ALT
macros).
Due to Mbed TLS moving from ARMmbed to the Trusted Firmware project, some
changes to the download URLs are required. For the time being, the
ARMmbed/mbedtls Github repository is the canonical source for Mbed TLS.
Signed-off-by: Magnus Kroken <mkroken@gmail.com>
[Use https://codeload.github.com and new tar.gz file] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 201d6776a0b5858b8ce43a2392c9fe48aa1c4dd7)
The only difference from the v1 is the TP-Link hardware ID/revision.
Attention:
The TL-WR710N v2.0 (!) has only 4 MB flash and cannot be flashed with
this image. It has a different TPLINK_HWREV, so accidental flashing
of the factory image should be impossible without additional measures.
Unfortunately, the v2.0 in ar71xx has the same board name, so sysupgrade
from ar71xx v2.0 into ath79 v1/v2.1 will not be prevented, but will brick
the device.
Flashing instruction:
Upload the factory image via the OEM firmware GUI upgrade mechanism.
Further notes:
To make implementation easier if somebody desires to port the 4M v2.0,
this already creates two DTSI files.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Tested-by: Fabian Eppig <fabian@eppig.de>
(backported from eb531337a779a48a2d17bc66f0d222325d6c1563)
Alexander Couzens [Mon, 3 Aug 2020 21:51:53 +0000 (23:51 +0200)]
tools/tplink-safeloader: use soft_ver 1.9.1 for archer c6 v2
TP-LINK published a firmware update for the archer c6 v2.
This updates also reached the factory devices. Newer software version
rejects downgrading to 1.2.x. Use 1.9.x to allow installing the factory images
and have a little bit time to change it again.
Georgi Vlaev [Fri, 27 Mar 2020 10:33:53 +0000 (12:33 +0200)]
tplink-safeloader: update soft_ver for TP-Link Archer C6 v2 (EU)
The last couple of TP-Link firmware releases for Archer C6 v2 (EU)
have switched to version 1.2.x. Bump the soft_ver to "1.2.1" to
allow firmware updates from the vendor web interface.
The source CDN has been discontinued in its current form and will take a
while to be reestablished. Even then it makes little sense to put a CDN
before other CDNs such as kernel.org, apache.org, sourceforge etc.
Adrian Schmutzler [Fri, 3 Jul 2020 15:21:12 +0000 (17:21 +0200)]
ath79: enable gpio on ar933x by default
All other SoC DTSI files have gpio enabled by default, only
ar9330/ar9331 disable it by default, only to have it enabled again
afterwards for each individual device.
So, do not disable it in the first place, and drop all device-specific
status statements afterwards.
Though this is a cosmetic commit, it might be a pitfall for
device-support backporters if missing. Since backporting it is trivial,
let's just do it.
Adrian Schmutzler [Fri, 14 Aug 2020 13:09:29 +0000 (15:09 +0200)]
ath79: ar724x: make sure builtin-switch is enabled in DT
On ar7240/ar7241 the mdioX node with the builtin-switch is enabled
in the DTSI files, but the parent ethX node is left disabled. It
only gets enabled per device or device family, and has not been
enabled at all yet for the TP-Link WA devices with ar7240, making
the switch unavailable there.
This patch makes sure ð0/ð1 nodes are enabled together with
the &mdio0/&mdio1 nodes containing the builtin-switch.
For ar7240_tplink_tl-wa.dtsi, ð0 is properly hidden again via
compatible = "syscon", "simple-mfd";
This partially fixes FS#2887, however it seems dmesg still does
not show cable (dis)connect in dmesg for ar7240 TP-Link WA
devices.
Michal Cieslakiewicz [Wed, 16 Oct 2019 10:39:51 +0000 (12:39 +0200)]
ath79: WNR612v2: improve device support
This patch improves ath79 support for Netgear WNR612v2.
Router functionality becomes identical to ar71xx version.
Changes include:
* software control over LAN LEDs via sysfs
* correct MAC addresses for network interfaces
* correct image size in device definition
* dts: 'keys' renamed to 'ath9k-keys'
* dts: 'label-mac-device' set to eth1 (LAN)
* dts: formatting adjustments
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
(cherry picked from commit d74324e407de7fb641310070762923f7e4cd2d6c)
[remove label-mac-device] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Michal Cieslakiewicz [Wed, 16 Oct 2019 10:38:43 +0000 (12:38 +0200)]
ath79: add LAN LEDs control bits for AR724x GPIO function pinmux
Currently AR724x pinmux for register 0x18040028 controls only JTAG disable bit.
This patch adds new DTS settings to control LAN LEDs and CLKs that allow
full software control over these diodes - exactly the same is done by ar71xx
target in device setup phase for many routers (WNR2000v3 for example).
'switch_led_disable_pins' clears AR724X_GPIO_FUNC_ETH_SWITCH_LED[0-4]_EN bits.
'clks_disable_pins' clears AR724X_GPIO_FUNC_CLK_OBS[1-5]_EN and
AR724X_GPIO_FUNC_GE0_MII_CLK_EN bits. These all should be used together, along
with 'jtag_disable_pins', to allow OS to control all GPIO-connected LEDs and
buttons on device.
Chih-Wei Chen [Wed, 16 Oct 2019 06:34:14 +0000 (14:34 +0800)]
ramips: fix Xiaomi MiWiFi Mini switch definition
Based on OpenWRT Table of Hardware > Xiaomi > Xiaomi Mi WiFi Mini
Switch Ports Defaults:
0, 1: LAN
4: WAN
6: CPU
Port in Web GUI (word printed on bottom of case)
WAN(Internet) map to switch port 4
LAN1(.) map to switch port 1
LAN2(..) map to switch port 0
CPU map to switch port 6
current setting is 1 WAN/ 4 LAN port, fix it.
Signed-off-by: Chih-Wei Chen <changeway@gmail.com>
[rebased after base-files split, fixed commit title] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(backported from commit 3e88ab79b03917bc4b03b34db12edf622bde1de1)
Signed-off-by: Magnus Kroken <mkroken@gmail.com>
[bump PKG_RELEASE] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 4165232c45df224f32a94f43b9938d13d643b2a8)
Hauke Mehrtens [Thu, 21 May 2020 19:49:21 +0000 (21:49 +0200)]
mac80211: Fix build on mpc85xx target
This fixes the following compile error seen on the mpc85xx target:
CC [M] /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o
In file included from /builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/stddef.h:17,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/uapi/linux/wireless.h:77,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/linux/wireless.h:13,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:89:
/builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/alltypes.h:106:15: error: conflicting types for 'ptrdiff_t'
typedef _Addr ptrdiff_t;
^~~~~~~~~
In file included from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/types.h:4,
from ./include/linux/list.h:5,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/list.h:3,
from ./include/linux/module.h:9,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/module.h:3,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:79:
./include/linux/types.h:65:28: note: previous declaration of 'ptrdiff_t' was here
typedef __kernel_ptrdiff_t ptrdiff_t;
^~~~~~~~~
scripts/Makefile.build:265: recipe for target '/linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o' failed
Fixes: d6b158b86981 ("mac80211: Update to 4.19.137-1") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 04b1a11f5ca72a741493addca1b1ae093f37934f)
projects / users / dwmw2 / openwrt.git / log