deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-27415
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: bridge: confirm multicast packets before passing them up the stack

conntrack nf_confirm logic cannot handle cloned skbs referencing
the same nf_conn entry, which will happen for multicast (broadcast)
frames on bridges.

 Example:
    macvlan0
       |
      br0
     /  \
  ethX    ethY

 ethX (or Y) receives a L2 multicast or broadcast packet containing
 an IP packet, flow is not yet in conntrack table.

 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
    -> skb->_nfct now references a unconfirmed entry
 2. skb is broad/mcast packet. bridge now passes clones out on each bridge
    interface.
 3. skb gets passed up the stack.
 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
    and schedules a work queue to send them out on the lower devices.

    The clone skb->_nfct is not a copy, it is the same entry as the
    original skb.  The macvlan rx handler then returns RX_HANDLER_PASS.
 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.

The Macvlan broadcast worker and normal confirm path will race.

This race will not happen if step 2 already confirmed a clone. In that
case later steps perform skb_clone() with skb->_nfct already confirmed (in
hash table).  This works fine.

But such confirmation won't happen when eb/ip/nftables rules dropped the
packets before they reached the nf_confirm step in postrouting.

Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
nat, so we can safely discard the nf_conn entry and let inet call
conntrack again.

This doesn't work for bridge netfilter: skb could have a nat
transformation. Also bridge nf prevents re-invocation of inet prerouting
via 'sabotage_in' hook.

Work around this problem by explicit confirmation of the entry at LOCAL_IN
time, before upper layer has a chance to clone the unconfirmed entry.

The downside is that this disables NAT and conntrack helpers.

Alternative fix would be to add locking to all code parts that deal with
unconfirmed packets, but even if that could be done in a sane way this
opens up other problems, for example:

-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5

For multicast case, only one of such conflicting mappings will be
created, conntrack only handles 1:1 NAT mappings.

Users should set create a setup that explicitly marks such traffic
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
them, ruleset might have accept rules for untracked traffic already,
so user-visible behaviour would change.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0; https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9; https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
CVE: CVE-2024-27416
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST

If we received HCI_EV_IO_CAPA_REQUEST while
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
does support SSP since otherwise this event shouldn't be generated.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f; https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259; https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
CVE: CVE-2024-27417
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()

It seems that if userspace provides a correct IFA_TARGET_NETNSID value
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
returns -EINVAL with an elevated "struct net" refcount.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb; https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a; https://git.kernel.org/stable/c/33a1b6bfef6def2068c[PII_REDACTED]024ce17053e
CVE: CVE-2024-27418
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mctp: take ownership of skb in mctp_local_output

Currently, mctp_local_output only takes ownership of skb on success, and
we may leak an skb if mctp_local_output fails in specific states; the
skb ownership isn't transferred until the actual output routing occurs.

Instead, make mctp_local_output free the skb on all error paths up to
the route action, so it always consumes the passed skb.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3; https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd; https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
CVE: CVE-2024-27419
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

netrom: Fix data-races around sysctl_net_busy_read

We need to protect the reader reading the sysctl value because the
value can be changed concurrently.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1; https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc2d60ad4; https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b
CVE: CVE-2024-27420
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27421
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27422
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27423
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27424
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27425
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27426
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27427
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27428
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27429
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27430
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-27431
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

cpumap: Zero-initialise xdp_rxq_info struct before running XDP program

When running an XDP program that is attached to a cpumap entry, we don't
initialise the xdp_rxq_info data structure being used in the xdp_buff
that backs the XDP program invocation. Tobias noticed that this leads to
random values being returned as the xdp_md->rx_queue_index value for XDP
programs running in a cpumap.

This means we're basically returning the contents of the uninitialised
memory, which is bad. Fix this by zero-initialising the rxq data
structure before running the XDP program.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5; https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95; https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd[PII_REDACTED]97
CVE: CVE-2024-5043
Published: 2024-05-17
Description: A vulnerability was found in Emlog Pro 2.3.4 and classified as critical. Affected by this issue is some unknown functionality of the file admin/setting.php. The manipulation leads to unrestricted upload. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-264740. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-434
References: https://github.com/ssteveez/emlog/blob/main/emlog%20pro%20version%202.3.4%20Admin%20side%20can%20upload%20arbitrary%20files%20and%20getshell.md; https://vuldb.com/?ctiid.264740; https://vuldb.com/?id.264740
CVE: CVE-2024-5044
Published: 2024-05-17
Description: A vulnerability was found in Emlog Pro 2.3.4. It has been classified as problematic. This affects an unknown part of the component Cookie Handler. The manipulation of the argument AuthCookie leads to improper authentication. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The identifier VDB-264741 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 3.7 (LOW)
CWE: CWE-287
References: https://github.com/ssteveez/emlog/blob/main/emlog%20pro%20version%202.3.4%20has%20session(AuthCookie)%20persistence%20and%20any%20user%20login%20vulnerability.md; https://vuldb.com/?ctiid.264741; https://vuldb.com/?id.264741
CVE: CVE-2024-5055
Published: 2024-05-17
Description: Uncontrolled resource consumption vulnerability in XAMPP Windows, versions 7.3.2 and earlier. This vulnerability exists when XAMPP attempts to process many incomplete HTTP requests, resulting in resource consumption and system crashes.
CVSS Score: 7.5 (HIGH)
CWE: CWE-400
References: https://www.incibe.es/en/incibe-cert/notices/aviso/vulnerability-uncontrolled-resource-consumption-xampp; https://www.incibe.es/en/incibe-cert/notices/aviso/vulnerability-uncontrolled-resource-consumption-xampp
CVE: CVE-2023-52659
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type

