deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-47739
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

padata: use integer wrap around to prevent deadlock on seq_nr overflow

When submitting more than 2^32 padata objects to padata_do_serial, the
current sorting implementation incorrectly sorts padata objects with
overflowed seq_nr, causing them to be placed before existing objects in
the reorder list. This leads to a deadlock in the serialization process
as padata_find_next cannot match padata->seq_nr and pd->processed
because the padata instance with overflowed seq_nr will be selected
next.

To fix this, we use an unsigned integer wrap around to correctly sort
padata objects in scenarios with integer overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428; https://git.kernel.org/stable/c/1bd712de96ad7167fe0d608e706cd60587579f16; https://git.kernel.org/stable/c/46c4079460f4dcaf[PII_REDACTED]58eedef4e1bc91
CVE: CVE-2024-47740
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: Require FMODE_WRITE for atomic write ioctls

The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches the inode's UID, inode_owner_or_capable() immediately returns true.

There are scenarios where LSMs want to deny a process the ability to write
particular files, even files that the FSUID of the process owns; but this
can currently partially be bypassed using atomic write ioctls in two ways:

 - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can
   truncate an inode to size 0
 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert
   changes another process concurrently made to a file

Fix it by requiring FMODE_WRITE for these operations, just like for
F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these
ioctls when intending to write into the file, that seems unlikely to break
anything.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac; https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713; https://git.kernel.org/stable/c/[PII_REDACTED]c13c2c2e5eb8773886d153c2c5121d
CVE: CVE-2024-47741
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix race setting file private on concurrent lseek using same fd

When doing concurrent lseek(2) system calls against the same file
descriptor, using multiple threads belonging to the same process, we have
a short time window where a race happens and can result in a memory leak.

The race happens like this:

1) A program opens a file descriptor for a file and then spawns two
   threads (with the pthreads library for example), lets call them
   task A and task B;

2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at
   file.c:find_desired_extent() while holding a read lock on the inode;

3) At the start of find_desired_extent(), it extracts the file's
   private_data pointer into a local variable named 'private', which has
   a value of NULL;

4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode
   in shared mode and enters file.c:find_desired_extent(), where it also
   extracts file->private_data into its local variable 'private', which
   has a NULL value;

5) Because it saw a NULL file private, task A allocates a private
   structure and assigns to the file structure;

6) Task B also saw a NULL file private so it also allocates its own file
   private and then assigns it to the same file structure, since both
   tasks are using the same file descriptor.

   At this point we leak the private structure allocated by task A.

Besides the memory leak, there's also the detail that both tasks end up
using the same cached state record in the private structure (struct
btrfs_file_private::llseek_cached_state), which can result in a
use-after-free problem since one task can free it while the other is
still using it (only one task took a reference count on it). Also, sharing
the cached state is not a good idea since it could result in incorrect
results in the future - right now it should not be a problem because it
end ups being used only in extent-io-tree.c:count_range_bits() where we do
range validation before using the cached state.

Fix this by protecting the private assignment and check of a file while
holding the inode's spinlock and keep track of the task that allocated
the private, so that it's used only by that task in order to prevent
user-after-free issues with the cached state record as well as potentially
using it incorrectly in the future.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362
References: https://git.kernel.org/stable/c/33d1310d4496e904123dab9c28b2d8d2c1800f97; https://git.kernel.org/stable/c/7ee85f5515e86a4e2a2f[PII_REDACTED]0733912bad; https://git.kernel.org/stable/c/a412ca489ac27b9d0e603499315b7139c948130d
CVE: CVE-2024-47742
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Block path traversal

Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.

However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:

 - lpfc_sli4_request_firmware_update() seems to construct the firmware
   filename from "ModelName", a string that was previously parsed out of
   some descriptor ("Vital Product Data") in lpfc_fill_vpd()
 - nfp_net_fw_find() seems to construct a firmware filename from a model
   name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
   think parses some descriptor that was read from the device.
   (But this case likely isn't exploitable because the format string looks
   like "netronome/nic_%s", and there shouldn't be any *folders* starting
   with "netronome/nic_". The previous case was different because there,
   the "%s" is *at the start* of the format string.)
 - module_flash_fw_schedule() is reachable from the
   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
   enough to pass the privilege check), and takes a userspace-provided
   firmware name.
   (But I think to reach this case, you need to have CAP_NET_ADMIN over a
   network namespace that a special kind of ethernet device is mapped into,
   so I think this is not a viable attack path in practice.)

