Re: CVEs in OpenWrt 22.03
On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! I also prefer if the CVE number is named in the patch. If this is missing somewhere you could send a patch or pull request to rename the patch. I'm afraid I don't have any explicit examples, but I'll let you know if find any. There are some concerns with the older lua I mentioned below, but I'll need to come back to those. In any case, a suggestion for future CVE patches. The OpenWrt project does not have enough resources to maintain security patches for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and we update to the most recent LTS version every few days or weeks in the maintained branches. If some security patches are missing in the LTS kernel versions used by OpenWrt it is probably best to approach the Linux stable team directly. See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure system" section: http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Yes, sure. And whether you or I agree with this or not is to some degree irrelevant, since what matters to the security people is that they see the bug fixed. In 90% of the cases I was able to dismiss CVEs since the subsystems in question are not in use by us (or most of OpenWrt for that matter. e.g, frame buffers), but some tricky ones remain. That said, there's a very large number of patches to the kernel in OpenWrt; mostly for new device function, pending fixes or whatnot; I guess few of these are actual security fixes. So, to user space: dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't go over particularly well, even though they have been properly dismissed by the Simon Kelley and others. See my mail on the dnsmasq mailing list: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html Yes, and was referred to and well understood by myself at least. Still, the objection is that Mitre have this as "disputed", which is rather unhelpful, and that is what is being focused upon. Obviously I cannot fix something that isn't broken and has no fix, so there's no satisfactory answer here to a security review beyond getting the CVEs dismissed from Mitre. tcpdump 4.9.3 - CVE-2018-16303 This CVE is not for tcpdump, but PDF-XChange Editor: https://nvd.nist.gov/vuln/detail/CVE-2018-16303 Sorry, trying to juggle lots of items here. https://nvd.nist.gov/vuln/detail/CVE-2018-16301 Long since in OpenWrt patches. e2fsprogs 1.46.5 - CVE-2022-1304 This is pretty hard to attack. You could provide a patch. This was the patch I provided here: I brought in this patch: diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c index b324c7b0..1a206a16 100644 Yes, very large files on OpenWrt are unlikely without external media. If would be simply easier on the optics if I was able to ditch 5.1.5 in the build and just use 5.3 - is this possible; I'm sure there's been much discussion on this before, so please point me at that - will it break luci? An update to Lua 5.4 would be good, but I do not know which impact it has. Understood. I'm going to come back to this later in another post. There's much more, but that's quite enough for now. OpenWrt is a mostly volunteer run project. Especially (security) maintenance does not get paid by companies. If you have some fixes tested patches would be really helpful. Yes, I know, and to say my reliance upon OpenWrt over the years is considerable would be an understatement, but my time is limited as well, and my focus must be on addressing specifics to the security review. Still, I felt it better to at least have a partial discussion here, and do what little I can. I don't necessarily have time to roll patches in a format suitable for OpenWrt upstreaming; sometimes I think it's more constructive to simply point out what can be done, and have the maintainers do it. Maybe not ideal, but it's something. Look for some more posts on specific topics in the near future. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls wrote: > > On 10/24/22 18:21, Hauke Mehrtens wrote: > > Hauke, thanks for replying! As I said on a related thread - if an eu body can be found to care more deeply on these issues, I'm pretty sure 30-50k of funding is available via one or more of nlnet's grant programs. Applications for this round close december 1st. https://nlnet.nl/ > > > > I also prefer if the CVE number is named in the patch. If this is missing > > somewhere you could send a patch or pull request to rename the patch. > > I'm afraid I don't have any explicit examples, but I'll let you know if > find any. There are some concerns with the older lua I mentioned below, > but I'll need to come back to those. In any case, a suggestion for future > CVE patches. > > > > > The OpenWrt project does not have enough resources to maintain security > > patches > > for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and > > we > > update to the most recent LTS version every few days or weeks in the > > maintained > > branches. If some security patches are missing in the LTS kernel versions > > used > > by OpenWrt it is probably best to approach the Linux stable team directly. > > > > See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure > > system" section: > > http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ > > Yes, sure. And whether you or I agree with this or not is to some degree > irrelevant, since what matters to the security people is that they see > the bug fixed. In 90% of the cases I was able to dismiss CVEs > since the subsystems in question are not in use by us (or most of OpenWrt > for that matter. e.g, frame buffers), but some tricky ones remain. > > That said, there's a very large number of patches to the kernel in > OpenWrt; mostly for new device function, pending fixes or whatnot; > I guess few of these are actual security fixes. > > >> So, to user space: > >> > >> dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't > >> go > >> over particularly well, even though they have been properly dismissed by > >> the Simon Kelley and others. > > > > See my mail on the dnsmasq mailing list: > > https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html > > Yes, and was referred to and well understood by myself at least. Still, the > objection is that Mitre have this as "disputed", which is rather unhelpful, > and > that is what is being focused upon. Obviously I cannot fix something that > isn't > broken and has no fix, so there's no satisfactory answer here to a security > review beyond getting the CVEs dismissed from Mitre. > > > > > >> tcpdump 4.9.3 - CVE-2018-16303 > > > > This CVE is not for tcpdump, but PDF-XChange Editor: > > https://nvd.nist.gov/vuln/detail/CVE-2018-16303 > > Sorry, trying to juggle lots of items here. > > https://nvd.nist.gov/vuln/detail/CVE-2018-16301 > > > >> Long since in OpenWrt patches. > >> > >> e2fsprogs 1.46.5 - CVE-2022-1304 > > > > This is pretty hard to attack. You could provide a patch. > > This was the patch I provided here: > > >> > >> I brought in this patch: > >> > >> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c > >> index b324c7b0..1a206a16 100644 > > Yes, very large files on OpenWrt are unlikely without external > media. > > >> > >> If would be simply easier on the optics if I was able to ditch 5.1.5 in the > >> build and just use 5.3 - is this possible; I'm sure there's been much > >> discussion on this before, so please point me at that - will it break luci? > > > > An update to Lua 5.4 would be good, but I do not know which impact it has. > > Understood. I'm going to come back to this later in another post. > > > >> There's much more, but that's quite enough for now. > > > > OpenWrt is a mostly volunteer run project. Especially (security) maintenance > > does not get paid by companies. If you have some fixes tested patches would > > be > > really helpful. > > Yes, I know, and to say my reliance upon OpenWrt over the years is > considerable > would be an understatement, but my time is limited as well, and my focus > must be on addressing specifics to the security review. Still, I felt it > better to at least have a partial discussion here, and do what little I can. > > I don't necessarily have time to roll patches in a format suitable > for OpenWrt upstreaming; sometimes I think it's more constructive to simply > point out what can be done, and have the maintainers do it. Maybe not ideal, > but it's something. > > Look for some more posts on specific topics in the near future. > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz Dave Täht CEO, Tek
Security changes - restricting uhttpd addresses
The default uhttpd configuration has this: # HTTP listen addresses, multiple allowed list listen_http0.0.0.0:80 list listen_http[::]:80 Now, I know there's lots of practical reasons for this to be the case, and I know also that the firewall setup in OpenWrt is robust and isn't going to allow WAN-side access. Nevertheless, the security people are looking at this config statically, and not seeing that it's bound to the LAN interface IP only. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. For my use, I've changed the default binding to the LAN IP, and also added another init.d script to check the current LAN address, and update the uhttpd config if need be and then restart it (and add a config hook to the network config). Obviously this isn't very satisfactory, open to better suggestions here. It might also be better if uhttpd could be configured to bind to a specific interface rather than knowing its IP upfront, but that might be impractical. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
> The default uhttpd configuration has this: > > # HTTP listen addresses, multiple allowed > list listen_http0.0.0.0:80 > list listen_http[::]:80 > > Now, I know there's lots of practical reasons for this to be the case, > and I know also that the firewall setup in OpenWrt is robust and > isn't going to allow WAN-side access. > > Nevertheless, the security people are looking at this config > statically, and not seeing that it's bound to the LAN interface IP > only. It might be easy to bind to the LAN interface in a simple product but OpenWrt might have multiple interfaces. It is much easier to let the firewall zones deal with that. > As aside, they don't see the iptables tool in the system, and don't > understand that that's been deprecated (although I since did add it > for some unrelated legacy usage), and think there's no firewall at all. 22.03? Did you read the release notes? nftables. > For my use, I've changed the default binding to the LAN IP, and also > added another init.d script to check the current LAN address, and > update the uhttpd config if need be and then restart it (and add > a config hook to the network config). Obviously this isn't > very satisfactory, open to better suggestions here. It would be better to improve the uhttpd startup script, allowing it to bind to a list of openwrt interfaces. It is always better to reference an existing config than to duplicate it. Or leave the original bind address. > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. No, there are dozens of services that do just that. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote: is much easier to let the firewall zones deal with that. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. 22.03? Did you read the release notes? nftables. Luiz, I think you might have missed the context of my post - perhaps you missed my earlier ones. I'm well aware that nftables is in use, but this is in a security review, and they see what they want to see. It would be better to improve the uhttpd startup script, allowing it to bind to a list of openwrt interfaces. It is always better to reference an existing config than to duplicate it. Or leave the original bind address. I agree that's a better solution. I don't think I've advocated duplicating config though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Peter Naulls wrote: > On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote: > is much easier to let the firewall zones deal with that. > > > >> As aside, they don't see the iptables tool in the system, and don't > >> understand that that's been deprecated (although I since did add it > >> for some unrelated legacy usage), and think there's no firewall at all. > > > > 22.03? Did you read the release notes? nftables. > > Luiz, I think you might have missed the context of my post - > perhaps you missed my earlier ones. I'm well aware that > nftables is in use, but this is in a security review, and they > see what they want to see. If they see what they want to see, then why should anyone else get involved in their wish fulfilment? Security review is fine, security should not be entertained, and certainly foisted on other people? Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 16:40, Karl Palsson wrote: Peter Naulls wrote: If they see what they want to see, then why should anyone else get involved in their wish fulfilment? Security review is fine, security should not be entertained, and certainly foisted on other people? Karl, not sure where you're going with this. You haven't named anything practical here, apart from suggesting ignoring it. OpenWrt is widely used nowadays, probably more than most people expect, security reviews like this are likely to become more common. I think everyone bothering to read this understands the theatre aspects of all this that I called out in my original post. Whether things should actually be fixed (or "fixed") is certainly an open question, but if I can save someone some future grief, or at least have the discussion, then I might save myself or someone else some time. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Security changes - restricting uhttpd addresses
I have myself gone through the process of getting an openwrt based product through a security audit. > I think everyone bothering to read this understands the theatre aspects of all > this that I called out in my original post. Whether things should actually be > fixed (or "fixed") is certainly an open question, but if I can save someone > some future grief, or at least have the discussion, then I might save myself > or > someone else some time. The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. > That said, I think that limiting the listening ports of uhttpd is a good > idea. I > hardly see any downside to it, apart from maybe adding some complexity. I think adding complexity here is a pretty good argument against this. Regard, Reuben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:25, Reuben Dowle wrote: I have myself gone through the process of getting an openwrt based product through a security audit. The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. Well, I agree. For clarity, years ago I had been through reviews with both Microsoft and Intel, with some combination of Ubuntu/OpenWrt, so had some expectation here. Those reviews turned up their share of nonsense, but things have changed I guess. My hands are tied, we gotta do the dance. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. I think adding complexity here is a pretty good argument against this. Certainly. But failing an official fix, I'm left to a workaround of my own devising, which is unlikely to be robust in the short term, but will have to do - unless someone has other suggestions. To be clear to everyone here - I appreciate the feedback, and likely agree with everything that's been said - I've been doing this as long as you guys, so I know the ins and outs, but I think the conversation is still worth having. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Peter Naulls wrote: > Nevertheless, the security people are looking at this config > statically, and not seeing that it's bound to the LAN interface IP > only. I don't think they are really security people, but... > For my use, I've changed the default binding to the LAN IP, and also > added another init.d script to check the current LAN address, and > update the uhttpd config if need be and then restart it (and add > a config hook to the network config). Obviously this isn't > very satisfactory, open to better suggestions here. So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated And when we make guest LANs, we may also need to bind it to that, because there are things that guests might need to know, such as seeing the status page to see if the network is up. > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. It's totally impractical. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 5:34 PM, Peter Naulls wrote: On 10/25/22 17:25, Reuben Dowle wrote: The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. Well, I agree. For clarity, years ago I had been through reviews with both Microsoft and Intel, with some combination of Ubuntu/OpenWrt, so had some expectation here. Those reviews turned up their share of nonsense, but things have changed I guess. My hands are tied, we gotta do the dance. I mean this as gently as possible, but I think what a lot of us are missing is the benefit to the OpenWrt project to carry an increased maintenance burden in response to your internal requirements, which you openly state add no value. Maybe your time is better spent fixing your organization's processes, rather than trying to make volunteers responsive to what we all agree are pointless requirements? -Nathan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/2] realtek: fix L2 entry setup and learning on CPU port
This is a follow-up to the patch "realtek: don't set L2LEARNING flag in rtl83xx TX header". An undesired effect of that patch is flooding of some packets destined for the switch CPU port, which is addressed by this additional patch series. This patch series switches to assisted learning for the CPU port on all devices, and also fixes some existing issues with setup of unicast L2 entries. Together with the kernel 5.15 pull request, entries for local/bridge addresses are added to the switch. I am still not sure why that doesn't work with the patches in the current kernel. However, the pull request for the kernel update seems to be in a good shape, so I don't think it is worth it to investigate that any further. Tested on RTL838x (HPE 1920-8G) and RTL839x (HPE 1920-48G). Changes in v2: - don't explicitly specify struct name as parameter to sizeof - make calculation of SALRN shift offset clearer - define SALRN values, mask and shift offset in header Jan Hoffmann (2): realtek: set up L2 table entries properly realtek: use assisted learning on CPU port .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 45 ++- .../drivers/net/dsa/rtl83xx/rtl838x.h | 6 +++ 2 files changed, 41 insertions(+), 10 deletions(-) -- 2.37.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] realtek: use assisted learning on CPU port
L2 learning on the CPU port is currently not consistently configured and
relies on the default configuration of the device. On RTL83xx, it is
disabled for packets transmitted with a TX header, as hardware learning
corrupts the forwarding table otherwise. As a result, unneeded flooding
of traffic for the CPU port can already happen on some devices now. It
is also likely that similar issues exist on RTL93xx, which doesn't have
a field to disable learning in the TX header.
To address this, disable hardware learning for the CPU port globally on
all devices. Instead, enable assisted learning to let DSA write FDB
entries to the switch.
For now, this does not sync local/bridge entries to the switch. However,
support for that was added in Linux 5.14, so the next switch to a newer
kernel version is going to fix this.
Signed-off-by: Jan Hoffmann
---
.../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 16
.../files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h | 6 ++
2 files changed, 22 insertions(+)
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 474d540945d1..319f171eaacc 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -162,6 +162,16 @@ static void rtl83xx_setup_bpdu_traps(struct
rtl838x_switch_priv *priv)
priv->r->set_receive_management_action(i, BPDU, COPY2CPU);
}
+static void rtl83xx_port_set_salrn(struct rtl838x_switch_priv *priv,
+ int port, bool enable)
+{
+ int shift = SALRN_PORT_SHIFT(port);
+ int val = enable ? SALRN_MODE_HARDWARE : SALRN_MODE_DISABLED;
+
+ sw_w32_mask(SALRN_MODE_MASK << shift, val << shift,
+ priv->r->l2_port_new_salrn(port));
+}
+
static int rtl83xx_setup(struct dsa_switch *ds)
{
int i;
@@ -205,6 +215,9 @@ static int rtl83xx_setup(struct dsa_switch *ds)
priv->r->l2_learning_setup();
+ rtl83xx_port_set_salrn(priv, priv->cpu_port, false);
+ ds->assisted_learning_on_cpu_port = true;
+
/*
* Make sure all frames sent to the switch's MAC are trapped to the
CPU-port
* 0: FWD, 1: DROP, 2: TRAP2CPU
@@ -263,6 +276,9 @@ static int rtl93xx_setup(struct dsa_switch *ds)
priv->r->l2_learning_setup();
+ rtl83xx_port_set_salrn(priv, priv->cpu_port, false);
+ ds->assisted_learning_on_cpu_port = true;
+
rtl83xx_enable_phy_polling(priv);
priv->r->pie_init(priv);
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
index e2b82a4975f0..10913dacef42 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
@@ -245,6 +245,12 @@
#define RTL839X_L2_PORT_NEW_SALRN(p) (0x38F0 + (((p >> 4) << 2)))
#define RTL930X_L2_PORT_SALRN(p) (0x8FEC + (((p >> 4) << 2)))
#define RTL931X_L2_PORT_NEW_SALRN(p) (0xC820 + (((p >> 4) << 2)))
+
+#define SALRN_PORT_SHIFT(p)((p % 16) * 2)
+#define SALRN_MODE_MASK0x3
+#define SALRN_MODE_HARDWARE0
+#define SALRN_MODE_DISABLED2
+
#define RTL838X_L2_PORT_NEW_SA_FWD(p) (0x3294 + (((p >> 4) << 2)))
#define RTL839X_L2_PORT_NEW_SA_FWD(p) (0x3900 + (((p >> 4) << 2)))
#define RTL930X_L2_PORT_NEW_SA_FWD(p) (0x8FF4 + (((p / 10) << 2)))
--
2.37.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/2] realtek: set up L2 table entries properly
Initialize the data structure using memset to avoid the possibility of
writing garbage values to the hardware.
Always set a valid entry type, which should fix writing unicast entries
on RTL930x.
For unicast entries, set the is_static flag to prevent the switch from
aging them out.
Also set the rvid field for unicast entries. This is not strictly
necessary, as the switch fills it in automatically from a non-zero vid.
However, this makes the code consistent with multicast entry setup.
While at it, reorder the statements and fix some style issues (double
space, comma instead of semicolon at end of statement). Also remove the
unneeded priv parameter and debug print for the multicast entry setup
function.
Fixes: cde31976e37 ("realtek: Add support for Layer 2 Multicast")
Signed-off-by: Jan Hoffmann
---
.../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 29 ---
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 3ff1a96ed680..474d540945d1 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -1559,23 +1559,32 @@ static void dump_l2_entry(struct rtl838x_l2_entry *e)
static void rtl83xx_setup_l2_uc_entry(struct rtl838x_l2_entry *e, int port,
int vid, u64 mac)
{
- e->is_ip_mc = e->is_ipv6_mc = false;
+ memset(e, 0, sizeof(*e));
+
+ e->type = L2_UNICAST;
e->valid = true;
+
e->age = 3;
- e->port = port,
- e->vid = vid;
+ e->is_static = true;
+
+ e->port = port;
+
+ e->rvid = e->vid = vid;
+ e->is_ip_mc = e->is_ipv6_mc = false;
u64_to_ether_addr(mac, e->mac);
}
-static void rtl83xx_setup_l2_mc_entry(struct rtl838x_switch_priv *priv,
- struct rtl838x_l2_entry *e, int vid, u64
mac, int mc_group)
+static void rtl83xx_setup_l2_mc_entry(struct rtl838x_l2_entry *e, int vid, u64
mac, int mc_group)
{
- e->is_ip_mc = e->is_ipv6_mc = false;
+ memset(e, 0, sizeof(*e));
+
+ e->type = L2_MULTICAST;
e->valid = true;
+
e->mc_portmask_index = mc_group;
- e->type = L2_MULTICAST;
+
e->rvid = e->vid = vid;
- pr_debug("%s: vid: %d, rvid: %d\n", __func__, e->vid, e->rvid);
+ e->is_ip_mc = e->is_ipv6_mc = false;
u64_to_ether_addr(mac, e->mac);
}
@@ -1815,7 +1824,7 @@ static void rtl83xx_port_mdb_add(struct dsa_switch *ds,
int port,
err = -ENOTSUPP;
goto out;
}
- rtl83xx_setup_l2_mc_entry(priv, &e, vid, mac, mc_group);
+ rtl83xx_setup_l2_mc_entry(&e, vid, mac, mc_group);
priv->r->write_l2_entry_using_hash(idx >> 2, idx & 0x3,
&e);
}
goto out;
@@ -1836,7 +1845,7 @@ static void rtl83xx_port_mdb_add(struct dsa_switch *ds,
int port,
err = -ENOTSUPP;
goto out;
}
- rtl83xx_setup_l2_mc_entry(priv, &e, vid, mac, mc_group);
+ rtl83xx_setup_l2_mc_entry(&e, vid, mac, mc_group);
priv->r->write_cam(idx, &e);
}
goto out;
--
2.37.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:45, Michael Richardson wrote: So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated Sorry, I badly paraphrased. The requested change was for IPv4 only. I don't anticipate any IPv6 changes here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
lua 5.1.5 CVEs
Lua 5.1.5 would appear to have CVEs below against it. The patches to this in OpenWrt are significant, but dated, with the last bug fix seeming to be from 2019, so it's hard to say if these are addressed: https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15888 https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900ce0b7 https://github.com/lua/lua/commit/eb41999461b6f428186c55abd95f4ce1a76217d5 I can't see that these have been applied - correct me here please. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43519 This appears to be the fix: https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900ce0b7 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15945 Fix here: https://github.com/lua/lua/commit/a2195644d89812e5b157ce7bac35543e06db05e3 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5461 This is ancient, and may have long since been fixed, although I can't find the exact patch. This would be a good example where if the CVE patches had been applied, naming them well would help. The "better" fix would arguably to move to lua 5.3 or even 5.4, but as I mentioned in an earlier post, I'm not sure if this is possible or what it might break in luci. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: lua 5.1.5 CVEs
I have run into these CVEs during an audit. I looked into the patches linked to them, and it seems that the ancient lua code for 5.1.5 was very different from the code where the patches are created against. When I attempted to manually make similar changes in the code, it seemed to me that the older lua code was probably not vulnerable in the same way. So in the end I just marked these CVEs as not applying to the version of LUA in use. My opinion is that openwrt should try and move to a newer version of lua. This old 5.1.5 version appears to be unmaintained, and there does not seem to be the resources within the openwrt community to change that. > -Original Message- > From: openwrt-devel On > Behalf Of Peter Naulls > Sent: Wednesday, 26 October 2022 12:06 pm > To: OpenWrt Development List > Subject: lua 5.1.5 CVEs > > > Lua 5.1.5 would appear to have CVEs below against it. > > The patches to this in OpenWrt are significant, but dated, with the last bug > fix > seeming to be from 2019, so it's hard to say if these are addressed: > > https://github.com/openwrt/openwrt/tree/openwrt- > 22.03/package/utils/lua/patches > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15888 > > https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900 > ce0b7 > https://github.com/lua/lua/commit/eb41999461b6f428186c55abd95f4ce1a76 > 217d5 > > I can't see that these have been applied - correct me here please. > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43519 > > This appears to be the fix: > > https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900 > ce0b7 > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15945 > > Fix here: > > https://github.com/lua/lua/commit/a2195644d89812e5b157ce7bac35543e06 > db05e3 > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5461 > > This is ancient, and may have long since been fixed, although I can't find the > exact patch. > > This would be a good example where if the CVE patches had been applied, > naming them well would help. > > The "better" fix would arguably to move to lua 5.3 or even 5.4, but as I > mentioned in an earlier post, I'm not sure if this is possible or what it > might > break in luci. > > Thanks! > > > ___ > 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
