deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-38606
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - validate slices count returned by FW

The function adf_send_admin_tl_start() enables the telemetry (TL)
feature on a QAT device by sending the ICP_QAT_FW_TL_START message to
the firmware. This triggers the FW to start writing TL data to a DMA
buffer in memory and returns an array containing the number of
accelerators of each type (slices) supported by this HW.
The pointer to this array is stored in the adf_tl_hw_data data
structure called slice_cnt.

The array slice_cnt is then used in the function tl_print_dev_data()
to report in debugfs only statistics about the supported accelerators.
An incorrect value of the elements in slice_cnt might lead to an out
of bounds memory read.
At the moment, there isn't an implementation of FW that returns a wrong
value, but for robustness validate the slice count array returned by FW.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/483fd65ce29317044d1d00757e3fd23503b6b04c; https://git.kernel.org/stable/c/9b284b915e2a5e63ca133353f8c456eff4446f82; https://git.kernel.org/stable/c/e57ed345e2e6043629fc74aa5be051415dcc4f77
CVE: CVE-2024-38607
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"

The via-macii ADB driver calls request_irq() after disabling hard
interrupts. But disabling interrupts isn't necessary here because the
VIA shift register interrupt was masked during VIA1 initialization.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9; https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e; https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8
CVE: CVE-2024-38609
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: connac: check for null before dereferencing

The wcid can be NULL. It should be checked for validity before
dereferencing it to avoid crash.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/cb47c7be0e93dd5acda[PII_REDACTED]01ac3a78e10; https://git.kernel.org/stable/c/e469218765b2781fb968778bd13595acec181a0e; https://git.kernel.org/stable/c/cb47c7be0e93dd5acda[PII_REDACTED]01ac3a78e10
CVE: CVE-2024-38610
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()

Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".

Patch #1 fixes a bunch of issues I spotted in the acrn driver.  It
compiles, that's all I know.  I'll appreciate some review and testing from
acrn folks.

Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
more sanity checks, and improving the documentation.  Gave it a quick test
on x86-64 using VM_PAT that ends up using follow_pte().


This patch (of 3):

We currently miss handling various cases, resulting in a dangerous
follow_pte() (previously follow_pfn()) usage.

(1) We're not checking PTE write permissions.

Maybe we should simply always require pte_write() like we do for
pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
ACRN_MEM_ACCESS_WRITE for now.

(2) We're not rejecting refcounted pages.

As we are not using MMU notifiers, messing with refcounted pages is
dangerous and can result in use-after-free. Let's make sure to reject them.

(3) We are only looking at the first PTE of a bigger range.

We only lookup a single PTE, but memmap->len may span a larger area.
Let's loop over all involved PTEs and make sure the PFN range is
actually contiguous. Reject everything else: it couldn't have worked
either way, and rather made use access PFNs we shouldn't be accessing.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb; https://git.kernel.org/stable/c/3d6586008f7b638f91f[PII_REDACTED]caa8b00b559; https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4
CVE: CVE-2024-38611
Published: 2024-06-19
Description: 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)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/04d1086a62ac492ebb6bb0c94c1c8cb55f5d1f36; https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9; https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce
CVE: CVE-2024-38612
Published: 2024-06-19
Description: 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.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-416, CWE-476
References: https://git.kernel.org/stable/c/00e6335329f23ac6cf[PII_REDACTED]674e28bc598c; https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7; https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45
CVE: CVE-2024-38613
Published: 2024-06-19
Description: 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).
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0; https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14; https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82
CVE: CVE-2024-38614
Published: 2024-06-19
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/075c0405b0d7d9fc490609e988a3af[PII_REDACTED]; https://git.kernel.org/stable/c/c0ed9a711e3392d73e857faa031d8d349c0d70db; https://git.kernel.org/stable/c/c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f
CVE: CVE-2024-38615
Published: 2024-06-19
Description: 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2d730b465e377396d2a09a53524b96b111f7ccb6; https://git.kernel.org/stable/c/35db5e76d5e9f752476df5fa0b9018a2398b0378; https://git.kernel.org/stable/c/3e99f060cfd2e36504d62c9132b453ade5027e1c
CVE: CVE-2024-38616
Published: 2024-06-19
Description: 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.
CVSS Score: 8.2 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/042a39bb8e[PII_REDACTED]a5102606e88a5a4f8c02; https://git.kernel.org/stable/c/066afafc10c9476ee36c47c9062527a17e763901; https://git.kernel.org/stable/c/0c38c9c460bb8ce8d6f6cf316e0d71a70983ec83
CVE: CVE-2024-38617
Published: 2024-06-19
Description: 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-763
References: https://git.kernel.org/stable/c/03758d5a0932016b6d5f5bfbca580177e6bc937a; https://git.kernel.org/stable/c/42d21c9727028fe7ee392223ba127484b1b8677e; https://git.kernel.org/stable/c/7880dbf4eafe22a6a41a42e774f1122c814ed02d
CVE: CVE-2024-38618
Published: 2024-06-19
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2c95241ac5fc90c929d6c0c023e84bf0d30e84c3; https://git.kernel.org/stable/c/4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e; https://git.kernel.org/stable/c/68396c825c43664b20a3a1ba546844deb2b4e48f
CVE: CVE-2021-47573
Published: 2024-06-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47574
Published: 2024-06-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47575
Published: 2024-06-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47576
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()