Fix it by rejecting any firmware names containing ".." path components.

For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously.
CVSS Score: 7.8 (HIGH)
CWE: CWE-22
References: https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb; https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251; https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec
CVE: CVE-2024-47743
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: prevent NULL pointer dereference in find_asymmetric_key()

In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2}
arguments, the kernel will first emit WARN but then have an oops
because id_2 gets dereferenced anyway.

Add the missing id_2 check and move WARN_ON() to the final else branch
to avoid duplicate NULL checks.

Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0d3b0706ada15c333e6f9faf19590ff715e45d1e; https://git.kernel.org/stable/c/13b5b401ead95b5d8266f64904086c55b6024900; https://git.kernel.org/stable/c/3322fa8f2aa40b0b3651034cd541647a600cc6c0
CVE: CVE-2024-47745
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: call the security_mmap_file() LSM hook in remap_file_pages()

The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.

So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].

The PoC:

$ cat > test.c

int main(void) {
	size_t pagesz = sysconf(_SC_PAGE_SIZE);
	int mfd = syscall(SYS_memfd_create, "test", 0);
	const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
		MAP_SHARED, mfd, 0);
	unsigned int old = syscall(SYS_personality, 0xffffffff);
	syscall(SYS_personality, READ_IMPLIES_EXEC | old);
	syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
	syscall(SYS_personality, old);
	// show the RWX page exists even if W^X policy is enforced
	int fd = open("/proc/self/maps", O_RDONLY);
	unsigned char buf2[1024];
	while (1) {
		int ret = read(fd, buf2, 1024);
		if (ret <= 0) break;
		write(1, buf2, ret);
	}
	close(fd);
}

$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]
CVSS Score: 7.8 (HIGH)
CWE: CWE-670
References: https://git.kernel.org/stable/c/0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1; https://git.kernel.org/stable/c/3393fddbfa947c8e1fdcc[PII_REDACTED]ffffd8b89; https://git.kernel.org/stable/c/49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178
CVE: CVE-2024-47746
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set

This may be a typo. The comment has said shared locks are
not allowed when this bit is set. If using shared lock, the
wait in `fuse_file_cached_io_open` may be forever.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2f3d8ff457982f4055fe8f7bf19d3821ba22c376; https://git.kernel.org/stable/c/4e181761ffec67307157a7e8a78d58ee4130cf00; https://git.kernel.org/stable/c/fa4890bd8237e5a1e7428acd7328729db2703b23
CVE: CVE-2024-47747
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition

In the ether3_probe function, a timer is initialized with a callback
function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is
started, there is a risk of a race condition if the module or device
is removed, triggering the ether3_remove function to perform cleanup.
The sequence of operations that may lead to a UAF bug is as follows:

CPU0                                    CPU1

                      |  ether3_ledoff
ether3_remove         |
  free_netdev(dev);   |
  put_devic           |
  kfree(dev);         |
 |  ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2);
                      | // use dev

Fix it by ensuring that the timer is canceled before proceeding with
the cleanup in ether3_remove.
CVSS Score: 7.0 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1c57d61a43293252ad732007c7070fdb112545fd; https://git.kernel.org/stable/c/25d559ed2beec9b[PII_REDACTED]0dac46d1ad92eba; https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353
CVE: CVE-2024-47748
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost_vdpa: assign irq bypass producer token correctly

We used to call irq_bypass_unregister_producer() in
vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the
token pointer is still valid or not.

Actually, we use the eventfd_ctx as the token so the life cycle of the
token should be bound to the VHOST_SET_VRING_CALL instead of
vhost_vdpa_setup_vq_irq() which could be called by set_status().

