rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-38611 media: i2c: et8ek8: Don't strip remove function when driver is builtin
In the Linux kernel, the following vulnerability has been resolved:

media: i2c: et8ek8: Don't strip remove function when driver is builtin

Using __exit for the remove function results in the remove callback
being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
unbound (e.g. using sysfs or hotplug), the driver is just removed
without the cleanup being performed. This results in resource leaks. Fix
it by compiling in the remove callback unconditionally.

This also fixes a W=1 modpost warning:

	WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:12.742Z
CVE-2024-38612 ipv6: sr: fix invalid unregister error path
In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix invalid unregister error path

The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL
is not defined. In that case if seg6_hmac_init() fails, the
genl_unregister_family() isn't called.

This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control
lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible
use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()
with genl_unregister_family() in this error path.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:13.415Z
CVE-2024-38613 m68k: Fix spinlock race in kernel thread creation
In the Linux kernel, the following vulnerability has been resolved:

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across
the switch from 'prev' to 'next' tasks.  This does rely on interrupts
remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context
switching between already running processes, because both 'prev' and
'next' already have interrupts disabled in their saved copies of the
status register.

The situation is different for newly created kernel threads.  The status
register is set to PS_S in copy_thread(), which does leave the IPL at 0.
Upon restoring the 'next' thread's status register in switch_to() aka
resume(), interrupts then become enabled prematurely.  resume() then
returns via ret_from_kernel_thread() and schedule_tail() where run queue
lock is released (see finish_task_switch() and finish_lock_switch()).

A timer interrupt calling scheduler_tick() before the lock is released
in finish_task_switch() will find the lock already taken, with the
current task as lock owner.  This causes a spinlock recursion warning as
reported by Guenter Roeck.

As far as I can ascertain, this race has been opened in commit
533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
but I haven't done a detailed study of kernel history so it may well
predate that commit.

Interrupts cannot be disabled in the saved status register copy for
kernel threads (init will complain about interrupts disabled when
finally starting user space).  Disable interrupts temporarily when
switching the tasks' register sets in resume().

Note that a simple oriw 0x700,%sr after restoring sr is not enough here
- this leaves enough of a race for the 'spinlock recursion' warning to
still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:14.083Z
CVE-2024-38614 openrisc: traps: Don't send signals to kernel mode threads
In the Linux kernel, the following vulnerability has been resolved:

openrisc: traps: Don't send signals to kernel mode threads

OpenRISC exception handling sends signals to user processes on floating
point exceptions and trap instructions (for debugging) among others.
There is a bug where the trap handling logic may send signals to kernel
threads, we should not send these signals to kernel threads, if that
happens we treat it as an error.

This patch adds conditions to die if the kernel receives these
exceptions in kernel mode code.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:14.753Z
CVE-2024-38615 cpufreq: exit() callback is optional
In the Linux kernel, the following vulnerability has been resolved:

cpufreq: exit() callback is optional

The exit() callback is optional and shouldn't be called without checking
a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn't
present.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:15.422Z
CVE-2024-38616 wifi: carl9170: re-fix fortified-memset warning
In the Linux kernel, the following vulnerability has been resolved:

wifi: carl9170: re-fix fortified-memset warning

The carl9170_tx_release() function sometimes triggers a fortified-memset
warning in my randconfig builds:

In file included from include/linux/string.h:254,
                 from drivers/net/wireless/ath/carl9170/tx.c:40:
In function 'fortify_memset_chk',
    inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2,
    inlined from 'kref_put' at include/linux/kref.h:65:3,
    inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9:
include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  493 |                         __write_overflow_field(p_size_field, size);

Kees previously tried to avoid this by using memset_after(), but it seems
this does not fully address the problem. I noticed that the memset_after()
here is done on a different part of the union (status) than the original
cast was from (rate_driver_data), which may confuse the compiler.

Unfortunately, the memset_after() trick does not work on driver_rates[]
because that is part of an anonymous struct, and I could not get
struct_group() to do this either. Using two separate memset() calls
on the two members does address the warning though.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:16.086Z
CVE-2024-38617 kunit/fortify: Fix mismatched kvalloc()/vfree() usage
In the Linux kernel, the following vulnerability has been resolved:

kunit/fortify: Fix mismatched kvalloc()/vfree() usage

The kv*() family of tests were accidentally freeing with vfree() instead
of kvfree(). Use kvfree() instead.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:16.763Z
CVE-2024-38618 ALSA: timer: Set lower bound of start tick time
In the Linux kernel, the following vulnerability has been resolved:

ALSA: timer: Set lower bound of start tick time

Currently ALSA timer doesn't have the lower limit of the start tick
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
for hrtimer.  Such a situation may lead to an unexpected RCU stall,
where  the callback repeatedly queuing the expire update, as reported
by fuzzer.

