deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2020-36776
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal/drivers/cpufreq_cooling: Fix slab OOB issue

Slab OOB issue is scanned by KASAN in cpu_power_to_freq().
If power is limited below the power of OPP0 in EM table,
it will cause slab out-of-bound issue with negative array
index.

Return the lowest frequency if limited power cannot found
a suitable OPP in EM table to fix this issue.

Backtrace:
[<ffffffd02d2a37f0>] die+0x104/0x5ac
[<ffffffd02d2a5630>] bug_handler+0x64/0xd0
[<ffffffd02d288ce4>] brk_handler+0x160/0x258
[<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0
[<ffffffd02d284488>] el1_dbg+0x14/0xbc
[<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0
[<ffffffd02d75c2e0>] kasan_report+0x10/0x20
[<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28
[<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c
[<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4
[<ffffffd02e6fac24>] allocate_power+0xaec/0xde0
[<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4
[<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294
[<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154
[<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28
[<ffffffd02d352f44>] worker_thread+0xa4c/0xfac
[<ffffffd02d360124>] kthread+0x33c/0x358
[<ffffffd02d289940>] ret_from_fork+0xc/0x18
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/34ab17cc6c2c1ac93d7e5d53bb972df9a968f085; https://git.kernel.org/stable/c/6bf443acf6ca4f666d0e4225614ba9993a3aa1a9; https://git.kernel.org/stable/c/876a5f33e5d961d879c5436987c09b3d9ef70379
CVE: CVE-2020-36777
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvbdev: Fix memory leak in dvb_media_device_free()

dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`
before setting it to NULL, as documented in include/media/media-device.h:
"The media_entity instance itself must be freed explicitly by the driver
if required."
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275; https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f; https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749
CVE: CVE-2021-46939
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Restructure trace_clock_global() to never block

It was reported that a fix to the ring buffer recursion detection would
cause a hung machine when performing suspend / resume testing. The
following backtrace was extracted from debugging that case:

Call Trace:
 trace_clock_global+0x91/0xa0
 __rb_reserve_next+0x237/0x460
 ring_buffer_lock_reserve+0x12a/0x3f0
 trace_buffer_lock_reserve+0x10/0x50
 __trace_graph_return+0x1f/0x80
 trace_graph_return+0xb7/0xf0
 ? trace_clock_global+0x91/0xa0
 ftrace_return_to_handler+0x8b/0xf0
 ? pv_hash+0xa0/0xa0
 return_to_handler+0x15/0x30
 ? ftrace_graph_caller+0xa0/0xa0
 ? trace_clock_global+0x91/0xa0
 ? __rb_reserve_next+0x237/0x460
 ? ring_buffer_lock_reserve+0x12a/0x3f0
 ? trace_event_buffer_lock_reserve+0x3c/0x120
 ? trace_event_buffer_reserve+0x6b/0xc0
 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
 ? dpm_run_callback+0x3b/0xc0
 ? pm_ops_is_empty+0x50/0x50
 ? platform_get_irq_byname_optional+0x90/0x90
 ? trace_device_pm_callback_start+0x82/0xd0
 ? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to
happen while tracing, this lead to the trace_clock_global() taking a spin
lock and then trying to take it again:

ring_buffer_lock_reserve() {
  trace_clock_global() {
    arch_spin_lock() {
      queued_spin_lock_slowpath() {
        /* lock taken */
        (something else gets traced by function graph tracer)
          ring_buffer_lock_reserve() {
            trace_clock_global() {
              arch_spin_lock() {
                queued_spin_lock_slowpath() {
                /* DEAD LOCK! */

Tracing should *never* block, as it can lead to strange lockups like the
above.

Restructure the trace_clock_global() code to instead of simply taking a
lock to update the recorded "prev_time" simply use it, as two events
happening on two different CPUs that calls this at the same time, really
doesn't matter which one goes first. Use a trylock to grab the lock for
updating the prev_time, and if it fails, simply try again the next time.
If it failed to be taken, that means something else is already updating
it.


Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-662, CWE-400
References: https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545; https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e; https://git.kernel.org/stable/c/6e[PII_REDACTED]eeb12e7ba82edb8f[PII_REDACTED]ff
CVE: CVE-2021-46940
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tools/power turbostat: Fix offset overflow issue in index converting

The idx_to_offset() function returns type int (32-bit signed), but
MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number.
The end result is that it hits the if (offset < 0) check in update_msr_sum()
which prevents the timer callback from updating the stat in the background when
long durations are used. The similar issue exists in offset_to_idx() and
update_msr_sum(). Fix this issue by converting the 'int' to 'off_t' accordingly.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/13a779de4175df602366d129e41782ad7168cef0; https://git.kernel.org/stable/c/337b1546cde87fb8588ddaedf0201b769baa572a; https://git.kernel.org/stable/c/dbdf22fc825fdb1d97f23230064e0f[PII_REDACTED]
CVE: CVE-2021-46941
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: core: Do core softreset when switch mode


According to the programming guide, to switch mode for DRD controller,
the driver needs to do the following.

To switch from device to host:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(host mode)
3. Reset the host with USBCMD.HCRESET
4. Then follow up with the initializing host registers sequence

To switch from host to device:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(device mode)
3. Reset the device with DCTL.CSftRst
4. Then follow up with the initializing registers sequence

Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
switching from host to device. John Stult reported a lockup issue seen
with HiKey960 platform without these steps[1]. Similar issue is observed
with Ferry's testing platform[2].

So, apply the required steps along with some fixes to Yu Chen's and John
Stultz's version. The main fixes to their versions are the missing wait
for clocks synchronization before clearing GCTL.CoreSoftReset and only
apply DCTL.CSftRst when switching from host to device.

[1] https://lore.kernel.org/linux-usb/[PII_REDACTED]5115.27920-1-john.stultz@linaro.org/
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3; https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b; https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9
CVE: CVE-2021-46942
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix shared sqpoll cancellation hangs

[  736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds.
[  736.982897] Call Trace:
[  736.982901]  schedule+0x68/0xe0
[  736.982903]  io_uring_cancel_sqpoll+0xdb/0x110
[  736.982908]  io_sqpoll_cancel_cb+0x24/0x30
[  736.982911]  io_run_task_work_head+0x28/0x50
[  736.982913]  io_sq_thread+0x4e3/0x720

We call io_uring_cancel_sqpoll() one by one for each ctx either in
sq_thread() itself or via task works, and it's intended to cancel all
requests of a specified context. However the function uses per-task
counters to track the number of inflight requests, so it counts more
requests than available via currect io_uring ctx and goes to sleep for
them to appear (e.g. from IRQ), that will never happen.

Cancel a bit more than before, i.e. all ctxs that share sqpoll
and continue to use shared counters. Don't forget that we should not
remove ctx from the list before running that task_work sqpoll-cancel,
otherwise the function wouldn't be able to find the context and will
hang.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/734551df6f9bedfbefcd113ede665945e9de0b99; https://git.kernel.org/stable/c/cb5e0b3d0f993a6268c1a2c7ede2f9aa0c17ef68; https://git.kernel.org/stable/c/734551df6f9bedfbefcd113ede665945e9de0b99
CVE: CVE-2021-46943
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: staging/intel-ipu3: Fix set_fmt error handling

If there in an error during a set_fmt, do not overwrite the previous
sizes with the invalid config.

Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and
causing the following OOPs

[   38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes)
[   38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0
[   38.663010] general protection fault: 0000 [#1] PREEMPT SMP
CVSS Score: 7.8 (HIGH)
CWE: CWE-131
References: https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916; https://git.kernel.org/stable/c/6fb617e37a39db0a3eca[PII_REDACTED]d0bdf3b9bc; https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6
CVE: CVE-2021-46944
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: staging/intel-ipu3: Fix memory leak in imu_fmt

We are losing the reference to an allocated memory if try. Change the
order of the check to avoid that.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e; https://git.kernel.org/stable/c/[PII_REDACTED]afba1d16c462b04d569b[PII_REDACTED]; https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9
CVE: CVE-2021-46945
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: always panic when errors=panic is specified

Before commit 014c9caa29d3 ("ext4: make ext4_abort() use
__ext4_error()"), the following series of commands would trigger a
panic:

1. mount /dev/sda -o ro,errors=panic test
2. mount /dev/sda -o remount,abort test

After commit 014c9caa29d3, remounting a file system using the test
mount option "abort" will no longer trigger a panic.  This commit will
restore the behaviour immediately before commit 014c9caa29d3.
(However, note that the Linux kernel's behavior has not been
consistent; some previous kernel versions, including 5.4 and 4.19
similarly did not panic after using the mount option "abort".)

This also makes a change to long-standing behaviour; namely, the
following series commands will now cause a panic, when previously it
did not:

1. mount /dev/sda -o ro,errors=panic test
2. echo test > /sys/fs/ext4/sda/trigger_fs_error

However, this makes ext4's behaviour much more consistent, so this is
a good thing.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1e9ea8f4637026b8e965128953f2da061ccae9c4; https://git.kernel.org/stable/c/64e1eebe[PII_REDACTED]f4fbb6b1491355f96c6cde; https://git.kernel.org/stable/c/ac2f7ca51b0929461ea49918f27c11b680f28995
CVE: CVE-2021-46946
Published: 2024-02-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-46947
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues

efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is
later used to allocate and traverse efx->xdp_tx_queues lookup array. However,
we may end up not initializing all the array slots with real queues during
probing. This results, for example, in a NULL pointer dereference, when running
"# ethtool -S <iface>", similar to below

[2[PII_REDACTED]55][T4126959] BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0000f8
[2[PII_REDACTED]83][T4126959] #PF: supervisor read access in kernel mode
[2[PII_REDACTED]78][T4126959] #PF: error_code(0x0000) - not-present page
[2[PII_REDACTED]13][T4126959] PGD 0 P4D 0
[2[PII_REDACTED]49][T4126959] Oops: 0000 [#1] SMP PTI
[2[PII_REDACTED]08][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G           O      5.10.20-cloudflare-2021.3.1 #1
[2[PII_REDACTED]41][T4126959] Hardware name: <redacted>
[2[PII_REDACTED]08][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc]
[2[PII_REDACTED]73][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b
[2[PII_REDACTED]59][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202
[2[PII_REDACTED]21][T4126959] RAX: [PII_REDACTED] RBX: ffffb799cd0c9280 RCX: [PII_REDACTED]
[2[PII_REDACTED]72][T4126959] RDX: [PII_REDACTED] RSI: ffff96dd970ce000 RDI: [PII_REDACTED]
[2[PII_REDACTED]25][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09:[PII_REDACTED]00005f
[2[PII_REDACTED]14][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8
[2[PII_REDACTED]06][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c
[2[PII_REDACTED]05][T4126959] FS:  00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:[PII_REDACTED]
[2[PII_REDACTED]48][T4126959] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[2[PII_REDACTED]24][T4126959] CR2:[PII_REDACTED]0000f8 CR3: 0000001a73e6e006 CR4:[PII_REDACTED]7706e0
[2[PII_REDACTED]29][T4126959] DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
[2[PII_REDACTED]00][T4126959] DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
[2[PII_REDACTED]08][T4126959] PKRU: 55555554
[2[PII_REDACTED]49][T4126959] Call Trace:
[2[PII_REDACTED]98][T4126959]  dev_ethtool+0x1832/0x2830

Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true
value of initialized slots in efx->xdp_tx_queues.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/99ba0ea616aabdc8e26259fd722503e012199a76; https://git.kernel.org/stable/c/ebeac958b690123a0b40aa61f688f2f170035fad; https://git.kernel.org/stable/c/99ba0ea616aabdc8e26259fd722503e012199a76
CVE: CVE-2021-46948
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: farch: fix TX queue lookup in TX event handling

We're starting from a TXQ label, not a TXQ type, so
 efx_channel_get_tx_queue() is inappropriate (and could return NULL,
 leading to panics).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052; https://git.kernel.org/stable/c/83b09a[PII_REDACTED]b387c7bc748d329fefc5617e; https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253
CVE: CVE-2021-46949
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: farch: fix TX queue lookup in TX flush done handling

We're starting from a TXQ instance number ('qid'), not a TXQ type, so
 efx_get_tx_queue() is inappropriate (and could return NULL, leading
 to panics).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac; https://git.kernel.org/stable/c/98d[PII_REDACTED]6bfb6dfb3e72765f3225719a647; https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170
CVE: CVE-2021-46950
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid1: properly indicate failure when ending a failed write request

This patch addresses a data corruption bug in raid1 arrays using bitmaps.
Without this fix, the bitmap bits for the failed I/O end up being cleared.

Since we are in the failure leg of raid1_end_write_request, the request
either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5; https://git.kernel.org/stable/c/2417b9869b81882ab90fd5ed1081a1cb2d4db1dd; https://git.kernel.org/stable/c/538244fba59fde[PII_REDACTED]247cd9c05be86dd
CVE: CVE-2021-46951
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: efi: Use local variable for calculating final log size

When tpm_read_log_efi is called multiple times, which happens when
one loads and unloads a TPM2 driver multiple times, then the global
variable efi_tpm_final_log_size will at some point become a negative
number due to the subtraction of final_events_preboot_size occurring
each time. Use a local variable to avoid this integer underflow.

The following issue is now resolved:

Mar  8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Mar  8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy]
Mar  8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20
Mar  8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4
Mar  8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206
Mar  8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f
Mar  8 15:35:12 hibinst kernel: RDX: [PII_REDACTED] RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d
Mar  8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: [PII_REDACTED] R09: 000000007e9d6073
Mar  8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12:[PII_REDACTED]000ed5
Mar  8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: [PII_REDACTED] R15: ffff88f77de7f018
Mar  8 15:35:12 hibinst kernel: FS:  [PII_REDACTED](0000) GS:ffff88f87bd00000(0000) knlGS:[PII_REDACTED]
Mar  8 15:35:12 hibinst kernel: CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
Mar  8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3:[PII_REDACTED]5a6004 CR4:[PII_REDACTED]060ee0
Mar  8 15:35:12 hibinst kernel: Call Trace:
Mar  8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7
Mar  8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0
Mar  8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260
Mar  8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]
Mar  8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370
Mar  8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0
Mar  8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76; https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb; https://git.kernel.org/stable/c/48cff270b037022e37835d[PII_REDACTED]5ca25101
CVE: CVE-2021-46952
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds

Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused
by a garbage timeout (retrans) mount option being passed to nfs mount,
in this case from syzkaller.

If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift
value for a 64-bit long integer, so 'retrans' cannot be >= 64.
If it is >= 64, fail the mount and return an error.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897; https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8; https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2
CVE: CVE-2021-46953
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure

When failing the driver probe because of invalid firmware properties,
the GTDT driver unmaps the interrupt that it mapped earlier.

However, it never checks whether the mapping of the interrupt actially
succeeded. Even more, should the firmware report an illegal interrupt
number that overlaps with the GIC SGI range, this can result in an
IPI being unmapped, and subsequent fireworks (as reported by Dann
Frazier).

Rework the driver to have a slightly saner behaviour and actually
check whether the interrupt has been mapped before unmapping things.
CVSS Score: 6.7 (MEDIUM)
References: https://git.kernel.org/stable/c/1ecd5b129252249b9bc03d7645a7bda512747277; https://git.kernel.org/stable/c/42e69521ee1fa5abf21f478d147d06bbfe6bf6a8; https://git.kernel.org/stable/c/504632a3577a049dd9bb7aabae5b4476f9c586b4
CVE: CVE-2021-46956
Published: 2024-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

virtiofs: fix memory leak in virtio_fs_probe()

When accidentally passing twice the same tag to qemu, kmemleak ended up
reporting a memory leak in virtiofs.  Also, looking at the log I saw the
following error (that's when I realised the duplicated tag):

  virtiofs: probe of virtio5 failed with error -17

Here's the kmemleak log for reference:

unreferenced object 0xffff888103d47800 (size 1024):
  comm "systemd-udevd", pid 118, jiffies[PII_REDACTED] (age 18.340s)
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff  ................
  backtrace:
    [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs]
    [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210
    [<000000004d6baf3c>] really_probe+0xea/0x430
    [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0
    [<[PII_REDACTED]6f47a7>] __driver_attach+0x98/0x140
    [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0
    [<[PII_REDACTED]9c7b7f>] bus_add_driver+0x11b/0x1f0
    [<[PII_REDACTED]b09ba7>] driver_register+0x8f/0xe0
    [<00000000cdd55998>] 0xffffffffa002c013
    [<000000000ea196a2>] do_one_initcall+0x64/0x2e0
    [<[PII_REDACTED]f727ce>] do_init_module+0x5c/0x260
    [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120
    [<00000000ad2f48c6>] do_syscall_64+0x33/0x40
    [<[PII_REDACTED]9526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/310efc95c72c13faf855c692d19cd4d054d827c8; https://git.kernel.org/stable/c/5116e79fc6e6725b8acdad8b7e928a83ab7b47e6; https://git.kernel.org/stable/c/9b9d60c0eb8ada99cce2a9ab5c15dffc523b01ae