Fixing this by setting up irq bypass producer's token when handling
VHOST_SET_VRING_CALL and un-registering the producer before calling
vhost_vring_ioctl() to prevent a possible use after free as eventfd
could have been released in vhost_vring_ioctl(). And such registering
and unregistering will only be done if DRIVER_OK is set.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/02e9e9366fefe461719da5d173385b6685f70319; https://git.kernel.org/stable/c/0c170b1e918b9afac25e2bbd01eaa2bfc0ece8c0; https://git.kernel.org/stable/c/7cf2fb51175cafe01df8c43fa15a06194a59c6e2
CVE: CVE-2024-47749
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Added NULL check for lookup_atid

The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0d50ae281a1712b9b2ca72830a96b8f11882358d; https://git.kernel.org/stable/c/39cb9f39913566ec[PII_REDACTED]f3e8123ad1aee1; https://git.kernel.org/stable/c/4e1fe68d695af367506ea3c794c5969630f21697
CVE: CVE-2024-47750
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08

Currently rsv_qp is freed before ib_unregister_device() is called
on HIP08. During the time interval, users can still dereg MR and
rsv_qp will be used in this process, leading to a UAF. Move the
release of rsv_qp after calling ib_unregister_device() to fix it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2ccf1c75d39949d8ea043d04a2e92d7100ea723d; https://git.kernel.org/stable/c/[PII_REDACTED]1c2ebe7faf82536c47eb0c967e3425; https://git.kernel.org/stable/c/d2d9c[PII_REDACTED]da6e887f451dd248cfeffca33
CVE: CVE-2024-47751
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()

Within kirin_pcie_parse_port(), the pcie->num_slots is compared to
pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead
to an overflow.

Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move
pcie->num_slots increment below the if-statement to avoid out-of-bounds
array access.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[kwilczynski: commit log]
CVSS Score: 7.8 (HIGH)
CWE: CWE-120
References: https://git.kernel.org/stable/c/6dcc5b49d6607a741a14122bf3105f3ac50d259e; https://git.kernel.org/stable/c/95248d7497bcbfe7deed4805469c6ff6ddd7f9d1; https://git.kernel.org/stable/c/a5f795f9412854df28e66679c5e6b68b0b79c229
CVE: CVE-2024-47752
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix H264 stateless decoder smatch warning

Fix a smatch static checker warning on vdec_h264_req_if.c.
Which leads to a kernel crash when fb is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/18181b0c1c5bd43846e5e0ae3d61a4a1adceab03; https://git.kernel.org/stable/c/7878d3a385efab560dce793b595447867fb163f2; https://git.kernel.org/stable/c/790d1848fac5ac3b1c474f66162598ab07a20c21
CVE: CVE-2024-47753
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning

Fix a smatch static checker warning on vdec_vp8_req_if.c.
Which leads to a kernel crash when fb is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3167aa42941b68405a092df114453ef0f1b09c2c; https://git.kernel.org/stable/c/35cc704622b3a9bc02a4755d5ba80238eee3cdc2; https://git.kernel.org/stable/c/4e0713c79cf5d0b549fa855e230ade1ff83c27d7
CVE: CVE-2024-47754
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning

Fix a smatch static checker warning on vdec_h264_req_multi_if.c.
Which leads to a kernel crash when fb is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/301f[PII_REDACTED]388c20521a1a641067647ab31c; https://git.kernel.org/stable/c/47b3b97930913ca74a595cc12bdbb650259afc6e; https://git.kernel.org/stable/c/588bcce9e64cc5138858ab562268eb3943c5b06c
CVE: CVE-2024-47755
Published: 2024-10-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-47756
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: keystone: Fix if-statement expression in ks_pcie_quirk()

This code accidentally uses && where || was intended.  It potentially
results in a NULL dereference.

Thus, fix the if-statement expression to use the correct condition.

[kwilczynski: commit log]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2171c5cb2fbc3e03af7e8116cd58736c09328655; https://git.kernel.org/stable/c/23838bef2adb714ec37b2d6141dccf4a3a70bdef; https://git.kernel.org/stable/c/6188a1c762eb9bbd444f47696eda77a5eae6207a
CVE: CVE-2024-47757
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential oob read in nilfs_btree_check_delete()

The function nilfs_btree_check_delete(), which checks whether degeneration
to direct mapping occurs before deleting a b-tree entry, causes memory
access outside the block buffer when retrieving the maximum key if the
root node has no entries.

