[LTS 9.2] CVE-2024-38562

[pvts-mat]

[LTS 9.2]
CVE-2024-38562
VULN-43268

Problem

https://access.redhat.com/security/cve/CVE-2024-38562

A vulnerability has been identified in the Linux kernel, specifically involving a possible out-of-bounds array indexing within the net/wireless/nl80211.c file (related to the wireless networking subsystem). This flaw can lead to a kernel-level crash, resulting in a denial-of-service condition for the affected system.

Applicability: no

First of all, this is not a vulnerability and there is no problem. The RedHat's CVE page at https://access.redhat.com/security/cve/CVE-2024-38562 is wrong and so is https://www.cve.org/CVERecord?id=CVE-2024-38562. The fixing mainline commit 838c7b8 is another case of changing the way flexible arrays are used to align with how CONFIG_UBSAN_BOUNDS functionality, along with __counted_by annotations, expects it: the variable defining the size must be increased first, before the new elements of the flexible array are accessed. The previous case like this was CVE-2024-41071 (#103) and it was rejected (see https://www.cve.org/CVERecord?id=CVE-2024-41071). Compare the associated commits, which even preserve the same wording:

CVE-2024-41071, 2663d04

wifi: mac80211: Avoid address calculations via out of bounds array indexing

req->n_channels must be set before req->channels[] can be used.

CVE-2024-38562, 838c7b8:

wifi: nl80211: Avoid address calculations via out of bounds array indexing
    
Before request->channels[] can be used, request->n_channels must be set.

Analyzing the change 838c7b8 it can be seen that there are no semantic changes to the code. The equivalence of request->ssids and request->ie assignments before & after can be easily seen once the layout of request is depicted along with all the variables involved:

 |<--------------ie_offset--------------------->|
 |<--------ssids_offset-------->|               |
 |         |<----n_channels---->|<---n_ssids--->|
-------------------------------------------------------
 ^         ^                    ^               ^
 request   request->channels    request->ssids  request->ie

Putting the validity of CVE aside, no one will be disturbed by the UBSAN errors if this CVE is not patched, because the "fixes" commit e3eac9f, consisting of a single __counted_by annotation in the cfg80211_scan_request struct, is missing from ciqlts9_2 history, nor was it backported, see

kernel-src-tree/include/net/cfg80211.h

Line 2462 in f85f16c

struct ieee80211_channel *channels[];

The patched version is cleaner, simpler and friendlier to the boundary checking machine, it would therefore may be beneficial to switch to it anyway. However, the fixing 838c7b8 commit requires at least 14e05be as the prerequisite to be cherry-picked cleanly, and the resulting code still requires some changes (either another prereq or a manual change) as it doesn't compile because of the size-arithmetic macros definitions not included in the net/wireless/nl80211.c file.

Considering all of the above it was decided the CVE-2024-38562 is not applicable to LTS 9.2.

[pvts-mat]

The "draft" status is only to prevent accidental merge, the PR is ready for review.

[PlaidCat]

I'm sufficiently pleased that while this is not invalid from bellow I want to make sure that no one else disagrees

The previous case like this was GHSA-m487-w7jq-5grr (#103) and it was rejected (see https://www.cve.org/CVERecord?id=CVE-2024-41071).

Is this statement because they have an RHSA for RHEL 9 ie https://access.redhat.com/errata/RHSA-2024:6997

First of all, this is not a vulnerability and there is no problem. The RedHat's CVE page at https://access.redhat.com/security/cve/CVE-2024-38562

This is because that Security advisory was made for 9.4 when 9.4 was the active new release.

[pvts-mat]

I want to make sure that no one else disagrees

Of course, I was actually surprised the "not applicable" PRs weren't reviewed so far.
Preventing the accidental merge with the "draft" status also isn't my favorite - it pushes the PR out of sight of codebase-related decisions to be evaluated, to which it definitely belongs.

[kerneltoast]

A kernel-level crash here is actually possible, but only when the kernel is configured with CONFIG_UBSAN_BOUNDS=y and CONFIG_UBSAN_TRAP=y.

(Note that a crash isn't possible due to CONFIG_FORTIFY_SOURCE=y, since the flexible array is never passed to a fortified function prior to request->n_channels getting set.)

The crash would occur due to the added runtime-bounds check introduced by the __counted_by annotation, which would get tripped by the array "access" out of bounds by this line: request->ssids = (void *)&request->channels[n_channels];

It's not a real array access, but the compiler nonetheless treats it as such because the code computes a pointer to the start of the ssids array in terms of an out-of-bounds access into the flexible array.

With CONFIG_UBSAN_BOUNDS=y, this only results in a warning at runtime. Building with CONFIG_UBSAN_TRAP=y on top of that changes the runtime behavior to trigger a panic instead.

That being said, since we don't have the commit that introduced the bug, I don't think we should bother picking it or the associated CVE fix.

Also worth reading is this LKML thread on how poorly the __counted_by checks worked out: https://lore.kernel.org/all/20250714142130.9b0bbb7e1f07.I09112ccde72d445e11348fc2bef68942cb2ffc94@changeid/

I feel bad for Johannes 🙁

[pvts-mat]

@kerneltoast thanks for the very informative comment, as usual. Didn't know about the CONFIG_UBSAN_TRAP option. It's not enabled in any of the ciqlts9_2/ciqlts9_4 configs we have, however, and afaik they are the same as used by RH, so could it actually be what RH had in mind behind their "This flaw can lead to a kernel-level crash"? That would be a situation outside of their support scope.

[kerneltoast]

@kerneltoast thanks for the very informative comment, as usual. Didn't know about the CONFIG_UBSAN_TRAP option. It's not enabled in any of the ciqlts9_2/ciqlts9_4 configs we have, however, and afaik they are the same as used by RH, so could it actually be what RH had in mind behind their "This flaw can lead to a kernel-level crash"? That would be a situation outside of their support scope.

Agreed, I suspect RH wasn't thinking of CONFIG_UBSAN_TRAP since it'd be pretty unusual in the first place to ship a production kernel with UBSAN enabled. They might've been thinking of CONFIG_FORTIFY_SOURCE without actually checking source code to verify that a fortified function is used on the annotated struct, prior to setting request->n_channels.