CVEs in OpenWrt 22.03

[Peter Naulls]

Apologies for the obtuseness of the previous email about the squashfs 
permissions - that's related to the following, but a different topic.  I can now
say that we're undergoing a security review for our system which is very much
based upon OpenWrt 22.03.

If you have ever done this, you'll probably know what's in such things, lots
of picky items, much that is to be polite, spurious and many other things
which are of little relevance, but are security theater and therefore
important to people who make such reports.  Nevertheless, I do have to
provide answers and "proof" for everything.

The following is partly for my own benefit, but it might benefit anyone
else who is settling upon 22.03 for a stable version and will be doing
the same in the near future.

First a request on patch naming in OpenWrt - if it's a specific CVE patch, then
it would help that it was named that. I know that often isn't possible, since
often they get rolled up into other upstream patches, pulled out of git, etc, 
etc, but it would help.

For the kernel, a great many of the CVEs in my report relate to the 5.15
kernel series. The dumb assumption here is a that the 5.10 series
kernel is "older", and therefore these must apply to. The reality is that
in most cases, these are issues introduced in that series for new features,
or they've been backported by either the 5.10 maintainers or the OpenWrt
maintainers, both of who I know are on top of such things.

For other remaining CVEs, sometimes it's very hard to know, unless you
can (a) rule out for sure the driver/subsystem isn't in use, or failing
that (b) close code examination and hand-waving that the patch isn't
relevant, sans intimate knowledge of the codebase.

CVE-2022-500 and CVE-2021-4150 are examples here.

For CVE-2022-39188, CVE-2021-3669, it seems like they might get 5.10 series
patches, if they are relevant, so I will wait on a kernel bump on those.


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.

However, there is CVE-20220-0934.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39

Which can easily be patched, or update to dnsmasq 2.87.

busybox 1.35.0 - CVE-2022-30065

I brought in patches from here:

https://bugs.busybox.net/show_bug.cgi?id=14781

tcpdump 4.9.3 - CVE-2018-16303

Long since in OpenWrt patches.

e2fsprogs 1.46.5 - CVE-2022-1304

I brought in this patch:

diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
index b324c7b0..1a206a16 100644
--- a/lib/ext2fs/extent.c
+++ b/lib/ext2fs/extent.c
@@ -495,6 +495,10 @@ retry:
  			ext2fs_le16_to_cpu(eh->eh_entries);
  		newpath->max_entries = ext2fs_le16_to_cpu(eh->eh_max);

+		/* Make sure there is at least one extent present */
+		if (newpath->left <= 0)
+			return EXT2_ET_EXTENT_NO_DOWN;
+
  		if (path->left > 0) {
  			ix++;
  			newpath->end_blk = ext2fs_le32_to_cpu(ix->ei_block);
@@ -1630,6 +1634,10 @@ errcode_t ext2fs_extent_delete(ext2_extent_handle_t 
handle, int flags)

  	cp = path->curr;

+	/* Sanity check before memmove() */
+	if (path->left < 0)
+		return EXT2_ET_EXTENT_LEAF_BAD;
+
  	if (path->left) {
  		memmove(cp, cp + sizeof(struct ext3_extent_idx),
  			path->left * sizeof(struct ext3_extent_idx));


lua 5.1.5 and lua 5.3.

CVE-2014-5461 and others. lua 5.1.5 has been heavily patched in OpenWrt,
and I suspect these have all long since been fixed.

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?

There's much more, but that's quite enough for now.