deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-42126
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.

nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.

Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
percpu allocation is from the embedded first chunk. However with
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
allocation can come from the vmalloc area.

With kernel command line "percpu_alloc=page" we can force percpu allocation
to come from vmalloc area and can see kernel crash in machine_check_early:

[    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
[    1.215717] LR [c[PII_REDACTED]461a0] machine_check_early+0xf0/0x2c0
[    1.215719] --- interrupt: 200
[    1.215720] [c000000fffd73180] [[PII_REDACTED]] 0x0 (unreliable)
[    1.215722] [c000000fffd731b0] [[PII_REDACTED]] 0x0
[    1.215724] [c000000fffd73210] [c[PII_REDACTED]08364] machine_check_early_common+0x134/0x1f8

Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
first chunk is not embedded.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0db880fc865ffb522141ced4bfa66c12ab1fbb70; https://git.kernel.org/stable/c/0f37946c62c48a907625348cbc720a7a0c547d1e; https://git.kernel.org/stable/c/2c78c9411e685dbc9eac8c2845111b03501975b8
CVE: CVE-2024-42127
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/lima: fix shared irq handling on driver remove

lima uses a shared interrupt, so the interrupt handlers must be prepared
to be called at any time. At driver removal time, the clocks are
disabled early and the interrupts stay registered until the very end of
the remove process due to the devm usage.
This is potentially a bug as the interrupts access device registers
which assumes clocks are enabled. A crash can be triggered by removing
the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.
This patch frees the interrupts at each lima device finishing callback
so that the handlers are already unregistered by the time we fully
disable clocks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770; https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9; https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13
CVE: CVE-2024-42128
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

leds: an30259a: Use devm_mutex_init() for mutex initialization

In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3ead19aa341de89a8c3d88a091d8093ebea622e8; https://git.kernel.org/stable/c/9dba44460bfca657ca43f03ea9bafa4f9f7dd077; https://git.kernel.org/stable/c/c382e2e3eccb6b7ca8c7aff5092c1668428e7de6
CVE: CVE-2024-42129
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

leds: mlxreg: Use devm_mutex_init() for mutex initialization

In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/172ffd26a5af13e951d0e82df7cfc5a95b04fa80; https://git.kernel.org/stable/c/3b62888307ae44b68512d3f7735c26a4c8e45b51; https://git.kernel.org/stable/c/618c6ce83471ab4f7ac744d27b9d03af173bc141
CVE: CVE-2024-42130
Published: 2024-07-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-42131
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits).  If limits end up being larger, we will hit overflows,
possible divisions by 0 etc.  Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway.  For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits.  For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc.  So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.

This is root-only triggerable problem which occurs when the operator
sets dirty limits to >16 TB.
CVSS Score: 4.4 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff; https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2; https://git.kernel.org/stable/c/4d3817b64eda07491bdd86a234629fe0764fb42a
CVE: CVE-2024-42132
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX

Syzbot hit warning in hci_conn_del() caused by freeing handle that was
not allocated using ida allocator.

This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by
hci_le_big_sync_established_evt(), which makes code think it's unset
connection.

Add same check for handle upper bound as in hci_conn_set_handle() to
prevent warning.
CVSS Score: 7.1 (HIGH)
CWE: CWE-763
References: https://git.kernel.org/stable/c/1cc18c2ab2e8c54c355ea7c0423a636e415a0c23; https://git.kernel.org/stable/c/4970e48f83dbd21d2a6a7cdaaafc2a71f7f45dc4; https://git.kernel.org/stable/c/d311036696fed778301d08a71a4bef737b86d8c5
CVE: CVE-2024-42133
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Ignore too large handle values in BIG

