OpenWrt 19.07.5 service release
Hi, The OpenWrt community is proud to announce the fifth service release of OpenWrt 19.07. It focuses on fixing several regression as well as security issues. Main changes from OpenWrt 19.07.4 Security fixes * Security Advisory 2020-12-09-2 - libuci import heap use after free (CVE-2020-28951) * Security Advisory 2020-12-09-1 - Linux kernel - ICMP rate limiting can be used to facilitate DNS poisoning attack (CVE-2020-25705) * musl: fix possible destination buffer overflow in some applications (CVE-2020-28928) Note: security fixes for most packages can also be applied by upgrading only the affected packages on running devices, without the need for a full firmware upgrade. This can be done with opkg update; opkg upgrade the_package_name or through the LuCI web interface. Nevertheless, we encourage all users to upgrade their devices to OpenWrt 19.07.5 or later versions whenever possible. Major bug fixes * Fix regression in 19.07.4 causing transmit timeout and packet loss on mt7620 devices: FS#3332 * Fix regression in 19.07.4 where VLAN tagging no longer works on ipq40xx devices: FS#3239 * Fix long-standing instability issue on Ethernet link on several ath79 devices: FS#2216, FS#2730, FS#3225 Device support * Various fixes for My Net Range Extender, PowerCloud Systems CAP324, D-Link DIR-645, Quad-E4G * Support newer version of Turris Omnia * Fix ath9k firmware extraction for UniFi AP * Fix MAC address assignment on UniFi AC family (UniFi AC Mesh, UniFi AC LR, UniFi Lite) * Allow booting espressobin with a mainline firmware Various fixes and improvements * Fix support for 3G USB modems * uhttpd: fix spurious keepalive connection timeouts * firewall: fix parsing of boolean attributes * mac80211: do not allow bigger VHT MPDUs than the hardware supports LuCI web interface * Set the fallback default of rollback timeout to 90s * luci-app-firewall: fix removing networks from zone (GH#4523, GH#4573) * rpcd-mod-luci: handle lease files from all dnsmasq/odhcpd sections (GH#911, GH#4303, GH#4308) * luci-app-firewall: rules: add ICMPv6 Packet Too Big (Type 2) * Update translations from weblate Core components * Update Linux kernel from 4.14.195 to 4.14.209 * Update intel-microcode from 20190918 to 20200616 * Update amd-microcode from 20180524 to 20191218 Full release notes and upgrade instructions are available at https://openwrt.org/releases/19.07/notes-19.07.5 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/19.07/notes-19.07.5#regressions For a very detailed list of all changes since 19.07.4, refer to https://openwrt.org/releases/19.07/changelog-19.07.5 - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact - --- For latest information about the 19.07 series, refer to the wiki at: https://openwrt.org/releases/19.07/ To download a OpenWrt 19.07.5 firmware image for your device, head to the Table of Hardware: https://openwrt.org/toh/start Or navigate directly in the list of firmware images: https://downloads.openwrt.org/releases/19.07.5/targets/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 18.06.9 final service release
Hi, The OpenWrt Community is proud to announce the ninth service release of the stable OpenWrt 18.06 series. OpenWrt 18.06.9 brings security fixes, as well as the usual device support fixes and core components update. End of support for OpenWrt 18.06 This release is the final one for OpenWrt 18.06. You should consider upgrading to a newer version (OpenWrt 19.07 or later) - The main highlights of this service release are: Security fixes * Security Advisory 2020-12-09-2 - libuci import heap use after free (CVE-2020-28951) * Security Advisory 2020-12-09-1 - Linux kernel - ICMP rate limiting can be used to facilitate DNS poisoning attack (CVE-2020-25705) * Security Advisory 2020-05-06-2 - relayd out-of-bounds reads of heap data and possible buffer overflow (CVE-2020-11752) * Security Advisory 2020-05-06-1 - umdns out-of-bounds reads of heap data and possible buffer overflow (CVE-2020-11750) * libjson-c: fix out of bounds write vulnerability (CVE-2020-12762) * mac80211: backport some fixes for the Kr00k vulnerability in WPA. It is not clear which wireless driver/firmware combinations could be vulnerable in OpenWrt. These backported patches harden mac80211 just in case. Note: security fixes for most packages can also be applied by upgrading only the affected packages on running devices, without the need for a full firmware upgrade. This can be done with opkg update; opkg upgrade the_package_name or through the LuCI web interface. Nevertheless, we encourage all users to upgrade their devices to OpenWrt 18.06.9 or a newer major release whenever possible. Bug fixes * libubox: Fix regression that could cause procd to fail to start or restart some services. This is especially visible as it broke LuCI when upgrading from older 18.06.X releases (FS#3177) * musl: fix locking synchronization bug * kernel: backport out-of-memory fix for non-Ethernet devices * firewall: fix TCP MSS clamping that was only applied on one direction (FS#3231) Device support * brcm63xx: fix BCM6348/BCM6358 hangs while booting (FS#2202) * ipq40xx: fix essedma MAC hang by disabling TCP segmentation offload for IPv6 * ramips: fix USB detection on all rt305x devices * mikrotik: add support for the new ath9k caldata encoding (LZO) found in newer hardware revisions * Various fixes for ZyXEL Keenetic, ZyXEL NBG6616, TP-Link Archer C60 v1/v2, GL.iNet GL-AR750S, Embedded Wireless Dorin, Pirelli A226M-FWB, Arduino Yun Core components update * Linux kernel updated from 4.9.214 to 4.9.243 and from 4.14.171 to 4.14.206 * mbedtls updated from 2.16.4 to 2.16.8 * wireguard updated from 0.0.20190601 to 1.0.20200611 - For latest information about the 18.06 series, refer to the wiki at: https://openwrt.org/releases/18.06/ To download the v18.06.9 images, navigate to: https://downloads.openwrt.org/releases/18.06.9/targets/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream] ustream-openssl: fix bio memory leak
Eneas U de Queiroz [2020-12-09 14:39:06]: Hi, > So the answer to your question is because you only allocate the table if > methods_ustream is NULL, and it will point to the created table then. I was referencing the missing freeing of allocated resources. > We could free it in s_ustream_free, but only to have to create it again > with the same data the next time ustream_bio_new is called. I wouldn't do > it, but if you'd rather, I can add it in a v2. Is this micro optimization worth it? You're adding global variable in the library, you're breaking API layer etc. I'm not supposed to study how is it implemented _now_, because it will likely change with the next release (either OpenSSL or wolfSSL) and it might be source of regressions. The API boundary is given so I'm just trying to use it as designed and as seen in the docs/examples/tests etc. And there is always new/free combo. > As for the WIP, you're perhaps doing too much work. I'm spending time on this mainly because of FS#3465, perhaps mbedTLS has similar issues[1]. In the end I would like to have uclient/ustream-ssl CI tested (all 3 SSL libs combinations), with static analyzers, various sanitizers and Valgrind. So I have to fix all the issues those tools expose. Maybe it's too much work, but given the constraints (no globals, follow API), it's currently simplest working solution, but not fully tested yet. BTW I'm not discouraging you from v2, I've rejected the v1 patch, because it doesn't fix the memory leak as advertised in the subject :-) Thanks! 1. https://patchwork.ozlabs.org/project/openwrt/patch/trinity-0c56705d-7e2c-482a-a0b5-a3230d3e75b2-1533383113431@3c-app-gmx-bs62/ Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iftop: remove package
The package has no reason to be in openwrt.git. Move it to packages.git. Signed-off-by: Paul Spooren Acked-by: Jo-Philipp Wich --- package/network/utils/iftop/Makefile | 45 1 file changed, 45 deletions(-) delete mode 100644 package/network/utils/iftop/Makefile diff --git a/package/network/utils/iftop/Makefile b/package/network/utils/iftop/Makefile deleted file mode 100644 index 98fe15c8f5..00 --- a/package/network/utils/iftop/Makefile +++ /dev/null @@ -1,45 +0,0 @@ -# -# Copyright (C) 2006 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -include $(TOPDIR)/rules.mk - -PKG_NAME:=iftop -PKG_RELEASE:=1 - -PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL:=https://code.blinkace.com/pdw/iftop.git -PKG_SOURCE_DATE:=2018-10-03 -PKG_SOURCE_VERSION:=77901c8c53e01359d83b8090aacfe62214658183 -PKG_MIRROR_HASH:=219231541a437f5aecd497796be0202d337e13f141359a93595bf2cd8c5c5544 -PKG_MAINTAINER:=Jo-Philipp Wich -PKG_LICENSE:=GPL-2.0 - -PKG_FIXUP:=autoreconf - -include $(INCLUDE_DIR)/package.mk - -define Package/iftop - SECTION:=net - CATEGORY:=Network - DEPENDS:=+libpcap +libncurses +libpthread - TITLE:=display bandwith usage on an interface - URL:=http://www.ex-parrot.com/~pdw/iftop/ -endef - -define Package/iftop/description - iftop does for network usage what top(1) does for CPU usage. It - listens to network traffic on a named interface and displays a - table of current bandwidth usage by pairs of hosts. Handy for - answering the question 'why is our ADSL link so slow?'. -endef - -define Package/iftop/install - $(INSTALL_DIR) $(1)/usr/bin - $(INSTALL_BIN) $(PKG_BUILD_DIR)/iftop $(1)/usr/bin/ -endef - -$(eval $(call BuildPackage,iftop)) -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream] ustream-openssl: fix bio memory leak
On Wed, Dec 9, 2020 at 1:58 PM Daniel Golle wrote: > > On Wed, Dec 09, 2020 at 05:44:48PM +0100, Petr Štetiar wrote: > > Eneas U de Queiroz [2020-12-09 13:06:45]: > > > > Hi, > > > > > Using the patch by Pan Chen as inspiration, this avoids a memory leak by > > > using a global BIO_METHOD pointer that doesn't ordinarily need to be > > > freed. > > > > this sounds weird, how is global pointer avoiding memory leaks? :-) > > Well, it moves it from "definitely lost" to "still reachable" when > looking at it with valgrind. We will still have to free it as well, > and that could be done just like in the original patch. > See my reply to Petr. I'm not sure if valgrind will be completely pleased with my approach. I'm not an expert with valgrind, but it seems to not like that I left it in the heap to be cleaned up by the process end, but that is my intention. As long as I am not allocating memory again--it will only be created when methods_ustream is NULL, which is when it is initialized, and there's nowhere else in code that touches it. Note the const in the definition of: BIO * BIO_new(const BIO_METHOD *type); Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream] ustream-openssl: fix bio memory leak
On Wed, Dec 9, 2020 at 1:45 PM Petr Štetiar wrote:
>
> Eneas U de Queiroz [2020-12-09 13:06:45]:
>
> Hi,
>
> > Using the patch by Pan Chen as inspiration, this avoids a memory leak by
> > using a global BIO_METHOD pointer that doesn't ordinarily need to be
> > freed.
>
> this sounds weird, how is global pointer avoiding memory leaks? :-)
BIO_METHOD was made opaque by openssl 1.1.0. It's just a table of
methods, and it does change. Before that, one would just fill the
struct without having to make any calls.
I am the one responsible for introducing the bug in 34b0b80
[ustream-ssl: add openssl-1.1.0 compatibility]. The old, openssl 1.0
code was just:
static BIO_METHOD methods_ustream = {
100 | BIO_TYPE_SOURCE_SINK,
"ustream",
s_ustream_write,
s_ustream_read,
s_ustream_puts,
s_ustream_gets,
s_ustream_ctrl,
s_ustream_new,
s_ustream_free,
NULL,
};
So the answer to your question is because you only allocate the table
if methods_ustream is NULL, and it will point to the created table
then. The table won't change during the lifetime of the process, and
will get freed only when the process ends.
We could free it in s_ustream_free, but only to have to create it
again with the same data the next time ustream_bio_new is called. I
wouldn't do it, but if you'd rather, I can add it in a v2.
>
> > CC: Pan Chen
> >
> > Signed-off-by: Eneas U de Queiroz
> >
> > ---
> > Run-tested with a WRT-3200ACM, running uclient_fetch and uhttpd.
> > I have not run it with valgrind or any other debugger.
>
> how do you otherwise verify the correctness? :-) FYI this is my work in
> progress[1].
>
> 1.
> https://gitlab.com/ynezz/openwrt-ustream-ssl/-/commit/807ce1de752e021802a563783dfa580950746a0c
As for testing I don't have valgrind running, so I wasn't able to do
it; but someone else can. That's why I made sure to point it out. As
for the WIP, you're perhaps doing too much work.
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream] ustream-openssl: fix bio memory leak
On Wed, Dec 09, 2020 at 05:44:48PM +0100, Petr Štetiar wrote: > Eneas U de Queiroz [2020-12-09 13:06:45]: > > Hi, > > > Using the patch by Pan Chen as inspiration, this avoids a memory leak by > > using a global BIO_METHOD pointer that doesn't ordinarily need to be > > freed. > > this sounds weird, how is global pointer avoiding memory leaks? :-) Well, it moves it from "definitely lost" to "still reachable" when looking at it with valgrind. We will still have to free it as well, and that could be done just like in the original patch. > > > CC: Pan Chen > > > > Signed-off-by: Eneas U de Queiroz > > > > --- > > Run-tested with a WRT-3200ACM, running uclient_fetch and uhttpd. > > I have not run it with valgrind or any other debugger. > > how do you otherwise verify the correctness? :-) FYI this is my work in > progress[1]. > > 1. > https://gitlab.com/ynezz/openwrt-ustream-ssl/-/commit/807ce1de752e021802a563783dfa580950746a0c > > Cheers, > > Petr > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream] ustream-openssl: fix bio memory leak
Eneas U de Queiroz [2020-12-09 13:06:45]: Hi, > Using the patch by Pan Chen as inspiration, this avoids a memory leak by > using a global BIO_METHOD pointer that doesn't ordinarily need to be > freed. this sounds weird, how is global pointer avoiding memory leaks? :-) > CC: Pan Chen > > Signed-off-by: Eneas U de Queiroz > > --- > Run-tested with a WRT-3200ACM, running uclient_fetch and uhttpd. > I have not run it with valgrind or any other debugger. how do you otherwise verify the correctness? :-) FYI this is my work in progress[1]. 1. https://gitlab.com/ynezz/openwrt-ustream-ssl/-/commit/807ce1de752e021802a563783dfa580950746a0c Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH ustream] ustream-openssl: fix bio memory leak
Using the patch by Pan Chen as inspiration, this avoids a memory leak by
using a global BIO_METHOD pointer that doesn't ordinarily need to be
freed.
CC: Pan Chen
Signed-off-by: Eneas U de Queiroz
---
Run-tested with a WRT-3200ACM, running uclient_fetch and uhttpd.
I have not run it with valgrind or any other debugger.
diff --git a/ustream-io-openssl.c b/ustream-io-openssl.c
index 606ed4a..26b3ed5 100644
--- a/ustream-io-openssl.c
+++ b/ustream-io-openssl.c
@@ -116,20 +116,23 @@ static long s_ustream_ctrl(BIO *b, int cmd, long num,
void *ptr)
};
}
+static BIO_METHOD *methods_ustream = NULL;
+
static BIO *ustream_bio_new(struct ustream *s)
{
BIO *bio;
- BIO_METHOD *methods_ustream;
-
- methods_ustream = BIO_meth_new(100 | BIO_TYPE_SOURCE_SINK, "ustream");
- BIO_meth_set_write(methods_ustream, s_ustream_write);
- BIO_meth_set_read(methods_ustream, s_ustream_read);
- BIO_meth_set_puts(methods_ustream, s_ustream_puts);
- BIO_meth_set_gets(methods_ustream, s_ustream_gets);
- BIO_meth_set_ctrl(methods_ustream, s_ustream_ctrl);
- BIO_meth_set_create(methods_ustream, s_ustream_new);
- BIO_meth_set_destroy(methods_ustream, s_ustream_free);
+ if (methods_ustream == NULL) {
+ methods_ustream = BIO_meth_new(100 | BIO_TYPE_SOURCE_SINK,
+ "ustream");
+ BIO_meth_set_write(methods_ustream, s_ustream_write);
+ BIO_meth_set_read(methods_ustream, s_ustream_read);
+ BIO_meth_set_puts(methods_ustream, s_ustream_puts);
+ BIO_meth_set_gets(methods_ustream, s_ustream_gets);
+ BIO_meth_set_ctrl(methods_ustream, s_ustream_ctrl);
+ BIO_meth_set_create(methods_ustream, s_ustream_new);
+ BIO_meth_set_destroy(methods_ustream, s_ustream_free);
+ }
bio = BIO_new(methods_ustream);
BIO_set_data(bio, s);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
