Re: New CVE entries this week

[Dan Carpenter <error27@gmail.com>]

[ Still going through old stuff from the holiday season ]

On Thu, Dec 22, 2022 at 07:58:48AM +0900, Masami Ichikawa wrote:
> CVE-2022-47518: wifi: wilc1000: validate number of channels
> 
> CVSS v3 score is not provided
> 
> An issue was discovered in the Linux kernel before 6.0.11. Missing
> validation of the number of channels in
> drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000
> wireless driver can trigger a heap-based buffer overflow when copying
> the list of operating channels from Wi-Fi management frames.
> 
> It looks like a vulnerable function is not present on 4.4 and 4.9.
> That function is present in 5.4 and 4.19 however, this driver is
> staging driver at that time.
> Also, implementation of wilc_wfi_cfg_parse_ch_attr() in 5.4 and 4.19
> are different from newer code. It seems as if they are not affected.
> 
> Fixed status
> mainline: [0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0]
> stable/5.10: [3eb6b89a4e9f9e44c3170d70d8d16c3c8dc8c800]
> stable/5.15: [7aed1dd5d221dabe3fe258f13ecf5fc7df393cbb]
> stable/6.0: [6195b4838e10a557859862c4e7840dc0eafdd1cd]
> 
> CVE-2022-47519: wifi: wilc1000: validate length of
> IEEE80211_P2P_ATTR_OPER_CHANNEL attribute

This is probably something which could have been caught with static
analysis.  The first problem was that cfg80211_find_vendor_ie() takes
a struct and casts it to a char *.  Smatch correctly marks some of the
struct members as user data, but loses that information when the cast
happens.

It is easy to hard code cfg80211_find_vendor_ie() as returning user data
so we avoid this bug in the future.

diff --git a/smatch_points_to_user_data.c b/smatch_points_to_user_data.c
index 4267b85b53a7..f632d8c84452 100644
--- a/smatch_points_to_user_data.c
+++ b/smatch_points_to_user_data.c
@@ -49,7 +49,7 @@ STATE(user_data_set);
 static const char *returns_pointer_to_user_data[] = {
 	"nlmsg_data", "nla_data", "memdup_user", "kmap_atomic", "skb_network_header",
 	"cfg80211_find_elem_match", "ieee80211_bss_get_elem", "cfg80211_find_elem",
-	"ieee80211_bss_get_ie",
+	"ieee80211_bss_get_ie", "cfg80211_find_vendor_ie",
 };
 
 bool is_skb_data(struct expression *expr)

Then from there, I actually have an unpublished static checker warning
which would have triggered.

drivers/net/wireless/microchip/wilc1000/cfg80211.c:991 wilc_wfi_cfg_parse_ch_attr() warn: uncapped user loop: 'attr_size'

Currently it prints 178 warnings.  It warns for things like:

        for (i = 0; i < user_controlled_value; i++)

But it's kind of useless.  There are too many times where the loop is
uncapped but it doesn't result in an out of bounds access.  For example,
the user_controlled_value could be number of seconds instead of array
offsets.  I need to add to the check and cut down on the false
positives.  I will do that today.

Update on my employment situation:  I have been lazy about looking for
Smatch funding.  But a lot of the things I'm looking at are a
subscription model where people get the warnings instead of the source
code.  These emails are intended to help the Kernel security community
to understand better how to continue the work after I have moved on.
Please email me if you have questions, because right now I have time and
I want to help people take on this work.

regards,
dan carpenter