The control device /dev/cdc-wdm0 is not available immediately on the
D-Link DWR-921 Rev.C3, therefore the wwan interface fails to start at
boot with a "The specified control device does not exist" error.
This patch alters /lib/netifd/proto/qmi.sh to wait for
network.wwan.delay earlier, before checking for the control device,
instead of just before interacting with the modem.
One still has to use network.wwan.proto='qmi', as the "wwan" proto
performs that sort of check before any delay is possible, failing with a
"No valid device was found" error.
Signed-off-by: Thomas Equeter <tequeter@users.noreply.github.com>
Some combination of modem/wireless operator requires more time to
execute the commands.
Tested on DWR-512 embedded wwan modem and italian operator iliad (new
virtual operator).
Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com>
(cherry picked from commit 774d7fc9f2)
This is necessary to get my position right.
Without this my longitude is incorrecty -15.85xxxx instead of -16.52yyyy
Signed-off-by: Bruno Randolf <br1@einfach.org>
(cherry picked from commit fe960cead7)
Netgear WNR612v2 flashed with recent OpenWrt builds suffers from kernel
panic at boot during wireless chip initialization, making device
unusable:
ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
ath: phy0: Enable LNA combining
CPU 0 Unable to handle kernel paging request at virtual address 1000fee1, epc == 801d08f0, ra == 801d0d90
Oops[#1]:
CPU: 0 PID: 469 Comm: kmodloader Not tainted 4.9.120 #0
[ ... register dump etc ... ]
Kernel panic - not syncing: Fatal exception
Rebooting in 1 seconds..
This simple patch fixes above error. It keeps LED table in memory after
kernel init phase for ath9k driver to operate correctly (__initdata
removed).
Also, another bug is fixed - correct array size is provided to function
that adds platform LEDs (this device has only 1 connected to Wifi chip)
preventing code from going outside array bounds.
Fixes: 1f5ea4eae4 ("ar71xx: add correct named default wireless led by using platform leds")
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
[trimmed commit message]
Signed-off-by: Mathias Kresin <dev@kresin.me>
The NBG6616 shares a config symbol with the NBG6716. It was accidentally
removed from the config when the ar71xx-tiny target was split off.
Fixes: 0cd5e85e7a ("ar71xx: create new ar71xx/tiny subtarget for 4MB flash devices")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
(cherry picked from commit a4f4ddba61)
7daf962 mt7603: add survey support
980c606 mt7603: add fix for CCA signal configuration
30b8371 mt7603: fix BAR rate
Signed-off-by: Felix Fietkau <nbd@nbd.name>
CVE description :
The recv_msg_userauth_request function in svr-auth.c in Dropbear through
2018.76 is prone to a user enumeration vulnerability because username
validity affects how fields in SSH_MSG_USERAUTH messages are handled,
a similar issue to CVE-2018-15473 in an unrelated codebase.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
The device was not included in the /etc/board.d/02_network file, so
the network wouldn't be properly set up on boot.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
The former used compatibles aren't defined anywhere and aren't used by
the devicetree source files including them.
Signed-off-by: Mathias Kresin <dev@kresin.me>
According to abbfcc8525 ("ramips: add support for GL-inet
GL-MT300N-V2") the board has a MediaTek MT7628AN. Change the SoC
compatible to match the used hardware.
Signed-off-by: Mathias Kresin <dev@kresin.me>
RT5350 neither have rgmii nor a mdio pinmux group. MT7628an doesn't
have a jtag group. Having these groups defined might cause a boot
panic.
The pin controller fails to initialise for kernels > 4.9 if invalid
groups are used. If a subsystem references a pin controller
configuration node, it can not find this node and errors out. In worst
case it's the SPI driver which errors out and we have no root
filesystem to mount.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The intention of 967b6be118 ("ar8327: Add workarounds for AR8337
switch") was to remove the register fixups for AR8337. But instead they
were removed for AR8327.
The RGMII RX delay is forced even if the port is used as phy instead of
mac, which results in no package flow at least for one board.
Fixes: FS#1664
Signed-off-by: Mathias Kresin <dev@kresin.me>
Update bison to 3.0.5
Bugfix release
Remove 001-fix-macos-vasnprintf.patch as it is fixed upstream
Signed-off-by: Daniel Engberg <daniel.engberg.lists@pyret.net>
(cherry picked from commit df02e7a3c7)
Since kernel 4.10 commit 61e84623ace3 ("net: centralize net_device
min/max MTU checking"), the range of mtu is [min_mtu, max_mtu], which
is [68, 1500] by default.
It's necessary to set a max_mtu if a mtu > 1500 is supported.
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Mathias Kresin <dev@kresin.me>
This fixes the following security problems:
* CVE-2018-0732: Client DoS due to large DH parameter
* CVE-2018-0737: Cache timing vulnerability in RSA Key Generation
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The following patch was integrated upstream:
* target/linux/generic/backport-4.9/500-ext4-fix-check-to-prevent-initializing-reserved-inod.patch
This fixes tries to work around the following security problems:
* CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
* CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The following patches were integrated upstream:
* target/linux/ipq40xx/patches-4.14/050-0006-mtd-nand-qcom-Add-a-NULL-check-for-devm_kasprintf.patch
* target/linux/mediatek/patches-4.14/0177-phy-phy-mtk-tphy-use-auto-instead-of-force-to-bypass.patch
This fixes tries to work around the following security problems:
* CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
* CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In "brcm47xx: rework model detection" the file 01_detect was moved
to 01_network, therefore also update the warning message in case
everything fails.
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
The flash size of the ubnt2 and ubnt5 is limited and the images with
LuCI are getting too big for these boards. Do not build images for these
boards to make the complete build of this target not fail anymore.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The kernel image of the at91-q5xr5 is getting too bing now and this is
breaking the build. Remove the image for the at91-q5xr5 from the build
to at least build images for the other devices.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add a temporary workaround to compile with glibc 2.28
as some constants were removed and others made private
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
Add a temporary workaround to compile with glibc 2.28
as some constants were removed and others made private
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
Unauthenticated EAPOL-Key decryption in wpa_supplicant
Published: August 8, 2018
Identifiers:
- CVE-2018-14526
Latest version available from: https://w1.fi/security/2018-1/
Vulnerability
A vulnerability was found in how wpa_supplicant processes EAPOL-Key
frames. It is possible for an attacker to modify the frame in a way that
makes wpa_supplicant decrypt the Key Data field without requiring a
valid MIC value in the frame, i.e., without the frame being
authenticated. This has a potential issue in the case where WPA2/RSN
style of EAPOL-Key construction is used with TKIP negotiated as the
pairwise cipher. It should be noted that WPA2 is not supposed to be used
with TKIP as the pairwise cipher. Instead, CCMP is expected to be used
and with that pairwise cipher, this vulnerability is not applicable in
practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data
field is encrypted using RC4. This vulnerability allows unauthenticated
EAPOL-Key frames to be processed and due to the RC4 design, this makes
it possible for an attacker to modify the plaintext version of the Key
Data field with bitwise XOR operations without knowing the contents.
This can be used to cause a denial of service attack by modifying
GTK/IGTK on the station (without the attacker learning any of the keys)
which would prevent the station from accepting received group-addressed
frames. Furthermore, this might be abused by making wpa_supplicant act
as a decryption oracle to try to recover some of the Key Data payload
(GTK/IGTK) to get knowledge of the group encryption keys.
Full recovery of the group encryption keys requires multiple attempts
(128 connection attempts per octet) and each attempt results in
disconnection due to a failure to complete the 4-way handshake. These
failures can result in the AP/network getting disabled temporarily or
even permanently (requiring user action to re-enable) which may make it
impractical to perform the attack to recover the keys before the AP has
already changes the group keys. By default, wpa_supplicant is enforcing
at minimum a ten second wait time between each failed connection
attempt, i.e., over 20 minutes waiting to recover each octet while
hostapd AP implementation uses 10 minute default for GTK rekeying when
using TKIP. With such timing behavior, practical attack would need large
number of impacted stations to be trying to connect to the same AP to be
able to recover sufficient information from the GTK to be able to
determine the key before it gets changed.
Vulnerable versions/configurations
All wpa_supplicant versions.
Acknowledgments
Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU
Leuven for discovering and reporting this issue.
Possible mitigation steps
- Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This
can be done also on the AP side.
- Merge the following commits to wpa_supplicant and rebuild:
WPA: Ignore unauthenticated encrypted EAPOL-Key data
This patch is available from https://w1.fi/security/2018-1/
- Update to wpa_supplicant v2.7 or newer, once available
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit 1961948585)
They're already in linux.git, so they shouldn't be in pending.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit 14b6c72541)
The previous round of fixes for the 82574 chip cause an issue with
emulated e1000e devices in VMware ESXi 6.5. It also contains changes
that are not strictly necessary. These patches fix the issues introduced
in the previous series, revert the unnecessary changes to avoid
unforeseen fallout, and avoid a case where interrupts can be missed.
The final two patches of this series are already in the kernel, so no
need to include them here.
Patchwork: https://patchwork.ozlabs.org/cover/881776/
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit ef025e6417)
This backports a fix for:
* CVE-2018-0500 SMTP send heap buffer overflow
See here for details: https://curl.haxx.se/docs/adv_2018-70a2.html
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Multiple security fixes
* CVE-2018-0497 Remote plaintext recovery on use of CBC based ciphersuites through a timing side-channel
* CVE-2018-0498 Plaintext recovery on use of CBC based ciphersuites through a cache based side-channel
Disable OFB block mode and XTS block cipher mode, added in 2.11.0.
Disable Chacha20 and Poly1305 cryptographic primitives, added in 2.12.0
Patch the so version back to the original one, the API changes are
looking no so invasive.
The size of mbedtls increased a little bit:
ipkg for mips_24kc before:
163.967 Bytes
ipkg for mips_24kc after:
164.753 Bytes
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This make sit possible to store informations about a session and reuse
it later. When used by a server it increases the time to create a new
TLS session from about 1 second to less than 0.1 seconds.
The size of the ipkg file increased by about 800 Bytes.
ipkg for mips_24kc before:
163.140 Bytes
ipkg for mips_24kc after:
163.967 Bytes
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This makes mbedtls use the POSIX API directly and not use the own
abstraction layer.
The size of the ipkg decreased by about 100 bytes.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The 4.4 version hash was accidentally reintroduced while rebasing the
master commit, remove it again.
Fixes ca3174e4e9 ("kernel: bump 4.9 to 4.9.118")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