In resp_mode_select() sanity check the block descriptor len to avoid UAF.

BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
Read of size 1 at addr ffff888026670f50 by task scsicmd/15032

CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Call Trace:
 <TASK>
 dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107
 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257
 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443
 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306
 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
 schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483
 scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537
 scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521
 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640
 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762
 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839
 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63
 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837
 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775
 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941
 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166
 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52
 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50
 entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/04181973c38f3d6a353f9246dcf7fee08024fd9e; https://git.kernel.org/stable/c/90491283b[PII_REDACTED]e4b0687d07b05df01e3bf; https://git.kernel.org/stable/c/a9078e791426c2cbbdf28a320c3670f6e0a611e6
CVE: CVE-2021-47577
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

io-wq: check for wq exit after adding new worker task_work

We check IO_WQ_BIT_EXIT before attempting to create a new worker, and
wq exit cancels pending work if we have any. But it's possible to have
a race between the two, where creation checks exit finding it not set,
but we're in the process of exiting. The exit side will cancel pending
creation task_work, but there's a gap where we add task_work after we've
canceled existing creations at exit time.

Fix this by checking the EXIT bit post adding the creation task_work.
If it's set, run the same cancelation that exit does.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/4b4e5bbf9386d4ec21d91c0cb0fd60b9bba778ec; https://git.kernel.org/stable/c/71a85387546e50b1a37b0fa45dadcae3bfb35cf6; https://git.kernel.org/stable/c/4b4e5bbf9386d4ec21d91c0cb0fd60b9bba778ec
CVE: CVE-2021-47578
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Don't call kcalloc() if size arg is zero

If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR.  Because of
that, for a following NULL pointer check to work on the returned pointer,
kcalloc() must not be called with the size arg equal to zero. Return early
without error before the kcalloc() call if size arg is zero.

BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974
Write of size 4 at addr [PII_REDACTED] by task syz-executor.1/22789

CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
Call Trace:
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
 __kasan_report mm/kasan/report.c:446 [inline]
 kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189
 memcpy+0x3b/0x60 mm/kasan/shadow.c:66
 memcpy include/linux/fortify-string.h:191 [inline]
 sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974
 do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]
 do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]
 resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276
 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478
 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533
 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]
 scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699
 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639
 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761
 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838
 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62
 blk_execute_rq+0xdb/0x360 block/blk-exec.c:102
 sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]
 scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930
 sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112
 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:874 [inline]
 __se_sys_ioctl fs/ioctl.c:860 [inline]
 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3344b58b53a76199dae48faa396e9fc37bf86992; https://git.kernel.org/stable/c/47d11d35203b0aa13533634e270fe2c3610e531b; https://git.kernel.org/stable/c/aa1f912712a109b[PII_REDACTED]de7e5343f016b26
CVE: CVE-2021-47579
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: fix warning in ovl_create_real()

Syzbot triggered the following warning in ovl_workdir_create() ->
ovl_create_real():

	if (!err && WARN_ON(!newdentry->d_inode)) {

The reason is that the cgroup2 filesystem returns from mkdir without
instantiating the new dentry.

Weird filesystems such as this will be rejected by overlayfs at a later
stage during setup, but to prevent such a warning, call ovl_mkdir_real()
directly from ovl_workdir_create() and reject this case early.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1f5573cfe7a7056e80a92c7a037a3e69f3a13d1c; https://git.kernel.org/stable/c/445d2dc63e5871d218f21b8f62ab29ac72f2e6b8; https://git.kernel.org/stable/c/6859985a2fbda5d1586bf44538853e1be69e85f7
CVE: CVE-2021-47580
Published: 2024-06-19
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Fix type in min_t to avoid stack OOB

Change min_t() to use type "u32" instead of type "int" to avoid stack out
of bounds. With min_t() type "int" the values get sign extended and the
larger value gets used causing stack out of bounds.

BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
Read of size 127 at addr ffff[PII_REDACTED]28 by task syz-executor.7/18707

CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
Call Trace:
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189
 memcpy+0x23/0x60 mm/kasan/shadow.c:65
 memcpy include/linux/fortify-string.h:191 [inline]
 sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000
 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162
 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]
 resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887
 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478
 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533
 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]
 scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699
 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639
 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761
 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838
 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62
 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836
 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774
 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939
 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:874 [inline]
 __se_sys_ioctl fs/ioctl.c:860 [inline]
 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 6.6 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/[PII_REDACTED]938eb41f0bc0e25ef9791e71f5ee4b; https://git.kernel.org/stable/c/36e07d7ede88a1f1ef8f0f209af5b7612324ac2c; https://git.kernel.org/stable/c/bdb854f134b964528fa543e0351022eb45bd7346
CVE: CVE-2021-47581
Published: 2024-06-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.