This patch introduces a sanity check of the timer start tick time, so
that the system returns an error when a too small start size is set.
As of this patch, the lower limit is hard-coded to 100us, which is
small enough but can still work somehow.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-19T13:56:17.422Z
CVE-2024-38619 usb-storage: alauda: Check whether the media is initialized
In the Linux kernel, the following vulnerability has been resolved:

usb-storage: alauda: Check whether the media is initialized

The member "uzonesize" of struct alauda_info will remain 0
if alauda_init_media() fails, potentially causing divide errors
in alauda_read_data() and alauda_write_lba().
- Add a member "media_initialized" to struct alauda_info.
- Change a condition in alauda_check_media() to ensure the
  first initialization.
- Add an error check for the return value of alauda_init_media().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-20T06:47:32.444Z
CVE-2024-38620 Bluetooth: HCI: Remove HCI_AMP support
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: HCI: Remove HCI_AMP support

Since BT_HS has been remove HCI_AMP controllers no longer has any use so
remove it along with the capability of creating AMP controllers.

Since we no longer need to differentiate between AMP and Primary
controllers, as only HCI_PRIMARY is left, this also remove
hdev->dev_type altogether.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-20T08:03:43.906Z
CVE-2024-38621 media: stk1160: fix bounds checking in stk1160_copy_video()
In the Linux kernel, the following vulnerability has been resolved:

media: stk1160: fix bounds checking in stk1160_copy_video()

The subtract in this condition is reversed.  The ->length is the length
of the buffer.  The ->bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it's unsigned then the result
is a very high positive value.  That means the overflow check is never
true.

Additionally, the ->bytesused doesn't actually work for this purpose
because we're not writing to "buf->mem + buf->bytesused".  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf->length bytes.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:14.955Z
CVE-2024-38622 drm/msm/dpu: Add callback function pointer check before its call
In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: Add callback function pointer check before its call

In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
but then callback function is unconditionally called by this pointer.
Fix this bug by adding conditional return.

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

Patchwork: https://patchwork.freedesktop.org/patch/588237/
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:15.625Z
CVE-2024-38623 fs/ntfs3: Use variable length array instead of fixed size
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning:
	ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:16.291Z
CVE-2024-38624 fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression:
	vbo = 2 * vbo + skip
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:16.940Z
CVE-2024-38625 fs/ntfs3: Check 'folio' pointer for NULL
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Check 'folio' pointer for NULL

It can be NULL if bmap is called.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:17.603Z
CVE-2024-38626 fuse: clear FR_SENT when re-adding requests into pending list
In the Linux kernel, the following vulnerability has been resolved:

fuse: clear FR_SENT when re-adding requests into pending list

The following warning was reported by lee bruce:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300
  fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300
  Modules linked in:
  CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300
  ......
  Call Trace:
  <TASK>
  fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334
  fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367
  call_read_iter include/linux/fs.h:2104 [inline]
  new_sync_read fs/read_write.c:395 [inline]
  vfs_read+0x85b/0xba0 fs/read_write.c:476
  ksys_read+0x12f/0x260 fs/read_write.c:619
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ......
  </TASK>

The warning is due to the FUSE_NOTIFY_RESEND notify sent by the write()
syscall in the reproducer program and it happens as follows:

(1) calls fuse_dev_read() to read the INIT request
The read succeeds. During the read, bit FR_SENT will be set on the
request.
(2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify
The resend notify will resend all processing requests, so the INIT
request is moved from processing list to pending list again.
(3) calls fuse_dev_read() with an invalid output address
fuse_dev_read() will try to copy the same INIT request to the output
address, but it will fail due to the invalid address, so the INIT
request is ended and triggers the warning in fuse_request_end().

Fix it by clearing FR_SENT when re-adding requests into pending list.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:18.255Z
CVE-2024-38627 stm class: Fix a double free in stm_register_device()
In the Linux kernel, the following vulnerability has been resolved:

stm class: Fix a double free in stm_register_device()

The put_device(&stm->dev) call will trigger stm_device_release() which
frees "stm" so the vfree(stm) on the next line is a double free.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:18.912Z
CVE-2024-38628 usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.

Hang on to the control IDs instead of pointers since those are correctly
handled with locks.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:19.558Z
CVE-2024-38629 dmaengine: idxd: Avoid unnecessary destruction of file_ida
In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Avoid unnecessary destruction of file_ida

file_ida is allocated during cdev open and is freed accordingly
during cdev release. This sequence is guaranteed by driver file
operations. Therefore, there is no need to destroy an already empty
file_ida when the WQ cdev is removed.

Worse, ida_free() in cdev release may happen after destruction of
file_ida per WQ cdev. This can lead to accessing an id in file_ida
after it has been destroyed, resulting in a kernel panic.

Remove ida_destroy(&file_ida) to address these issues.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:20.239Z
CVE-2024-38630 watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
In the Linux kernel, the following vulnerability has been resolved:

watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.

Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:20.892Z
CVE-2024-38631 iio: adc: PAC1934: fix accessing out of bounds array index
In the Linux kernel, the following vulnerability has been resolved:

iio: adc: PAC1934: fix accessing out of bounds array index

Fix accessing out of bounds array index for average
current and voltage measurements. The device itself has
only 4 channels, but in sysfs there are "fake"
channels for the average voltages and currents too.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:21.553Z
CVE-2024-38632 vfio/pci: fix potential memory leak in vfio_intx_enable()
In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:22.236Z
CVE-2024-38633 serial: max3100: Update uart_driver_registered on driver removal
In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Update uart_driver_registered on driver removal

The removal of the last MAX3100 device triggers the removal of
the driver. However, code doesn't update the respective global
variable and after insmod — rmmod — insmod cycle the kernel
oopses:

  max3100 spi-PRP0001:01: max3100_probe: adding port 0
  BUG: kernel NULL pointer dereference, address: 0000000000000408
  ...
  RIP: 0010:serial_core_register_port+0xa0/0x840
  ...
   max3100_probe+0x1b6/0x280 [max3100]
   spi_probe+0x8d/0xb0

Update the actual state so next time UART driver will be registered
again.

Hugo also noticed, that the error path in the probe also affected
by having the variable set, and not cleared. Instead of clearing it
move the assignment after the successfull uart_register_driver() call.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:22.905Z
CVE-2024-38634 serial: max3100: Lock port->lock when calling uart_handle_cts_change()
In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Lock port->lock when calling uart_handle_cts_change()

uart_handle_cts_change() has to be called with port lock taken,
Since we run it in a separate work, the lock may not be taken at
the time of running. Make sure that it's taken by explicitly doing
that. Without it we got a splat:

  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
  ...
  Workqueue: max3100-0 max3100_work [max3100]
  RIP: 0010:uart_handle_cts_change+0xa6/0xb0
  ...
   max3100_handlerx+0xc5/0x110 [max3100]
   max3100_work+0x12a/0x340 [max3100]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:23.573Z
CVE-2024-38635 soundwire: cadence: fix invalid PDI offset
In the Linux kernel, the following vulnerability has been resolved:

soundwire: cadence: fix invalid PDI offset

For some reason, we add an offset to the PDI, presumably to skip the
PDI0 and PDI1 which are reserved for BPT.

This code is however completely wrong and leads to an out-of-bounds
access. We were just lucky so far since we used only a couple of PDIs
and remained within the PDI array bounds.

A Fixes: tag is not provided since there are no known platforms where
the out-of-bounds would be accessed, and the initial code had problems
as well.

A follow-up patch completely removes this useless offset.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:24.244Z
CVE-2024-38637 greybus: lights: check return of get_channel_from_mode
In the Linux kernel, the following vulnerability has been resolved:

greybus: lights: check return of get_channel_from_mode

If channel for the given node is not found we return null from
get_channel_from_mode. Make sure we validate the return pointer
before using it in two of the missing places.

This was originally reported in [0]:
Found by Linux Verification Center (linuxtesting.org) with SVACE.

[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-06-21T10:18:25.560Z
CVE-2024-38638 QTS, QuTS hero
An out-of-bounds write vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers who have gained administrator access to modify or corrupt memory.

QTS 5.2.x/QuTS hero h5.2.x are not affected.

We have already fixed the vulnerability in the following versions:
QTS 5.1.9.2954 build 20241120 and later
QuTS hero h5.1.9.2954 build 20241120 and later
Problem types: cwe_id: CWE-787
description: CWE-787
Affected products: vendor: QNAP Systems Inc.
product: QTS
default_status: unaffected
vendor: QNAP Systems Inc.
product: QuTS hero
default_status: unaffected
Credits: lang: en
value: leeya_bug
Published: 2025-03-07T16:12:47.551Z
CVE-2024-38640 Download Station
A cross-site scripting (XSS) vulnerability has been reported to affect Download Station. If exploited, the vulnerability could allow authenticated users to inject malicious code via a network.

We have already fixed the vulnerability in the following version:
Download Station 5.8.6.283 ( 2024/06/21 ) and later
Problem types: cwe_id: CWE-79
description: CWE-79
Affected products: vendor: QNAP Systems Inc.
product: Download Station
default_status: unaffected
Credits: lang: en
value: Mohammad Abdullah - Infosec Researcher & Bugbounty hunter
Published: 2024-09-06T16:29:50.479Z
CVE-2024-38641 QTS, QuTS hero
An OS command injection vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow local network users to execute commands via unspecified vectors.

We have already fixed the vulnerability in the following versions:
QTS 5.1.8.2823 build 20240712 and later
QuTS hero h5.1.8.2823 build 20240712 and later
Problem types: cwe_id: CWE-77
description: CWE-77
cwe_id: CWE-78
description: CWE-78
Affected products: vendor: QNAP Systems Inc.
product: QTS
default_status: unaffected
vendor: QNAP Systems Inc.
product: QuTS hero
default_status: unaffected
Credits: lang: en
value: Team Viettel in Matrix Cup 2024
Published: 2024-09-06T16:27:46.814Z