deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-4465
Published: 2024-09-11
Description: An access control vulnerability was discovered in the Reports section due to a specific access restriction not being properly enforced for users with limited privileges.



If a logged-in user with reporting privileges learns how to create a specific application request, they might be able to make limited changes to the reporting configuration. This could result in a partial loss of data integrity. In Guardian/CMC instances with a reporting configuration, there could be limited Denial of Service (DoS) impacts, as the reports may not reach their intended destination, and there could also be limited information disclosure impacts. Furthermore, modifying the destination SMTP server for the reports could lead to the compromise of external credentials, as they might be sent to an unauthorized server. This could expand the scope of the attack.
CVSS Score: 6.0 (MEDIUM)
CWE: CWE-863, CWE-863
References: https://security.nozominetworks.com/NN-2024:2-01
CVE: CVE-2024-8306
Published: 2024-09-11
Description: CWE-269: Improper Privilege Management vulnerability exists that could cause unauthorized
access, loss of confidentiality, integrity and availability of the workstation when non-admin
authenticated user tries to perform privilege escalation by tampering with the binaries.
CVSS Score: 7.8 (HIGH)
CWE: CWE-269
References: https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2024-254-01&p_enDocType=Security+and+Safety+Notice&p_File_Name=SEVD-2024-254-01.pdf
CVE: CVE-2024-39378
Published: 2024-09-11
Description: Audition versions 24.4.1, 23.6.6 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://helpx.adobe.com/security/products/audition/apsb24-54.html
CVE: CVE-2024-41868
Published: 2024-09-11
Description: Audition versions 24.4.1, 23.6.6 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://helpx.adobe.com/security/products/audition/apsb24-54.html
CVE: CVE-2024-44466
Published: 2024-09-11
Description: COMFAST CF-XR11 V2.7.2 has a command injection vulnerability in function sub_424CB4. Attackers can send POST request messages to /usr/bin/webmgnt and inject commands into parameter iface.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-77, CWE-94
References: https://github.com/CurryRaid/iot_vul/tree/main/comfast
CVE: CVE-2024-44851
Published: 2024-09-11
Description: A stored cross-site scripting (XSS) vulnerability in the Discussion section of Perfex CRM v1.1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Content parameter.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://gist.github.com/0xashfaq/e44a6dece3be498241aebcfaa046e634; https://github.com/0xashfaq/File-Sharing-module-for-Perfex-CRM-XSS/
CVE: CVE-2024-45009
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only decrement add_addr_accepted for MPJ req

Adding the following warning ...

  WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)

... before decrementing the add_addr_accepted counter helped to find a
bug when running the "remove single subflow" subtest from the
mptcp_join.sh selftest.

Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the
subflow closure. Before this patch, and upon the reception of the
RM_ADDR, the other peer will then try to decrement this
add_addr_accepted. That's not correct because the attached subflows have
not been created upon the reception of an ADD_ADDR.

A way to solve that is to decrement the counter only if the attached
subflow was an MP_JOIN to a remote id that was not 0, and initiated by
the host receiving the RM_ADDR.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1c1f[PII_REDACTED]79e46741f59523e39ec9b2a9bd; https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c; https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d
CVE: CVE-2024-45010
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only mark 'subflow' endp as available

Adding the following warning ...

  WARN_ON_ONCE(msk->pm.local_addr_used == 0)

... before decrementing the local_addr_used counter helped to find a bug
when running the "remove single address" subtest from the mptcp_join.sh
selftests.

Removing a 'signal' endpoint will trigger the removal of all subflows
linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with
rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used
counter, which is wrong in this case because this counter is linked to
'subflow' endpoints, and here it is a 'signal' endpoint that is being
removed.

Now, the counter is decremented, only if the ID is being used outside
of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and
if the ID is not 0 -- local_addr_used is not taking into account these
ones. This marking of the ID as being available, and the decrement is
done no matter if a subflow using this ID is currently available,
because the subflow could have been closed before.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6; https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d; https://git.kernel.org/stable/c/7fdc870d[PII_REDACTED]8a44c569f20f50940e7d4f
CVE: CVE-2024-45011
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

char: xillybus: Check USB endpoints when probing device

Ensure, as the driver probes the device, that all endpoints that the
driver may attempt to access exist and are of the correct type.

All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at
address 1. This is verified in xillyusb_setup_base_eps().

On top of that, a XillyUSB device may have additional Bulk OUT
endpoints. The information about these endpoints' addresses is deduced
from a data structure (the IDT) that the driver fetches from the device
while probing it. These endpoints are checked in setup_channels().

A XillyUSB device never has more than one IN endpoint, as all data
towards the host is multiplexed in this single Bulk IN endpoint. This is
why setup_channels() only checks OUT endpoints.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731; https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594; https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda
CVE: CVE-2024-45012
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

nouveau/firmware: use dma non-coherent allocator

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:

kernel BUG at include/linux/scatterlist.h:187!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30
Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019
RIP: 0010:sg_init_one+0x85/0xa0
Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54
24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b
0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00
RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: ffffa77600d87000 RCX:[PII_REDACTED]00002b
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffffa77680d87000
RBP:[PII_REDACTED]00e000 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffff98f4c46aa508 R11: [PII_REDACTED] R12: ffff98f4c46aa508
R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018
FS:  00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f22cb9a4520 CR3:[PII_REDACTED]3ba000 CR4:[PII_REDACTED]3506f0
Call Trace:
 <TASK>
 ? die+0x36/0x90
 ? do_trap+0xdd/0x100
 ? sg_init_one+0x85/0xa0
 ? do_error_trap+0x65/0x80
 ? sg_init_one+0x85/0xa0
 ? exc_invalid_op+0x50/0x70
 ? sg_init_one+0x85/0xa0
 ? asm_exc_invalid_op+0x1a/0x20
 ? sg_init_one+0x85/0xa0
 nvkm_firmware_ctor+0x14a/0x250 [nouveau]
 nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]
 ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]
 r535_gsp_oneinit+0xb3/0x15f0 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? nvkm_udevice_new+0x95/0x140 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? ktime_get+0x47/0xb0

Fix this by using the non-coherent allocator instead, I think there
might be a better answer to this, but it involve ripping up some of
APIs using sg lists.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/57ca481fca97ca4553e8c85d6a94baf4cb40c40e; https://git.kernel.org/stable/c/9b340aeb26d50e9a9ec99599e2a39b035fac978e; https://git.kernel.org/stable/c/cc29c5546c6a373648363ac49781f1d74b530707
CVE: CVE-2024-45013
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme: move stopping keep-alive into nvme_uninit_ctrl()

Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup")
moves starting keep-alive from nvme_start_ctrl() into
nvme_init_ctrl_finish(), but don't move stopping keep-alive into
nvme_uninit_ctrl(), so keep-alive work can be started and keep pending
after failing to start controller, finally use-after-free is triggered if
nvme host driver is unloaded.

This patch fixes kernel panic when running nvme/004 in case that connection
failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl().

This way is reasonable because keep-alive is now started in
nvme_init_ctrl_finish().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4101af98ab573554c4225e328d506fec2a74bc54; https://git.kernel.org/stable/c/a54a93d0e3599b[PII_REDACTED]4e15418ac551a14c
CVE: CVE-2024-45014
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/boot: Avoid possible physmem_info segment corruption

When physical memory for the kernel image is allocated it does not
consider extra memory required for offsetting the image start to
match it with the lower 20 bits of KASLR virtual base address. That
might lead to kernel access beyond its memory range.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/a944cba5d57687b747023c3bc074fcf9c790f7df; https://git.kernel.org/stable/c/d7fd2941ae9a67423d1c7bee985f240e4686634f
CVE: CVE-2024-45015
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()

For cases where the crtc's connectors_changed was set without enable/active
getting toggled , there is an atomic_enable() call followed by an
atomic_disable() but without an atomic_mode_set().

This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in
the atomic_enable() as the dpu_encoder's connector was cleared in the
atomic_disable() but not re-assigned as there was no atomic_mode_set() call.

Fix the NULL ptr access by moving the assignment for atomic_enable() and also
use drm_atomic_get_new_connector_for_encoder() to get the connector from
the atomic_state.

Patchwork: https://patchwork.freedesktop.org/patch/606729/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3bacf814b6a61cc683c68465f175ebd938f09c52; https://git.kernel.org/stable/c/3fb61718bcbe309279205d1cc275a6435611dc77; https://git.kernel.org/stable/c/aedf02e46eb549dac8db4821a6b9f0c6bf6e3990
CVE: CVE-2024-45016
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

netem: fix return value if duplicate enqueue fails

There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.

This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.

There are two ways for the bug happen:

- If the duplicated packet is dropped by rootq->enqueue() and then
  the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc
  and the original packet is dropped.

In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0486d31dd8198e22b63a4730244b38fffce6d469; https://git.kernel.org/stable/c/52d99a69f3d556c6426048c9d481b912205919d8; https://git.kernel.org/stable/c/577d6c0619467fe90f7e8e57e45cb5bd9d936014
CVE: CVE-2024-45018
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: initialise extack before use

Fix missing initialisation of extack in flow offload.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-665
References: https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1; https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7; https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78
CVE: CVE-2024-45019
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Take state lock during tx timeout reporter