On 64-bit platforms, the pfn_to_kaddr() macro requires that the input
value is 64 bits in order to ensure that valid address bits don't get
lost when shifting that input by PAGE_SHIFT to calculate the physical
address to provide a virtual address for.

One such example is in pvalidate_pages() (used by SEV-SNP guests), where
the GFN in the struct used for page-state change requests is a 40-bit
bit-field, so attempts to pass this GFN field directly into
pfn_to_kaddr() ends up causing guest crashes when dealing with addresses
above the 1TB range due to the above.

Fix this issue with SEV-SNP guests, as well as any similar cases that
might cause issues in current/future code, by using an inline function,
instead of a macro, so that the input is implicitly cast to the
expected 64-bit input type prior to performing the shift operation.

While it might be argued that the issue is on the caller side, other
archs/macros have taken similar approaches to deal with instances like
this, such as ARM explicitly casting the input to phys_addr_t:

  e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()")

A C inline function is even better though.

[ mingo: Refined the changelog some more & added __always_inline. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/325956b0173f11e98f90462be4829a8b8b0682ce; https://git.kernel.org/stable/c/7e1471888a5e6e846e9b4d306e5327db2b58e64e; https://git.kernel.org/stable/c/814305b5c23cb815ada68d43019f39050472b25f
CVE: CVE-2023-52660
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: rkisp1: Fix IRQ handling due to shared interrupts

The driver requests the interrupts as IRQF_SHARED, so the interrupt
handlers can be called at any time. If such a call happens while the ISP
is powered down, the SoC will hang as the driver tries to access the
ISP registers.

This can be reproduced even without the platform sharing the IRQ line:
Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
hang.

Fix this by adding a new field, 'irqs_enabled', which is used to bail
out from the interrupt handler when the ISP is not operational.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63; https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee; https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587
CVE: CVE-2024-27432
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: fix PPE hanging issue

A patch to resolve an issue was found in MediaTek's GPL-licensed SDK:
In the mtk_ppe_stop() function, the PPE scan mode is not disabled before
disabling the PPE. This can potentially lead to a hang during the process
of disabling the PPE.

Without this patch, the PPE may experience a hang during the reboot test.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09a[PII_REDACTED]b7c8ee6777e507f5126bdd38c0f; https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369; https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633
CVE: CVE-2024-27433
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe()

'clk_data' is allocated with mtk_devm_alloc_clk_data(). So calling
mtk_free_clk_data() explicitly in the remove function would lead to a
double-free.

Remove the redundant call.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/a32e88f2b20259f5fe4f8eed598bbc85dc4879ed; https://git.kernel.org/stable/c/de3340533bd68a7b3d6be1841b8eb3fa6c762fe6; https://git.kernel.org/stable/c/f3633fed984f1db106ff737a0bb52fadb2d89ac7
CVE: CVE-2024-27434
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't set the MFP flag for the GTK

The firmware doesn't need the MFP flag for the GTK, it can even make the
firmware crash. in case the AP is configured with: group cipher TKIP and
MFPC. We would send the GTK with cipher = TKIP and MFP which is of course
not possible.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/40405cbb20eb6541c603e7b3d54ade0a7be9d715; https://git.kernel.org/stable/c/60f6d5fc84a9fd26528a24d8a267fc6a6698b628; https://git.kernel.org/stable/c/b4f1b0b3b91762edd19bf9d3b2e4c3a0740501f8
CVE: CVE-2024-27435
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme: fix reconnection fail due to reserved tag allocation

We found a issue on production environment while using NVMe over RDMA,
admin_q reconnect failed forever while remote target and network is ok.
After dig into it, we found it may caused by a ABBA deadlock due to tag
allocation. In my case, the tag was hold by a keep alive request
waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
request maked as idle and will not process before reset success. As
fabric_q shares tagset with admin_q, while reconnect remote target, we
need a tag for connect command, but the only one reserved tag was held
by keep alive command which waiting inside admin_q. As a result, we
failed to reconnect admin_q forever. In order to fix this issue, I
think we should keep two reserved tags for admin queue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8; https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818; https://git.kernel.org/stable/c/[PII_REDACTED]cdb49431809b4ba061903d5f592c96
CVE: CVE-2024-27436
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72; https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827; https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6
CVE: CVE-2024-35784
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix deadlock with fiemap and extent locking

While working on the patchset to remove extent locking I got a lockdep
splat with fiemap and pagefaulting with my new extent lock replacement
lock.

This deadlock exists with our normal code, we just don't have lockdep
annotations with the extent locking so we've never noticed it.

Since we're copying the fiemap extent to user space on every iteration
we have the chance of pagefaulting.  Because we hold the extent lock for
the entire range we could mkwrite into a range in the file that we have
mmap'ed.  This would deadlock with the following stack trace

[<0>] lock_extent+0x28d/0x2f0
[<0>] btrfs_page_mkwrite+0x273/0x8a0
[<0>] do_page_mkwrite+0x50/0xb0
[<0>] do_fault+0xc1/0x7b0
[<0>] __handle_mm_fault+0x2fa/0x460
[<0>] handle_mm_fault+0xa4/0x330
[<0>] do_user_addr_fault+0x1f4/0x800
[<0>] exc_page_fault+0x7c/0x1e0
[<0>] asm_exc_page_fault+0x26/0x30
[<0>] rep_movs_alternative+0x33/0x70
[<0>] _copy_to_user+0x49/0x70
[<0>] fiemap_fill_next_extent+0xc8/0x120
[<0>] emit_fiemap_extent+0x4d/0xa0
[<0>] extent_fiemap+0x7f8/0xad0
[<0>] btrfs_fiemap+0x49/0x80
[<0>] __x64_sys_ioctl+0x3e1/0xb50
[<0>] do_syscall_64+0x94/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76

I wrote an fstest to reproduce this deadlock without my replacement lock
and verified that the deadlock exists with our existing locking.

To fix this simply don't take the extent lock for the entire duration of
the fiemap.  This is safe in general because we keep track of where we
are when we're searching the tree, so if an ordered extent updates in
the middle of our fiemap call we'll still emit the correct extents
because we know what offset we were on before.

The only place we maintain the lock is searching delalloc.  Since the
delalloc stuff can change during writeback we want to lock the extent
range so we have a consistent view of delalloc at the time we're
checking to see if we need to set the delalloc flag.

With this patch applied we no longer deadlock with my testcase.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b; https://git.kernel.org/stable/c/b0ad381fa[PII_REDACTED]aed119b478b4bdafc31dd; https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
CVE: CVE-2024-35785
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

tee: optee: Fix kernel panic caused by incorrect error handling

The error path while failing to register devices on the TEE bus has a
bug leading to kernel panic as follows:

[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
[   15.406913] Mem abort info:
[   15.409722]   ESR = 0x[PII_REDACTED]000005
[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits
[   15.418814]   SET = 0, FnV = 0
[   15.421878]   EA = 0, S1PTW = 0
[   15.425031]   FSC = 0x05: level 1 translation fault
[   15.429922] Data abort info:
[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=[PII_REDACTED]
[   15.464146] Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP

Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
lead to the introduction of this bug. So fix it appropriately.
CVSS Score: 7.1 (HIGH)
CWE: CWE-754
References: https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7; https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee; https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
CVE: CVE-2024-35786
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf

If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/b466416bdd6ecbde15ce987226ea633a0268fbb1; https://git.kernel.org/stable/c/c288a61a48ddb77ec097e11ab81b81027cd4e197; https://git.kernel.org/stable/c/daf8739c3322a762ce84f240f50e0c39181a41ab
CVE: CVE-2024-35787
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

md/md-bitmap: fix incorrect usage for sb_index

Commit d7038f951828 ("md-bitmap: don't use ->index for pages backing the
bitmap file") removed page->index from bitmap code, but left wrong code
logic for clustered-md. current code never set slot offset for cluster
nodes, will sometimes cause crash in clustered env.

Call trace (partly):
 md_bitmap_file_set_bit+0x110/0x1d8 [md_mod]
 md_bitmap_startwrite+0x13c/0x240 [md_mod]
 raid1_make_request+0x6b0/0x1c08 [raid1]
 md_handle_request+0x1dc/0x368 [md_mod]
 md_submit_bio+0x80/0xf8 [md_mod]
 __submit_bio+0x178/0x300
 submit_bio_noacct_nocheck+0x11c/0x338
 submit_bio_noacct+0x134/0x614
 submit_bio+0x28/0xdc
 submit_bh_wbc+0x130/0x1cc
 submit_bh+0x1c/0x28
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da; https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240; https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31
CVE: CVE-2024-35788
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35789
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes

When moving a station out of a VLAN and deleting the VLAN afterwards, the
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
after the VLAN change.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc; https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685; https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7