This does not usually happen because b-tree mappings with 0 child nodes
are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen
if the b-tree root node read from a device is configured that way, so fix
this potential issue by adding a check for that case.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/257f9e5185eb6de83377caea686c306e22e871f2; https://git.kernel.org/stable/c/a33e967b681e088a125b979975c93e3453e686cd; https://git.kernel.org/stable/c/a8abfda768b9f33630cfbc4af6c4214f1e5681b0
CVE: CVE-2024-49850
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos

In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL
referencing a non-existing BTF type, function bpf_core_calc_relo_insn
would cause a null pointer deference.

Fix this by adding a proper check upper in call stack, as malformed
relocation records could be passed from user space.

Simplest reproducer is a program:

    r0 = 0
    exit

With a single relocation record:

    .insn_off = 0,          /* patch first instruction */
    .type_id = 100500,      /* this type id does not exist */
    .access_str_off = 6,    /* offset of string "0" */
    .kind = BPF_CORE_TYPE_ID_LOCAL,

See the link for original reproducer or next commit for a test case.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2288b54b96dcb55bedebcef3572bb8821fc5e708; https://git.kernel.org/stable/c/3d2786d65aaa954ebd3fcc033ada433e10da21c4; https://git.kernel.org/stable/c/584cd3ff792e1edbea20b2a7df55897159b0be3e
CVE: CVE-2024-49851
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: Clean up TPM space after command failure

tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.

Fix this by flushing the space in the event of command transmission
failure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/2c9b228938e9266a1065a3f4fe5c99b7235dc439; https://git.kernel.org/stable/c/3f9f72d843c92fb6f4ff7460d774413cde7f254c; https://git.kernel.org/stable/c/82478cb8a23bd4f97935bbe60d64528c6d9918b4
CVE: CVE-2024-49852
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()

The kref_put() function will call nport->release if the refcount drops to
zero.  The nport->release release function is _efc_nport_free() which frees
"nport".  But then we dereference "nport" on the next line which is a use
after free.  Re-order these lines to avoid the use after free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/16a570f07d870a285b0c0b0d1ca4dff79e8aa5ff; https://git.kernel.org/stable/c/2e4b02fad094976763af08fec2c620f4f8edd9ae; https://git.kernel.org/stable/c/7c2908985e4ae0ea1b526b3916de9e[PII_REDACTED]
CVE: CVE-2024-49853
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Fix double free in OPTEE transport

Channels can be shared between protocols, avoid freeing the same channel
descriptors twice when unloading the stack.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/6699567b0bbb378600a4dc0a1f929439a4e84a2c; https://git.kernel.org/stable/c/aef6ae124bb3cc12e34430fed91fbb7efd7a444d; https://git.kernel.org/stable/c/d7f4fc2bc101e666da649605a9ece2bd42529c7a
CVE: CVE-2024-49854
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix uaf for accessing waker_bfqq after splitting

After commit 42c306ed7233 ("block, bfq: don't break merge chain in
bfq_split_bfqq()"), if the current procress is the last holder of bfqq,
the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and
then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq
may in the merge chain of bfqq, hence just recored waker_bfqq is still
not safe.

Fix the problem by adding a helper bfq_waker_bfqq() to check if
bfqq->waker_bfqq is in the merge chain, and current procress is the only
holder.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0780451f03bf518bc032a7c584de8f92e2d39d7f; https://git.kernel.org/stable/c/0b8bda0ff17156cd3f60944527c9d8c9f99f1583; https://git.kernel.org/stable/c/1ba0403ac6447f2d63914fb760c44a3b19c44eaf
CVE: CVE-2024-49855
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: fix race between timeout and normal completion

If request timetout is handled by nbd_requeue_cmd(), normal completion
has to be stopped for avoiding to complete this requeued request, other
use-after-free can be triggered.

Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime
make sure that cmd->lock is grabbed for clearing the flag and the
requeue.
CVSS Score: 7.0 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5236ada8ebbd9e7461f[PII_REDACTED]f5be4f46f7; https://git.kernel.org/stable/c/6e73b946a379a1dfbb62626af93843bdfb53753d; https://git.kernel.org/stable/c/9a74c3e6c0d686c26ba2aab66d15ddb89dc139cc