mlx5e_safe_reopen_channels() requires the state lock taken. The
referenced changed in the Fixes tag removed the lock to fix another
issue. This patch adds it back but at a later point (when calling
mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the
Fixes tag.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/03d3734bd692affe4d0e9c9d638f491aaf37411b; https://git.kernel.org/stable/c/8e57e66ecbdd2fddc9fbf3e984b1c523b70e9809; https://git.kernel.org/stable/c/b3b9a87adee97854bcd71057901d[PII_REDACTED]7e
CVE: CVE-2024-45020
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a kernel verifier crash in stacksafe()

Daniel Hodges reported a kernel verifier crash when playing with sched-ext.
Further investigation shows that the crash is due to invalid memory access
in stacksafe(). More specifically, it is the following code:

    if (exact != NOT_EXACT &&
        old->stack[spi].slot_type[i % BPF_REG_SIZE] !=
        cur->stack[spi].slot_type[i % BPF_REG_SIZE])
            return false;

The 'i' iterates old->allocated_stack.
If cur->allocated_stack < old->allocated_stack the out-of-bound
access will happen.

To fix the issue add 'i >= cur->allocated_stack' check such that if
the condition is true, stacksafe() should fail. Otherwise,
cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/6e3987ac310c74bb4dd6a2fa8e46702fe505fb2b; https://git.kernel.org/stable/c/7cad3174cc79519bf5f6c[PII_REDACTED]416822c08; https://git.kernel.org/stable/c/bed2eb964c70b780fb55925892a74f26cb590b25
CVE: CVE-2024-45021
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

memcg_write_event_control(): fix a user-triggerable oops

we are *not* guaranteed that anything past the terminating NUL
is mapped (let alone initialized with anything sane).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/046667c4d3196938e992fba0dfcde570aa85cd0e; https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227; https://git.kernel.org/stable/c/1b37ec85ad95b[PII_REDACTED]58c6018cd9d92cca8
CVE: CVE-2024-45022
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

The __vmap_pages_range_noflush() assumes its argument pages** contains
pages with the same page shift.  However, since commit e9c3cda4d86e ("mm,
vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags includes
__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation
failed for high order, the pages** may contain two different page shifts
(high order and order-0).  This could lead __vmap_pages_range_noflush() to
perform incorrect mappings, potentially resulting in memory corruption.

Users might encounter this as follows (vmap_allow_huge = true, 2M is for
PMD_SIZE):

kvmalloc(2M, __GFP_NOFAIL|GFP_X)
    __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)
        vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0
            vmap_pages_range()
                vmap_pages_range_noflush()
                    __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens

We can remove the fallback code because if a high-order allocation fails,
__vmalloc_node_range_noprof() will retry with order-0.  Therefore, it is
unnecessary to fallback to order-0 here.  Therefore, fix this by removing
the fallback code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/61ebe5a747da649057c37be1c37eb934b4af79ca; https://git.kernel.org/stable/c/c91618816f4d21fc574d7577a37722adcd4075b2; https://git.kernel.org/stable/c/de7bad86345c43cd040ed43e20d9fad78a3ee59f
CVE: CVE-2024-45023
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid1: Fix data corruption for degraded array with slow disk

read_balance() will avoid reading from slow disks as much as possible,
however, if valid data only lands in slow disks, and a new normal disk
is still in recovery, unrecovered data can be read:

raid1_read_request
 read_balance
  raid1_should_read_first
  -> return false
  choose_best_rdev
  -> normal disk is not recovered, return -1
  choose_bb_rdev
  -> missing the checking of recovery, return the normal disk
 -> read unrecovered data

Root cause is that the checking of recovery is missing in
choose_bb_rdev(). Hence add such checking to fix the problem.

Also fix similar problem in choose_slow_rdev().
CVSS Score: 7.1 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/2febf5fdbf5d9a52ddc3e986971c8609b1582d67; https://git.kernel.org/stable/c/c916ca35308d3187c9928664f9be249b22a3a701
CVE: CVE-2024-45025
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
the rest with zeroes.  What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear.  Otherwise we are risking garbage from the last word
we'd copied.

For most of the callers that is true - expand_fdtable() has
count equal to old->max_fds, so there's no open descriptors
past count, let alone fully occupied words in ->open_fds[],
which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds.  In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.

Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in ->full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
	* descriptor table being currently shared
	* 'to' being above the current capacity of descriptor table
	* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.

* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff; https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058; https://git.kernel.org/stable/c/9a2fa[PII_REDACTED]b6c66bdaf291f591e1170123a
CVE: CVE-2024-45026
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be
formatted on demand during usual IO processing.

The dasd_ese_needs_format function checks for error codes that signal
the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases
leading to transport of insufficient data also have this flag set.
This might lead to data corruption in certain error cases for example
during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by
explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid
ESE handling case.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246; https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8; https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc
CVE: CVE-2024-45027
Published: 2024-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()

If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop
up the damage. If it fails early enough, before xhci->interrupters
is allocated but after xhci->max_interrupters has been set, which
happens in most (all?) cases, things get uglier, as xhci_mem_cleanup()
unconditionally derefences xhci->interrupters. With prejudice.

Gate the interrupt freeing loop with a check on xhci->interrupters
being non-NULL.

Found while debugging a DMA allocation issue that led the XHCI driver
on this exact path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/3efb29f6a78d4746f958c1ab6cd7981c5762f03b; https://git.kernel.org/stable/c/770cacc75b0091ece17349195d72133912c1ca7c; https://git.kernel.org/stable/c/dcdb52d948f3a17ccd3fce757d9bd981d7c32039