hci_le_big_sync_established_evt is necessary to filter out cases where the
handle value is belonging to ida id range, otherwise ida will be erroneously
released in hci_conn_cleanup.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/015d79c96d62cd8a4a359fcf5be40d58088c936b; https://git.kernel.org/stable/c/38263088b845abeeeb98dda5b87c0de3063b6dbb; https://git.kernel.org/stable/c/dad0003ccc68457baf005a6ed75b4d321463fe3d
CVE: CVE-2024-42134
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-pci: Check if is_avq is NULL

[bug]
In the virtio_pci_common.c function vp_del_vqs, vp_dev->is_avq is involved
to determine whether it is admin virtqueue, but this function vp_dev->is_avq
 may be empty. For installations, virtio_pci_legacy does not assign a value
 to vp_dev->is_avq.

[fix]
Check whether it is vp_dev->is_avq before use.

[test]
Test with virsh Attach device
Before this patch, the following command would crash the guest system

After applying the patch, everything seems to be working fine.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106; https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d[PII_REDACTED]8; https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106
CVE: CVE-2024-42135
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost_task: Handle SIGKILL by flushing work and exiting

Instead of lingering until the device is closed, this has us handle
SIGKILL by:

1. marking the worker as killed so we no longer try to use it with
   new virtqueues and new flush operations.
2. setting the virtqueue to worker mapping so no new works are queued.
3. running all the exiting works.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af; https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233; https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4
CVE: CVE-2024-42136
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

cdrom: rearrange last_media_change check to avoid unintentional overflow

When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:

