aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* armvirt64: enable qemu drm driversLucian Cristian2019-04-181-0/+4
| | | | | | | adds the qemu video drivers and also fixes the build failure introduced with drm-kms-helper Signed-off-by: Lucian Cristian <lucian.cristian@gmail.com>
* kernel: add missing drm symbolLucian Cristian2019-04-183-0/+3
| | | | | | dependency introduced with module drm-kms-helper Signed-off-by: Lucian Cristian <lucian.cristian@gmail.com>
* include: unpack.mk: remove CRLF_WORKAROUNDAlexandru Ardelean2019-04-181-7/+2
| | | | | | | | | | | | | This patch doesn't seem to have any more users. The only one used to be target in `target/linux/etrax/image/e100boot/Makefile`. That target has since been removed via commit 1080f68b2b422f1e72e402765a45d0cc3c550825 . There doesn't seem to be any reason left for this workaround. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
* mac80211: brcm: backport brcmfmac 5.2 patchesRafał Miłecki2019-04-1818-1/+1410
| | | | | | | This includes some USB fixes and early work on FullMAC firmware crash recovery. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* lantiq: tdw90x0: Fix WLAN LED on TP-Link W8970 v1.2 (FS#2232)Petr Štetiar2019-04-171-0/+1
| | | | | | | | | | This patch fixes disfunctional WLAN LED on TP-Link W8970. The LED was reported working in the CC release[1], but doesn't work anymore in 18.06.2. 1. https://github.com/openwrt/chaos_calmer/commit/420cb24d41fcd650795f09d2b26e0e1d2cf21165 Tested-by: Damian Janarek <dzanar18@o2.pl> Signed-off-by: Petr Štetiar <ynezz@true.cz>
* odhcpd: update to latest git HEAD (FS#2206)Hans Dedecker2019-04-171-3/+3
| | | | | | | | | | | | 38bc630 router: use ra_lifetime as lifetime for RA options (FS#2206) 0523bdd router: improve code readibility 0a3b279 Revert "router:" 207f8e0 treewide: align syslog loglevels f1d7da9 router: 0e048ac treewide: fix compiler warnings 83698f6 CMakeList.txt: enable extra compiler checks Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
* openssl: change defaults: ENGINE:on, NPN:off, miscEneas U de Queiroz2019-04-172-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. Enable engine support by default. Right now, some packages require this, so it is always enabled by the bots. Many packages will compile differently when engine support is detected, needing engine symbols from the libraries. However, being off by default, a user compiling its own image will fail to run some popular packages from the official repo. Note that disabling engines did not work in 1.0.2, so this problem never showed up before. NPN support has been removed in major browsers & servers, and has become a small bloat, so it does not make sense to leave it on by default. Remove deprecated CONFIG_ENGINE_CRYPTO symbol that is no longer needed. Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
* kernel: Fix kmod-drm-amdgpu and kmod-drm-radeon dependenciesLucian Cristian2019-04-161-7/+40
| | | | | | | | | | | | | | | | | | Currently the Geode builds fails on following kernel module missing dependencies: Package kmod-drm-amdgpu is missing dependencies for the following libraries: backlight.ko drm_kms_helper.ko fb.ko ttm.ko So this patch tries to fix the kmod-drm-amdgpu module dependecies. Fixes: 2f239c0 ("x86: video: add amdgpu DRM kernel package") Fixes: 2f6918e ("x86: video: add radeon DRM module support") Tested-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Signed-off-by: Lucian Cristian <lucian.cristian@gmail.com>
* procd/hotplug: add dependency to dialout and audio groupMartin Schiller2019-04-161-1/+2
| | | | | | | | | | | | | | | | Commit 6e060bd62c85 introduced a dependency to the dialout group. Adding this group to the "group" file in the base-files package is not enough to handle this dependency, because after a sysupgrade this entry will be missing in the "group" file. To address this problem the dependencies to the required groups needs to be set in the Makefile of the procd package. Then, the uci-default script "13_fix_group_user" will add the groups on first boot-up after a sysupgrade. Fixes: 6e060bd62c85 ("base-files/hotplug: fix dedicated group for tty devices") Tested-by: Michael Heimpold <mhei@heimpold.de> Signed-off-by: Martin Schiller <ms@dev.tdt.de>
* netifd: update to latest git HEADHans Dedecker2019-04-151-3/+3
| | | | | | | | 666c14f system-linux: remove debug tracing 08989e4 interface: add neighbor config support bfd4de3 interface: fix "if-down" hotplug event handling Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
* layerscape: unbreak ehci-fsl interaction with mpc85xxChristian Lamparter2019-04-152-23/+10
| | | | | | | | | | Both targets have their own idea of how to use ehci-fsl. This patch reverts part of commit 68b8d3b0796d ("kernel: usb: add FSL EHCI package") and moves ehci-fsl back into kmod-usb2, while also making it hopefully useable for the mpc85xx target. Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* mpc85xx: disable bricking TL-WDR4900v1 imagesChristian Lamparter2019-04-151-1/+1
| | | | | | | | | | | | | | | | | | The current mpc85xx build is failing because the TL-WDR4900v1 kernel image no longer fits into the partition. Extending the kernel is not possible without updating u-boot's kernel loader commands. This patch disables the WDR4900v1 until the kernel image size issue is fixed so the buildbot can still compile the Sophos RED 15w Rev.1 . Installing the WDR4900v1 images would cause the routers to get bricked. For the discussion, please go to: <https://github.com/openwrt/openwrt/pull/1773> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* kernel: MIPS: perf: ath79: Fix perfcount IRQ assignmentPetr Štetiar2019-04-152-0/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently it's not possible to use perf on ath79 due to genirq flags mismatch happening on static virtual IRQ 13 which is used for performance counters hardware IRQ 5. On TP-Link Archer C7v5: CPU0 2: 0 MIPS 2 ath9k 4: 318 MIPS 4 19000000.eth 7: 55034 MIPS 7 timer 8: 1236 MISC 3 ttyS0 12: 0 INTC 1 ehci_hcd:usb1 13: 0 gpio-ath79 2 keys 14: 0 gpio-ath79 5 keys 15: 31 AR724X PCI 1 ath10k_pci $ perf top genirq: Flags mismatch irq 13. 00014c83 (mips_perf_pmu) vs. 00002003 (keys) On TP-Link Archer C7v4: CPU0 4: 0 MIPS 4 19000000.eth 5: 7135 MIPS 5 1a000000.eth 7: 98379 MIPS 7 timer 8: 30 MISC 3 ttyS0 12: 90028 INTC 0 ath9k 13: 5520 INTC 1 ehci_hcd:usb1 14: 4623 INTC 2 ehci_hcd:usb2 15: 32844 AR724X PCI 1 ath10k_pci 16: 0 gpio-ath79 16 keys 23: 0 gpio-ath79 23 keys $ perf top genirq: Flags mismatch irq 13. 00014c80 (mips_perf_pmu) vs. 00000080 (ehci_hcd:usb1) This problem is happening, because currently statically assigned virtual IRQ 13 for performance counters is not claimed during the initialization of MIPS PMU during the bootup, so the IRQ subsystem doesn't know, that this interrupt isn't available for further use. So this patch fixes the issue by simply booking hardware IRQ 5 for MIPS PMU. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* umbim: update to latest git HEADPetr Štetiar2019-04-151-3/+3
| | | | | | | | | 24f9dc7 Iron out all extra compiler warnings 9d8dbc9 Enable extra compiler checks ff8d356 mbim-proxy support ccca03f umbim: add registration set support Signed-off-by: Petr Štetiar <ynezz@true.cz>
* Revert "ath79: Add WPS button to TP-Link Archer C7v5"Petr Štetiar2019-04-141-7/+0
| | | | | | | Reverting this commit as I've missed the fact, that the button is already present in the included DTSI file. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* mac80211: Fix rate_idx underflow in mwl8k (FS#2218)Petr Štetiar2019-04-142-1/+81
| | | | | | | Add a patch for mwl8k which fixes endless reboot loops on Linksys EA4500 with certain 5G configurations. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ramips: add support for Rakwireless RAK633Eike Feldmann2019-04-144-0/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's OEM module with 2*26 pin header, similar to LinkIt Smart 7688 or Vocore2. Specification: CPU: MT7628 580 MHz. MIPS 24K RAM: 64 MB Flash: 8 MB WIFI: 802.11n/g/b 20/40 MHz USB: 1x Port USB 2.0 Ethernet: 5 Port ethernet switch UART: 2x Installation: Use the installed uboot Bootloader. Connect a serial cable to serialport 0. Turn power on. Choose the option: "Load system code then write to Flash via TFTP". Choose the local device IP and the TFTP server IP and the file name of the system image. After if the Bootloader will copy the image to the local flash. Notes: The I2C Kernel module work not correctly. You can send and receive data. But the command i2cdetect doesn’t work. FS#845 Signed-off-by: Eike Feldmann <eike.feldmann@outlook.com> [commit subject and message touches, DTS whitespace fixes, wifi LED rename, pinctrl fixes, network settings fixes, lan/wmac mac addresses, removed i2c kernel modules] Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ramips: add support for GL.iNet VIXMINIDavid Bauer2019-04-133-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware -------- SoC: MediaTek MT7628NN RAM: 64M DDR2 (Etron EM68B16CWQD-25H) FLASH: 8M (Winbond W25Q64JVSIQ) LED: Power - WLAN BTN: Reset UART: 115200 8N1 TX and RX are labled on the board as pads next to the SoC Installation via web-interface ------------------------------ 1. Visit the web-interface at 192.168.8.1 Note: The ethernet port is by default WAN. So you need to connect to the router via WiFi 2. Navigate to the Update tab on the left side. 3. Select "Local Update" 4. Upload the OpenWrt sysupgrade image. Note: Make sure you select not to preserve the configuration. Installation via U-Boot ----------------------- 1. Hold down the reset button while powering on the device. Wait for the LED to flash 5 times. 2. Assign yourself a static IPv4 in 192.168.1.0/24 3. Upload the OpenWrt sysupgrade image at 192.168.1.1. Signed-off-by: David Bauer <mail@david-bauer.net>
* mpc85xx: generic: Check kernel size for the TL-WDR4900Pawel Dembicki2019-04-131-0/+1
| | | | | | | | | | | TP-Link TL-WDR 4900 have u-boot with read-only env. Boot command read only 0x29F000 data from flash. Bigger images causes crc error. It can't be changed. This patch add kernel size checking. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [utilize KERNEL_SIZE]
* mpc85xx: clean up device package selectionDavid Bauer2019-04-131-4/+2
| | | | | | | Remove wireless and USB packages from the device-specific package selection as they are already selected by the target itself. Signed-off-by: David Bauer <mail@david-bauer.net>
* mpc85xx: remove USB support from kernelDavid Bauer2019-04-133-15/+1
| | | | | | | | | | | | This removes USB support from the compiled kernel. Because of this, the kernel is just small enough for the TP-Link WDR4900 to boot the resulting kernel. This is necessary to support the WDR4900 in the upcoming 19.xx release. In the long run, this should be fixed with a second stage bootloader, as the vendor bootloader only loads the first 2684k bytes. Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: usb: add FSL EHCI packageDavid Bauer2019-04-131-2/+21
| | | | | | | Add kernel module package for the Freescale USB2 EHCI used on the mpc85xx platform. Signed-off-by: David Bauer <mail@david-bauer.net>
* ath79: remove unnecessary packages from I-O DATA ETG3-RINAGAKI Hiroshi2019-04-131-0/+1
| | | | | | | | I-O DATA ETG3-R is a wired router. So wireless-related packages are unnecessary and remove those packages from default configuration to reduce flash usage. Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* ath79: add TP-Link WR842N v3Sven Roederer2019-04-134-1/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the TP-Link WR842N v3 which is already supported on ar71xx target (0b45bec22c59cc6e6b2fa71dc9a88386c5587132). Specification: * SoC: QCA9533 ver 2 rev 0 * 16 MB Flash (gd25q128) * 64 MB RAM * 1 WAN 10/100 MBit/s (blue connector) * 4 LAN 10/100 MBit/s (AR8229; 4 ports; yellow connectors) * Atheros AR9531 (2,4GHz, two fixed antennas) * USB * Reset / WPS button * WiFi button (rf kill) * 8 green leds; 1 red/green led * serial console (115200 8N1, according to the OpenWrt-wiki some soldering is needed) Installation: * flash via vendor WebUI (the filename must not exceed certain length) * sysupgrade from installed OpenWrt (also ar71xx) Thanks to Holger Drefs for providing the hardware Tested-by: @kofec (github) Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
* mac80211: rt2x00: replace patch with upstream versionDaniel Golle2019-04-123-57/+96
| | | | | | | | Replace the patch introduced by commit d0b969eee8 ("mac80211: rt2x00: do not increment sequence number while re-transmitting") was merged into wireless-drivers.git. Replace our version with the merged version. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ramips: fix pinctrl to allow hardware i2c on WRTNODE2RDaniel Golle2019-04-111-1/+11
| | | | | | | | Instead of assigning I2C pins as GPIOs by default, leave it up to the user whether to install kmod-i2c-mt7621 and use them for hardware I2C instead. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: move and replace accepted patchDaniel Golle2019-04-111-12/+11
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-envtools: fix fw_env.config for ox820/stg-212Daniel Golle2019-04-111-1/+3
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* build: switch default target from ar71xx to ath79Kevin Darbyshire-Bryant2019-04-111-1/+1
| | | | | | | | | | | | | ar71xx is in the process of being deprecated as a target accepting new devices. The replacement target for the same hardware is DTS based ath79. Switch the default build target selection from ar71xx to ath79. This is intended to encourage DTS takeup & support for ath79 and longer term will also aid kernel upstream support. Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
* hostapd: fix CVE-2019-9497, CVE-2019-9498, CVE-2019-9499Stefan Lippers-Hollmann2019-04-115-1/+467
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EAP-pwd missing commit validation Published: April 10, 2019 Identifiers: - CVE-2019-9497 (EAP-pwd server not checking for reflection attack) - CVE-2019-9498 (EAP-pwd server missing commit validation for scalar/element) - CVE-2019-9499 (EAP-pwd peer missing commit validation for scalar/element) Latest version available from: https://w1.fi/security/2019-4/ Vulnerability EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP peer) was discovered not to validate the received scalar and element values in EAP-pwd-Commit messages properly. This could result in attacks that would be able to complete EAP-pwd authentication exchange without the attacker having to know the used password. A reflection attack is possible against the EAP-pwd server since the hostapd EAP server did not verify that the EAP-pwd-Commit contains scalar/element values that differ from the ones the server sent out itself. This allows the attacker to complete EAP-pwd authentication without knowing the password, but this does not result in the attacker being able to derive the session key (MSK), i.e., the attacker would not be able to complete the following key exchange (e.g., 4-way handshake in RSN/WPA). An attack using invalid scalar/element values is possible against both the EAP-pwd server and peer since hostapd and wpa_supplicant did not validate these values in the received EAP-pwd-Commit messages. If the used crypto library does not implement additional checks for the element (EC point), this could result in attacks where the attacker could use a specially crafted commit message values to manipulate the exchange to result in deriving a session key value from a very small set of possible values. This could further be used to attack the EAP-pwd server in a practical manner. An attack against the EAP-pwd peer is slightly more complex, but still consider practical. These invalid scalar/element attacks could result in the attacker being able to complete authentication and learn the session key and MSK to allow the key exchange to be completed as well, i.e., the attacker gaining access to the network in case of the attack against the EAP server or the attacker being able to operate a rogue AP in case of the attack against the EAP peer. While similar attacks might be applicable against SAE, it should be noted that the SAE implementation in hostapd and wpa_supplicant does have the validation steps that were missing from the EAP-pwd implementation and as such, these attacks do not apply to the current SAE implementation. Old versions of wpa_supplicant/hostapd did not include the reflection attack check in the SAE implementation, though, since that was added in June 2015 for v2.5 (commit 6a58444d27fd 'SAE: Verify that own/peer commit-scalar and COMMIT-ELEMENT are different'). Vulnerable versions/configurations All hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled in the runtime configuration) are vulnerable against the reflection attack. All wpa_supplicant and hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled in the runtime configuration) are vulnerable against the invalid scalar/element attack when built against a crypto library that does not have an explicit validation step on imported EC points. The following list indicates which cases are vulnerable/not vulnerable: - OpenSSL v1.0.2 or older: vulnerable - OpenSSL v1.1.0 or newer: not vulnerable - BoringSSL with commit 38feb990a183 ('Require that EC points are on the curve.') from September 2015: not vulnerable - BoringSSL without commit 38feb990a183: vulnerable - LibreSSL: vulnerable - wolfssl: vulnerable Acknowledgments Thanks to Mathy Vanhoef (New York University Abu Dhabi) for discovering and reporting the issues and for proposing changes to address them in the implementation. Possible mitigation steps - Merge the following commits to wpa_supplicant/hostapd and rebuild: CVE-2019-9497: EAP-pwd server: Detect reflection attacks CVE-2019-9498: EAP-pwd server: Verify received scalar and element EAP-pwd: Check element x,y coordinates explicitly CVE-2019-9499: EAP-pwd client: Verify received scalar and element EAP-pwd: Check element x,y coordinates explicitly These patches are available from https://w1.fi/security/2019-4/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* hostapd: fix CVE-2019-9496Stefan Lippers-Hollmann2019-04-112-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hostapd: fix SAE confirm missing state validation Published: April 10, 2019 Identifiers: - CVE-2019-9496 (SAE confirm missing state validation in hostapd/AP) Latest version available from: https://w1.fi/security/2019-3/ Vulnerability When hostapd is used to operate an access point with SAE (Simultaneous Authentication of Equals; also known as WPA3-Personal), an invalid authentication sequence could result in the hostapd process terminating due to a NULL pointer dereference when processing SAE confirm message. This was caused by missing state validation steps when processing the SAE confirm message in hostapd/AP mode. Similar cases against the wpa_supplicant SAE station implementation had already been tested by the hwsim test cases, but those sequences did not trigger this specific code path in AP mode which is why the issue was not discovered earlier. An attacker in radio range of an access point using hostapd in SAE configuration could use this issue to perform a denial of service attack by forcing the hostapd process to terminate. Vulnerable versions/configurations All hostapd versions with SAE support (CONFIG_SAE=y in the build configuration and SAE being enabled in the runtime configuration). Possible mitigation steps - Merge the following commit to hostapd and rebuild: SAE: Fix confirm message validation in error cases These patches are available from https://w1.fi/security/2019-3/ - Update to hostapd v2.8 or newer, once available Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* hostapd: fix CVE-2019-9495Stefan Lippers-Hollmann2019-04-112-1/+320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EAP-pwd side-channel attack Published: April 10, 2019 Identifiers: - CVE-2019-9495 (cache attack against EAP-pwd) Latest version available from: https://w1.fi/security/2019-2/ Vulnerability Number of potential side channel attacks were recently discovered in the SAE implementations used by both hostapd and wpa_supplicant (see security advisory 2019-1 and VU#871675). EAP-pwd uses a similar design for deriving PWE from the password and while a specific attack against EAP-pwd is not yet known to be tested, there is no reason to believe that the EAP-pwd implementation would be immune against the type of cache attack that was identified for the SAE implementation. Since the EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP peer) does not support MODP groups, the timing attack described against SAE is not applicable for the EAP-pwd implementation. A novel cache-based attack against SAE handshake would likely be applicable against the EAP-pwd implementation. Even though the wpa_supplicant/hostapd PWE derivation iteration for EAP-pwd has protections against timing attacks, this new cache-based attack might enable an attacker to determine which code branch is taken in the iteration if the attacker is able to run unprivileged code on the victim machine (e.g., an app installed on a smart phone or potentially a JavaScript code on a web site loaded by a web browser). This depends on the used CPU not providing sufficient protection to prevent unprivileged applications from observing memory access patterns through the shared cache (which is the most likely case with today's designs). The attacker could use information about the selected branch to learn information about the password and combine this information from number of handshake instances with an offline dictionary attack. With sufficient number of handshakes and sufficiently weak password, this might result in full recovery of the used password if that password is not strong enough to protect against dictionary attacks. This attack requires the attacker to be able to run a program on the target device. This is not commonly the case on an authentication server (EAP server), so the most likely target for this would be a client device using EAP-pwd. The commits listed in the end of this advisory change the EAP-pwd implementation shared by hostapd and wpa_supplicant to perform the PWE derivation loop using operations that use constant time and memory access pattern to minimize the externally observable differences from operations that depend on the password even for the case where the attacker might be able to run unprivileged code on the same device. Vulnerable versions/configurations All wpa_supplicant and hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled in the runtime configuration). It should also be noted that older versions of wpa_supplicant/hostapd prior to v2.7 did not include additional protection against certain timing differences. The definition of the EAP-pwd (RFC 5931) does not describe such protection, but the same issue that was addressed in SAE earlier can be applicable against EAP-pwd as well and as such, that implementation specific extra protection (commit 22ac3dfebf7b, "EAP-pwd: Mask timing of PWE derivation") is needed to avoid showing externally visible timing differences that could leak information about the password. Any uses of older wpa_supplicant/hostapd versions with EAP-pwd are recommended to update to v2.7 or newer in addition to the mitigation steps listed below for the more recently discovered issue. Possible mitigation steps - Merge the following commits to wpa_supplicant/hostapd and rebuild: OpenSSL: Use constant time operations for private bignums Add helper functions for constant time operations OpenSSL: Use constant time selection for crypto_bignum_legendre() EAP-pwd: Use constant time and memory access for finding the PWE These patches are available from https://w1.fi/security/2019-2/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available - Use strong passwords to prevent dictionary attacks Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* hostapd: fix CVE-2019-9494Stefan Lippers-Hollmann2019-04-119-1/+1083
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SAE side-channel attacks Published: April 10, 2019 Identifiers: - VU#871675 - CVE-2019-9494 (cache attack against SAE) Latest version available from: https://w1.fi/security/2019-1/ Vulnerability Number of potential side channel attacks were discovered in the SAE implementations used by both hostapd (AP) and wpa_supplicant (infrastructure BSS station/mesh station). SAE (Simultaneous Authentication of Equals) is also known as WPA3-Personal. The discovered side channel attacks may be able to leak information about the used password based on observable timing differences and cache access patterns. This might result in full password recovery when combined with an offline dictionary attack and if the password is not strong enough to protect against dictionary attacks. Cache attack A novel cache-based attack against SAE handshake was discovered. This attack targets SAE with ECC groups. ECC group 19 being the mandatory group to support and the most likely used group for SAE today, so this attack applies to the most common SAE use case. Even though the PWE derivation iteration in SAE has protections against timing attacks, this new cache-based attack enables an attacker to determine which code branch is taken in the iteration if the attacker is able to run unprivileged code on the victim machine (e.g., an app installed on a smart phone or potentially a JavaScript code on a web site loaded by a web browser). This depends on the used CPU not providing sufficient protection to prevent unprivileged applications from observing memory access patterns through the shared cache (which is the most likely case with today's designs). The attacker can use information about the selected branch to learn information about the password and combine this information from number of handshake instances with an offline dictionary attack. With sufficient number of handshakes and sufficiently weak password, this might result in full discovery of the used password. This attack requires the attacker to be able to run a program on the target device. This is not commonly the case on access points, so the most likely target for this would be a client device using SAE in an infrastructure BSS or mesh BSS. The commits listed in the end of this advisory change the SAE implementation shared by hostapd and wpa_supplicant to perform the PWE derivation loop using operations that use constant time and memory access pattern to minimize the externally observable differences from operations that depend on the password even for the case where the attacker might be able to run unprivileged code on the same device. Timing attack The timing attack applies to the MODP groups 22, 23, and 24 where the PWE generation algorithm defined for SAE can have sufficient timing differences for an attacker to be able to determine how many rounds were needed to find the PWE based on the used password and MAC addresses. When the attack is repeated with multiple times, the attacker may be able to gather enough information about the password to be able to recover it fully using an offline dictionary attack if the password is not strong enough to protect against dictionary attacks. This attack could be performed by an attacker in radio range of an access point or a station enabling the specific MODP groups. This timing attack requires the applicable MODP groups to be enabled explicitly in hostapd/wpa_supplicant configuration (sae_groups parameter). All versions of hostapd/wpa_supplicant have disabled these groups by default. While this security advisory lists couple of commits introducing additional protection for MODP groups in SAE, it should be noted that the groups 22, 23, and 24 are not considered strong enough to meet the current expectation for a secure system. As such, their use is discouraged even if the additional protection mechanisms in the implementation are included. Vulnerable versions/configurations All wpa_supplicant and hostapd versions with SAE support (CONFIG_SAE=y in the build configuration and SAE being enabled in the runtime configuration). Acknowledgments Thanks to Mathy Vanhoef (New York University Abu Dhabi) and Eyal Ronen (Tel Aviv University) for discovering the issues and for discussions on how to address them. Possible mitigation steps - Merge the following commits to wpa_supplicant/hostapd and rebuild: OpenSSL: Use constant time operations for private bignums Add helper functions for constant time operations OpenSSL: Use constant time selection for crypto_bignum_legendre() SAE: Minimize timing differences in PWE derivation SAE: Avoid branches in is_quadratic_residue_blind() SAE: Mask timing of MODP groups 22, 23, 24 SAE: Use const_time selection for PWE in FFC SAE: Use constant time operations in sae_test_pwd_seed_ffc() These patches are available from https://w1.fi/security/2019-1/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available - In addition to either of the above alternatives, disable MODP groups 1, 2, 5, 22, 23, and 24 by removing them from hostapd/wpa_supplicant sae_groups runtime configuration parameter, if they were explicitly enabled since those groups are not considered strong enough to meet current security expectations. The groups 22, 23, and 24 are related to the discovered side channel (timing) attack. The other groups in the list are consider too weak to provide sufficient security. Note that all these groups have been disabled by default in all hostapd/wpa_supplicant versions and these would be used only if explicitly enabled in the configuration. - Use strong passwords to prevent dictionary attacks Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* procd: update to latest git HEADHans Dedecker2019-04-101-3/+3
| | | | | | baaf38c procd: instance: Support deleting stopped instances Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
* wireguard: remove obvious commentsFlorian Eckert2019-04-091-9/+0
| | | | | | Remove obvious comments to save disk space. Signed-off-by: Florian Eckert <fe@dev.tdt.de>
* wireguard: converted whitespaces from space to tabFlorian Eckert2019-04-091-176/+169
| | | | | | | | | With this change, the file is reduced from 5186 bytes to 4649 bytes that its approximately 10.5 percent less memory consumption. For small devices, sometimes every byte counts. Also, all other protocol handler use tabs instead of spaces. Signed-off-by: Florian Eckert <fe@dev.tdt.de>
* ethtool: bump to 5.0Hans Dedecker2019-04-091-2/+2
| | | | | | | | | | | | | | | | | 170d821 Release version 5.0. 909f8c0 Revert "ethtool: change to new sane powerpc64 kernel headers" a484274 ethtool: dsa: mv88e6xxx: add pretty dump for others 034a17b ethtool: dsa: mv88e6xxx: add pretty dump for 88E6390 7f1cc44 ethtool: dsa: mv88e6xxx: add pretty dump for 88E6352 a13a053 ethtool: dsa: mv88e6xxx: add pretty dump for 88E6161 4e98029 ethtool: dsa: mv88e6xxx: add pretty dump for 88E6185 ff99e46 ethtool: dsa: mv88e6xxx: add pretty dump cb8e980 ethtool: dsa: add pretty dump 4df55c8 ethtool: change to new sane powerpc64 kernel headers 0cb963e ethtool: zero initialize coalesce struct 8f05538 ethtool: don't report UFO on kernels v4.14 and above Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
* imx6: bump sdma firmware to 3.4Koen Vandeputte2019-04-091-0/+0
| | | | Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ath79: add support for Netgear EX6400 and EX7300Daniel Gimpelevich2019-04-098-0/+282
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is sold as a dual-band 802.11ac range extender. It has a sliding switch for Extender mode or Access Point mode, a WPS button, a recessed Reset button, a hard-power button, and a multitude of LED's, some multiplexed via an NXP 74AHC164D chip. The internal serial header pinout is Vcc, Tx, Rx, GND, with GND closest to the corner of the board. You may connect at 115200 bps, 8 data bits, no parity, 1 stop bit. Specification: - System-On-Chip: QCA9558 - CPU/Speed: 720 MHz - Flash-Chip: Winbond 25Q128FVSG - Flash size: 16 MiB - RAM: 128 MiB - Wireless No1: QCA9558 on-chip 2.4GHz 802.11bgn, 3x3 - Wireless No2: QCA99x0 chip 5GHz 802.11an+ac, 4x4 - PHY: Atheros AR8035-A Installation: If you can get to the stock firmware's firmware upgrade option, just feed it the factory.img and boot as usual. As an alternative, TFTP the factory.img to the bootloader. Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> [whitespace fix in DTS and reorder of make variables] Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ath79: remove more duplicate image build variablesDaniel Gimpelevich2019-04-093-22/+18
| | | | | | | | | Remove Netgear-specific image build variables which are set to the same value. Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> [reordering of variables, removed stray newline] Signed-off-by: Petr Štetiar <ynezz@true.cz>
* sunxi: Remove already applied patchHauke Mehrtens2019-04-081-214/+0
| | | | | | | This patch is already included in kernel v4.19.31. Fixes: 8df12d76c642 ("kernel: bump 4.19 to 4.19.34") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* scripts/qemustart: Allow specifying custom rootfs for maltaPetr Štetiar2019-04-081-0/+11
| | | | | | | | Currently it's not possible to test boot squashfs root images, so this patch now allows this use case as well. Cc: Yousong Zhou <yszhou4tech@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz>
* scripts/qemustart: Allow specifying custom kernel for x86Petr Štetiar2019-04-081-1/+9
| | | | | | | | Currently it's not possible to test boot squashfs root images, so this patch now allows this use case as well. Cc: Yousong Zhou <yszhou4tech@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz>
* scripts/qemustart: Allow usage without networkingPetr Štetiar2019-04-081-10/+31
| | | | | | | | | | | For basic tests it's not necessary to have the networking setup and this allows testing as a normal user as well, without root privileges. So this patch adds `--no-network` long option or `-n` short option, which allows starting QEMU without network. Cc: Yousong Zhou <yszhou4tech@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ar71xx: Correct MAC address for WAN interface of Archer C7 v5Adrian Schmutzler2019-04-081-0/+4
| | | | | | | | | | | This device shares the network config with v4, thus the WAN MAC also needs to be fixed the same way. However, the partition where the MAC address resides has been changed. Based on: https://github.com/openwrt/openwrt/pull/1726 Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ar71xx: Add "info" partition for TP-Link Archer C7 v5Adrian Schmutzler2019-04-081-1/+1
| | | | | | | | | | | | | | This adds the "info" MTD partition, as it is specified in the ath79 DTS: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/qca9563_tplink_archer-c7-v5.dts#L35 This is required to set the WAN MAC address, as it is build based on the LAN MAC address, which in turn has to be read from the "info" partition: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/qca9563_tplink_archer-c7-v5.dts#L35 Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: Add WPS button to TP-Link Archer C7v5Petr Štetiar2019-04-081-0/+7
| | | | | | | This patch adds currently missing support for the WPS button on TP-Link Archer C7v5. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* ath79: Correct MAC address for WAN interface of Archer A7/C7 v5Adrian Schmutzler2019-04-081-0/+5
| | | | | | | | | | | These devices share the network config with C7v4, thus the WAN MAC also needs to be fixed the same way. However, the partition where the MAC address resides has been changed. Based on: https://github.com/openwrt/openwrt/pull/1726 Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: Fix GPIO reset button on TP-Link Archer C7v5Adrian Schmutzler2019-04-083-7/+18
| | | | | | | | | | | | | The GPIO for the reset button for the Archer C7v5 changed from ar71xx to ath79. An investigation based on tests revealed that the A7v5 responds on "11", while the C7v5 responds on "5" as set for ar71xx. Thus, we just define this in the DTS files instead of in the common DTSI. Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: Utilize new LED modes from diag.sh for Archer A7/C7 v5Adrian Schmutzler2019-04-081-1/+4
| | | | | Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-06 21:06:24 +0000