[  366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33
[  366.021089] [PII_REDACTED]854775808 - 346321 cannot be represented in type '__s64' (aka 'long long')
[  366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO
[  366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[  366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  366.027518] Call Trace:
[  366.027523]  <TASK>
[  366.027533]  dump_stack_lvl+0x93/0xd0
[  366.027899]  handle_overflow+0x171/0x1b0
[  366.038787] ata1.00: invalid multi_count 32 ignored
[  366.043924]  cdrom_ioctl+0x2c3f/0x2d10
[  366.063932]  ? __pm_runtime_resume+0xe6/0x130
[  366.071923]  sr_block_ioctl+0x15d/0x1d0
[  366.074624]  ? __pfx_sr_block_ioctl+0x10/0x10
[  366.077642]  blkdev_ioctl+0x419/0x500
[  366.080231]  ? __pfx_blkdev_ioctl+0x10/0x10
...

Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the
kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
sanitizer").

Let's rearrange the check to not perform any arithmetic, thus not
tripping the sanitizer.
CVSS Score: 7.8 (HIGH)
CWE: CWE-190
References: https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b; https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3; https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c
CVE: CVE-2024-42137
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
serdev") will cause below regression issue:

BT can't be enabled after below steps:
cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
if property enable-gpios is not configured within DT|ACPI for QCA6390.

The commit is to fix a use-after-free issue within qca_serdev_shutdown()
by adding condition to avoid the serdev is flushed or wrote after closed
but also introduces this regression issue regarding above steps since the
VSC is not sent to reset controller during warm reboot.

Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
once BT was ever enabled, and the use-after-free issue is also fixed by
this change since the serdev is still opened before it is flushed or wrote.

Verified by the reported machine Dell XPS 13 9310 laptop over below two
kernel commits:
commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
implementation for QCA") of bluetooth-next tree.
commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
implementation for QCA") of linus mainline tree.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/215a26c2404fa34625c725d446967fa328a703eb; https://git.kernel.org/stable/c/4ca6013cd18e58ac1044908c40d4006a92093a11; https://git.kernel.org/stable/c/88e72239ead9814b886db54fc4ee39ef3c2b8f26
CVE: CVE-2024-42138
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file

In case of invalid INI file mlxsw_linecard_types_init() deallocates memory
but doesn't reset pointer to NULL and returns 0. In case of any error
occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init()
calls mlxsw_linecard_types_fini() which performs memory deallocation again.

Add pointer reset to NULL.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/8ce34dccbe8fa7d2ef86f2d8e7db2a9b67cabfc3; https://git.kernel.org/stable/c/9af7437669b72f804fc4269f487528dbbed142a2; https://git.kernel.org/stable/c/ab557f5cd993a3201b09593633d04b891263d5c0
CVE: CVE-2024-42139
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Fix improper extts handling

Extts events are disabled and enabled by the application ts2phc.
However, in case where the driver is removed when the application is
running, a specific extts event remains enabled and can cause a kernel
crash.
As a side effect, when the driver is reloaded and application is started
again, remaining extts event for the channel from a previous run will
keep firing and the message "extts on unexpected channel" might be
printed to the user.

To avoid that, extts events shall be disabled when PTP is released.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc; https://git.kernel.org/stable/c/9f69b31ae9e25dec27ad31fbc64dd99af16ee3d3; https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc
CVE: CVE-2024-42140
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: kexec: Avoid deadlock in kexec crash path

If the kexec crash code is called in the interrupt context, the
machine_kexec_mask_interrupts() function will trigger a deadlock while
trying to acquire the irqdesc spinlock and then deactivate irqchip in
irq_set_irqchip_state() function.

Unlike arm64, riscv only requires irq_eoi handler to complete EOI and
keeping irq_set_irqchip_state() will only leave this possible deadlock
without any use. So we simply remove it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/484dd545271d02d1571e1c6b62ea7df9dbe5e692; https://git.kernel.org/stable/c/653deee48a4682ea17a05b96fb6842795ab5943c; https://git.kernel.org/stable/c/7692c9b6baacdee378435f58f19baf0eb69e4155
CVE: CVE-2024-42141
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Check socket flag instead of hcon

This fixes the following Smatch static checker warning:

net/bluetooth/iso.c:1364 iso_sock_recvmsg()
error: we previously assumed 'pi->conn->hcon' could be null (line 1359)

net/bluetooth/iso.c
1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,
1348                             size_t len, int flags)
1349 {
1350         struct sock *sk = sock->sk;
1351         struct iso_pinfo *pi = iso_pi(sk);
1352
1353         BT_DBG("sk %p", sk);
1354
1355         if (test_and_clear_bit(BT_SK_DEFER_SETUP,
                                      &bt_sk(sk)->flags)) {
1356                 lock_sock(sk);
1357                 switch (sk->sk_state) {
1358                 case BT_CONNECT2:
1359                         if (pi->conn->hcon &&
                                     ^^^^^^^^^^^^^^ If ->hcon is NULL

1360                             test_bit(HCI_CONN_PA_SYNC,
                                         &pi->conn->hcon->flags)) {
1361                                 iso_conn_big_sync(sk);
1362                                 sk->sk_state = BT_LISTEN;
1363                         } else {
--> 1364                         iso_conn_defer_accept(pi->conn->hcon);
                                                       ^^^^^^^^^^^^^^
                                                       then we're toast

1365                                 sk->sk_state = BT_CONFIG;
1366                         }
1367                         release_sock(sk);
1368                         return 0;
1369                 case BT_CONNECTED:
1370                         if (test_bit(BT_SK_PA_SYNC,
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]64a21c67e690ef14698fd71857cb11; https://git.kernel.org/stable/c/33fabef489169c6db87843ef23351ed0d5e51ad8; https://git.kernel.org/stable/c/596b6f081336e77764ca35cfeab66d0fcdbe544e
CVE: CVE-2024-42142
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: E-switch, Create ingress ACL when needed

Currently, ingress acl is used for three features. It is created only
when vport metadata match and prio tag are enabled. But active-backup
lag mode also uses it. It is independent of vport metadata match and
prio tag. And vport metadata match can be disabled using the
following devlink command:

 # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \
	value false cmode runtime

If ingress acl is not created, will hit panic when creating drop rule
for active-backup lag mode. If always create it, there will be about
5% performance degradation.

Fix it by creating ingress acl when needed. If esw_port_metadata is
true, ingress acl exists, then create drop rule using existing
ingress acl. If esw_port_metadata is false, create ingress acl and
then create drop rule.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3e3551f8702978cd2221d2614ca6d6727e785324; https://git.kernel.org/stable/c/83bc1a129f7fd0d7d05036ceb7ee69102624e320; https://git.kernel.org/stable/c/b20c2fb45470d0c7a603613c9cfa5d45720e17f2
CVE: CVE-2024-42143
Published: 2024-07-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-42144
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data

Verify that lvts_data is not NULL before using it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9; https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d; https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886
CVE: CVE-2024-42145
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/core: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.

To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb; https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f; https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa
CVE: CVE-2024-42146
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf

Any kunit doing any memory access should get their own runtime_pm
outer references since they don't use the standard driver API
entries. In special this dma_buf from the same driver.

Found by pre-merge CI on adding WARN calls for unprotected
inner callers:

<6> [318.639739]     # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver
<4> [318.639957] ------------[ cut here ]------------
<4> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection
<4> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0888d15ea45ba8ef4508edd1123ea5ad95b58994; https://git.kernel.org/stable/c/f9116f658a6217b101e3b4e89f845775b6fb05d9; https://git.kernel.org/stable/c/0888d15ea45ba8ef4508edd1123ea5ad95b58994
CVE: CVE-2024-42147
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/debugfs - Fix debugfs uninit process issue

During the zip probe process, the debugfs failure does not stop
the probe. When debugfs initialization fails, jumping to the
error branch will also release regs, in addition to its own
rollback operation.

As a result, it may be released repeatedly during the regs
uninit process. Therefore, the null check needs to be added to
the regs uninit process.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e; https://git.kernel.org/stable/c/8be[PII_REDACTED]e8d27c4f1d4537b5e1b99ed7739; https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3
CVE: CVE-2024-42149
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: don't misleadingly warn during thaw operations

The block device may have been frozen before it was claimed by a
filesystem. Concurrently another process might try to mount that
frozen block device and has temporarily claimed the block device for
that purpose causing a concurrent fs_bdev_thaw() to end up here. The
mounter is already about to abort mounting because they still saw an
elevanted bdev->bd_fsfreeze_count so get_bdev_super() will return
NULL in that case.

For example, P1 calls dm_suspend() which calls into bdev_freeze() before
the block device has been claimed by the filesystem. This brings
bdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is
required.

Now P2 tries to mount that frozen block device. It claims it and checks
bdev->bd_fsfreeze_count. As it's elevated it aborts mounting.

In the meantime P3 called dm_resume(). P3 sees that the block device is
already claimed by a filesystem and calls into fs_bdev_thaw().

P3 takes a passive reference and realizes that the filesystem isn't
ready yet. P3 puts itself to sleep to wait for the filesystem to become
ready.

P2 now puts the last active reference to the filesystem and marks it as
dying. P3 gets woken, sees that the filesystem is dying and
get_bdev_super() fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/25b1e3906e050d452427bc51620bb7f0a591373a; https://git.kernel.org/stable/c/2ae4db5647d807efb6a87c09efaa6d1db9c905d7; https://git.kernel.org/stable/c/25b1e3906e050d452427bc51620bb7f0a591373a
CVE: CVE-2024-42150
Published: 2024-07-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net: txgbe: remove separate irq request for MSI and INTx

When using MSI or INTx interrupts, request_irq() for pdev->irq will
conflict with request_threaded_irq() for txgbe->misc.irq, to cause
system crash. So remove txgbe_request_irq() for MSI/INTx case, and
rename txgbe_request_msix_irqs() since it only request for queue irqs.

Add wx->misc_irq_domain to determine whether the driver creates an IRQ
domain and threaded request the IRQs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/850103ebe6b062ee0ab0f6670205f861acc76ace; https://git.kernel.org/stable/c/bd07a98178462e7a02ed2bf7dec90a00944c1da5; https://git.kernel.org/stable/c/850103ebe6b062ee0ab0f6670205f861acc76ace